Reprise du message précédent :
Déjà, un CPU 32bit peu addresser plus de 4Go de RAM depuis longtemps... Et de plus, Quake 4 en Ultra High il a un commit charge de plus de 2Go ...

tout a fait, ou tout simplement lacher les CPU & OS 32bits, puisque DirectX   10 ne sera pas présent sur Xp (enfin je crois), et ne sera pas rétrocompatible avec les cartes non Dx10 hardware.
 
en fait on risque d'avoir un basculement aligné dans le domaine des jeux depuis 32bits+D3D9 => vers 64bits/D3D10. (j'ai dit on risque)
 
En fait comme les cartes DX10 seront forcement plus rapides que les actuelles, elles se vendront sans problèmes (comme d'hab), les moteurs vont rester en D3D9 pendant un certain temps, puis basculer sans rétro compatibilité en D3D10 (en fait, il risque d'y avoir un renderer D3D9 et 10, un peu comme FarCry & Unreal qui ont des renderers D3D & OpenGl).
Et puis comme la "barre" des assets va grimper sensiblement vers les 2Go, on risque d'avoir simultanément de multiples changements.
 
en fait l'année prochaine, ça risque d'être la fête du slip, entre le Conroe, le passage à D3D10 et les cartes qui vont avec, l'interêt grandissant des builds 64bits dû à la montée en qualité des ressources....

 
non linéairement d'un point de vue logiciel. sous Windows 32bits la barre est de 2Go par process, 4Go sous Win64 pour un process Win32, 3Go sous Linux.
 
Maintenant Quake 4 tu as un snapshot ? (j'essayerai a la maison), il doit y avoir des subtilités dans le calcul pour que cela se produise.

Même Outlook il chie quand tu lui colles un pst qui s'approche de 2Go lol (ça doit être une histoire de fichier mappé en mémoire encore)

Tout ce que je sais c'est que le chargement du niveau dliIntro ne passe pas si pas si j'ai pas >512Mo de swap en plus de mes 2Go de RAM physique,  j'ai >2,5Go de RAM utilisé au global dans le gestionnaire de tache... Or j'ai a peine 300Mo de conso RAM au boot (et encore)... Donc bon meme si y'a le pilote de la carte graphique qui consomme & co, on a bel et bien besoin de bien 2,5 voir meme 3Go de RAM physique pour ne pas swappé avec un jeu comme Quake 4... J'imagine meme pas ce que va donner Enemy Territory : Quake Wars vu les screenshot qu'on vois

Sans compter qu'en 64bit, les logiciels prendront plus de mémoire (sur le DD et en RAM). J'avais entendu parler de 20%. Si c'est le cas un 2Go se transforme en 2.5Go, c'est pas à négliger. Si c'est pas le cas, ignorez mon post

le code prend plus de place à cause des pointeurs 64bits au lieu de 32bits,  mais dans un jeu c'est pas les dll et les .exe qui prennent 2Go, c'est les données

les textures chargées ont ptet une part d'espace d'adressage rien que pour elles nan? dans le cadre de l'AGP texturing, ou son équivalent en PCIe. en tt cas je pense à l'"AGP aperture size"

 
oui, en fait tu as bien 2Go par process, mais effectivement, le swap grandi avec ce qui alloué globallement, si tu colles plusieurs process qui remplissent leurs 2Go, le swap doit faire x fois ce qui dépasse.... (sans compter le fait qu'il est de l'espace mémoire non pageable dû au noyau & drivers). donc y'a pas de problèmes, sur un os 32bits le swap peut facilement dépasser 2Go (dumoins la limite par process), dû a la multitude de process et d'espaces non pageable.

Et yaura quoi dans ces données ? Yaura bien une partie d'entiers 64bit, non ?

 
tout à fait, l'espace AGP est à ma conaissance à la fois non pageable et non cacheable.
 
pour le PCI Express c'est plus subtile et sioux (et mieux en principe, ça doit être potentiellement cacheable et pageable mais pas sûr). disons qu'en PCI Express il n'y pas de GART et de notion d'espace AGP, si il y a une virtualisation mémoire (vu du GPU) elle est implémentée différemment et suivant les désirs du fabricant de GPU.

entiers/pointeurs, pour tout ce qui est structures du moteur (entitées du monde, etc, etc..), mais au niveau de l'occupation mémoire dans un jeu, je dirais que l'ordre de grandeur à la louche c'est 50~70% pour les textures, l'audio, la géométrie en virgule flottante (modèles...) qui sont invariants par rapport au cpu, 10~20% pour les structures du moteur et 15~5% pour les binaires en eux-mêmes (l'exe du jeu, la chaine de DLLs liées et encore l'espace peut être partagé) qui sont dépendants du cpu et qui peuvent croitre d'un passage de l'ia32 (x86-32) au x86-64.
 
sur les jeux modernes, les textures & co (les assets) n'arrêtent pas de croitre alors si ça trouve dans certains jeux ça fait ptet 95% de la ram consommée

Donc dans un jeu, le passage aux entiers en 64bit (dont les pointeurs) n'aura que peu d'influence sur l'occupation mémoire globale

 
Bah sur certaines plateformes (qui n'ont typiquement pas 2Go de ram pour stocker
leur code et leurs données), l'influence des pointeurs 64 bits se fait sentir un peu trop.
 
Et un pointeur 64 bits c'est des données pas du code.

en fait au passage au 64bits, la tailles des binaires/structures, en s'en fous un peu de la consommation mémoire, ce qui est plus notable comme contre performance, c'est la consommation en cache L1/L2 et en bande-passante mémoire. (et donc 20% de taille en plus c'est autant de taille perdue en "surface" de code caché et de volume de donnée perdue lors de parcours de structures ayant grandie lors du passage en 64bits)
 
d'ailleurs il est recommandé en x86-64, d'utilises plustôt des indices entiers pour offseter des collections (le int C/C++ reste en 32bits) que des pointeurs (forcément 64bits par défaut).
 
ie peut-être qu'avec les binaires 64 bits, l'écart sera plus important entre les athlons 64 qui auront un plus gros cache et le dual channel (s939/s754), qu'avec des binaires 32 bits.

 
En général quand tu recompiles un programme pour le support du 64 bits natif, tu ne changes pas la taille de tes entiers (ce qui n'apporterait aucun avantage à ton programme).
 
Tu travailles toujours en floats 32 bits, entiers 32 bits là où tu peux. Et en double précision, là où c'est nécessaire (mais la double précision c'est aussi possible sur processeur 32 bits).
 
Bref..

 
d'ailleurs je me pose la question de l'intêret du 64bits pour les consoles comme la Xbox 360, et la PS3.
sachant que l'une comme l'autre ont pas des Go de ram système & vidéo cumulés, et que le HD étant optionnel, on peut pas coder et budgetiser la charge comme si on avait un swap, quel est l'interêt ?  
 
mapper tout un DVD ou un Blue Ray en mémoire ?

Windows vista 64bits n'est pas destiné au grand public, ça reste un OS Pro

ça fait vendre ?
c'est pour faire aussi bien que la Nintendo 64 ?

 
J'avais plutot l'impression du point de vue de ma lorgnette que Microsoft allait pousser le 64 bits en profitant de Vista comme béquille.
("quitte à changer d'OS, prenez la version 64 bits" ).
 
C'est vrai que xp 64 bits à un peu raté le coche, la faute à plein de choses. Du point de vue utilisateur final, le 64 bits a un sens au moins sur PC.
Le débat est dans le genre : "est-ce que l'on peut mieux utiliser l'espace d'adressage ?", la réponse est "oui". Cependant l'inflation de la mémoire et l'existence de ces fameux pointeurs 64 bits fait que la pratique devient de plus en plus difficile et justifiable.
 
Mais avec le temps on oublie les avantages de l'addressage sur 12 bits .
 
LeGreg

 
C'est un peu comme ça que je le sentais venir aussi.

Moi aussi je pensais que Vista x64 serait le premier OS 64-bits grand public, avait sur le DVD la version x86 et x64, et que l'on choissise l'un ou l'autre à l'installation ça marche impec sans trop se soucier de quoi que ce soit.
 
Cepandant le pb c'est encore et toujours les pilotes... Faire cohabiter deux versions de meme qualité c'est difficile. Apres je ne sais pas si ca change grand chose pour NVIDIA/ATI de faire une version x64 ou si c'est juste un switch dans le build, mais c'est clair qu'un pilote graphique etant compliqué, Microsoft a peut etre choisi d'attendre encore un peu, déjà qu'il introduit un nouveau modele de pilotes graphique et DirectX 10 incompatible avec le reste... Faut pas non plus jouer avec le feu et des pilotes bancal pour le x64.
 
Bon apres c'est clair que les pilotes LAN & co c'est plus simple, surtout que le WDM existent encore

et bien en fait, l'évolution dans l'adressage et les règles de virtualisations et autres contraintes OS peuvent peut-être imposer un changement dans une partie du code, notamment sur l'aspect entrée/sortie/allocation/interruption, mais l'aspect génération/optimisation de code & états pour le GPU, ça ne doit pas changer.
 
hors ce qui est le plus changeant dans un pilote D3D, dû aux applications, je suppose que c'est justement surtout le générateur de code et les stratégies de config du GPU, ce qui est finalement indépendant de l'OS, donc une fois qu'ils auront une base stable sur l'aspect "administratif" de l'OS, y'aura pas plus de contraintes que la version 32 bits.

d'autant plus que d'après ce que j'ai compris avec Vista, le coté interruption/dma/misc sera au niveau kernel, et l'aspect génération code gpu & etats sera au niveau user pour limiter les aller-retour kernel<=>user (disons qu'avec Vista on a un scindage par design de ces aspects).

ya quelques détails (comme l'impossibilite d'installer des drivers non signé sur la version 64 bits) qui me font penser que Vista 64 n'aura qu'un succès limité auprès du grand publique (dans un premier temps au moins). Et puis pour l'instant, la version 64bits n'apporte aucun avantage pour l'usager courant.

D'après ce que j'avais lu Vista x64 sera une version indépendante (comme XP x64)

Nouveau SDK d'ATI en prévision de DirectX 10
http://www.presence-pc.com/actuali [...] x10-16347/

Euh, c'est pas le SDK sur lequel Tridam a fait un papier y'a quelques semaines ?

Le SDK semble dater de Mars 2006, donc c'est possible
 
NB: wahou, encore un comparatif d'écran LCD, vous etes des fous furieux !
 
edit:
5/4 quand on fait référence aux 19" et 4/3 pour les 20" non wide.
 
"réactivité dans les jeux (en SD, HD 720p, HD 1080p), rendu vidéo"
Je suppose que ce qui est entre () concerne le rendu vidéo.
 
"Pour ou contre le format 16/9 ?"
16/10
 
"C´ets l´inverse poru ce BenQ."
Mélangeage de doigt
 
"dans le menu OSD de l´écran, amis dans un menu caché"
Des amis dans un menu caché ?
 
"Encore une fois pas de surprise, [...] très mauvais dans le sens vertical." (page 12)
Paragraphe en double.
 
"ses réglages des couleurs par défaut sur et sur sa garantie des pixels morts"

Ah merde j'allais poster après avoir lu la conclusion que les 19" SXGA c'était du 5/4, mais en revenant je viens de réaliser que c'est ce que tu voulais dire, Fouge

Vidéos, 16/9 : corrigé, merci Fouge.

4/3 -> 5/4 aussi

 
Je comprends pas le rapport avec DX10 ? C'est 100% DX9 ce SDK.

C'est ballot..
 
Sinon vous pouvez télécharger le dxsdk de février ou avril par Microsoft avec des vrais morceaux de d3d10 dedans.
 
LeGreg

Oui mais tout de même, En fournissant ce SDK aux créateurs de contenu, ATI prend une longueur d’avance sur son rival NVIDIA

mmm... du D3D10 à la fraise  

MDR, y'en a qui prennent leurs désirs pour des réalités chez PPC ?

parlez moi de l yperthreading inversé    
 
 
ne fait on pas que deplacer la "problematique" sur le hard plutot que le soft ?

un peu hors-sujet mais bon
 
http://www.nasa.gov/mission_pages/ [...] eship.html
 
"A rough estimate to produce the 10 milligrams of positrons needed for a human Mars mission is about 250 million dollars using technology that is currently under development"
 
putain ça progresse la fabrication d'anti-matière
(si je ne me trompe pas, on pourrait faire le plein de la voiture avec environ 100 nanogrammes de positrons )

Quelle problematique ?

 
 
celle de la "separation" en deux part egale d'une application en 2 threads
 
(tu peux toujours ajouter un thread pour faire un truc qui au final n'aurait bouffer que 0.1% du processeur)
 
je parle d'un multithread efficasse apportant donc au moins 60% de puissance en plus