Reprise du message précédent :

 
http://www.studiant.be/salmonella/ [...] aarden.jpg

 
Nan, qu'ils commencent pas à faire des annonces comme nVnouille, je veux pas que 1% = révolution moi  

 
C'est de gens serieux chez ATI, il ne blablaterait pas pour rien  

 
C'est ce que je veux croire, mais à voir comment chez nVIDIA ils mythonnent, ça me fait peur  
 
Pour me consoler :
 
"Les spécifications de DirectX 9 mentionnent la nécessité d'avoir 12 buffers au moins pour le processeur graphique. Les FX 5800 et FX5900 n'en possèdent que 2 !"  
 
Source : Onversity : on comprend pourquoi les FX sont RIP sous DX9

Ca m'etonne pas, NVidia n'as vraiment jamais suivis DX à 100% alors bon

 
Ben ça c'est pas nouveau mais une fois n'est pas coutume je trouve (si j'ai bien comrpis et je pense que c'est le cas) que JF s'est extrêmement mal exprimé sur le coup (c'est assez rare pour mériter d'être signalé ) : il ne s'agit pas de "buffers" dont il est question là mais des registres temporaires. On sait depuis maintenant très longtemps que les GF FX peuvent utiliser 4 registres FP16 ou deux registres FP32 (c'est d'ailleurs la seule raison pour laquelle certains shaders FP16 sont plus rapides que les FP32 : parce qu'ils disposent de plus de registres temporaires mais au niveau du calcul ça ne change rien le nombre d'ops en FP16 ou FP32 est le même) sans perte de performance et qu'au delà les perfs s'écroulent ça c'est pas nouveau.
 
Mais là tel que l'expose JF et tel que vous semblez l'avoir compris ça signifie que nVidia est en dessous des specs DirectX ce qui est faux : on dispose bien de 12 registres ce n'est pas comme si lorsque en essayant d'utiliser trois registres temporaires le pixel shader refusait de compiler ou quoi que ce soit c'est juste que les perfs diminuent (assez drastiquement il faut le reconnaître).
 
Edit : Ah et le nouveau compilo HLSL de DirectX minimise lui aussi le nombre de registres offrant un gain sensible avec les GPU nVidia

c bien là le pb  

Oui, mais ça veut aussi dire que nVidia respecte les specif de DX et que Barbarella a donc fait une boulette dans son article.

 
Ben oui j'suis bien d'accord mais bon il ne faut pas le voir comme "Les GF FX ne respectent pas les specs Dx9" comme il m'a semblé le percevoir parce que ce n'est pas vrai. Un exemple un peu du même style : Dx9 spécifie 512 opérations dans un ps2.0 mais si j'utilise ces 512 opérations que ce soit sur un R3x0 ou un NV3x les perfs vont être lamentables. Est ce que ça veut dire que ces chips ne respectent pas les specs ? Non tout ce que les specs définissent c'est un nombre minimum de registres/instructions que les implémentations doivent supporter, une sorte de dénominateur commun que tous les chips doivent respecter pour être conforme à l'API. Elles ne garantissent absolument rien sur les perfs.

Ouais mais question à 23sous, si les 12 registres sont bien là..... Pourquoi ça ralenti à mort avec utilisation masssive de ceux-ci et pas chez les Radeon ? (à priori) ?
 
Sinon, on va frapper JF pour son erreur de mot. Mais ça vaudra jamais la fois où il a dit que Wolfenstein 3D avait ses murs bump mappés  

D'après ce que j'ai compris, les GFFX n'ont bien que 2 registres, les registres étant "émulés" par les drivers ou le GPU, c'est donc transparent pour le programme qui s'éxécute au dessus.

 
humm
 
 
oui je n'ai pas précisé ça parceque je n'ai pas voulu entrer dans les détails et je reporte a l'article de damien pour ça, mais comment tu fais pour avoir une précision > 16 bits (ce qui supposé être la normale en PS2) en ayant plus de deux registres par unité de calcul ? ben tu peux pas aux dernières nouvelles avec une FX. Il n'y a pas de refus de compiler mais ça sera plus lent.
 
aussi j'emploie les mêmes termes buffer ou registre c'est fonction de la ou on se place. d'un point de vue prog on parle de registre mais du point vue utilisateur j'essaie généralemnt d'utiliser le terme buffer. mais franchement la différence est arbitraire.
 
Par contre je reconnais que tout le monde se focalise sur les registre, et je ne m'y attendais pas, je vais donc revoir ça en étant plus précis. ce qui fait la lenteur des FX ce n'est pas avant tout le nombre de buffer, mais plutot le fait qu'elle ont du mal a éxetuer des opération en parallèle en mode 32 bits

 
tu tiens un carnet des conneries que j'écris merde, j'vais arréter d'écrire , puis non comme ça ça te fera remplir des carnets et tu devras dépenser des sous

si tout était parfait, ca serait trop propre et donc moins sympa et intéressant

 
merci, parceque je n'ai pas la prétention de ne pas faire de boulette, mais quand on me dit que j'ai tors généralement je defend d'abord ma position mais si j'ai vraiment tort je sais le reconnaitre (la boulet du Wolfenstein a été corrigé depuis cette discussion dont je me souviens ).
 
Dans tous les cas si je fais une erreur n'hésitez pas a m'écrire, je suis encore bien seul pour faire tout le truc et parfois c'est lourd. donc un p'tit coup de main par mail n'est pas de refus .

 
Nan, c'est la seule connerie que j'ai relevé dans tes articles fort bien faits. Cette erreur était d'ailleurs plus une erreur d'inattention qu'autre choses, alors ! Franchement, meême le dernier sur l'école m'a vraiment plu Moi, je dis chapeau bas JF ! D'autant plus que comme tu le dis, c'est du boulot, et il est bien fait !
 
Moi, j'ai qu'une chose à dire : J'-AD-MI-RE. Si, si, c'est vrai    
 
Mareek > On avait compris la même chose .
 
En bref, le pb des GFFX est donc la parallèlisation, le calcul lourd (FP32 qui bouffe plus ressources) et ce détail des buffers/registres qui est la cerise sur le gâteau.
 
Question : si ces registres sont émulés, peut-on parler de compliance DX9 qui en réclame 12 ?
 
Si oui, pourquoi une GF4Ti n'est pas DX9 compliant avec nV30emulate ? Ouais, je sais, c'est les questions de mecs pas chiant... Mais ça a son importance, non ?

 
Un shader avec 12 registres tourne, comme c'est prévu par DX9 donc on peut parler de compliance. Le problème de perfs avec plus de registres est juste "lourd".
 

 
Hehe on pourrait dire que les CPU sont DX9 compliant aussi
 
Sinon, les GeF4Ti ne savent pas calculer en FP24 avec nv30emulate. Vu que le FP24 doit être supporté au minimum pour une compliance DX9, les GeF4 ne peuvent pas l'être.
 
 
Mais bon ça reste très flou la compliance. On peut même se demander si c'est Microsoft qui la donne ou si c'est le fabricant qui se l'approprie.

 
Ben voilà c'est sur le terme "tu peux pas" que je ne suis pas vraiment d'accord : tu peux au détriment du fill rate mais pour le programmeur c'est totalement invisible. Au niveau de l'API le NV3x expose les 12 registres nécessaires, ensuite au niveau de l'implémentation hardware on en sait rien mais ça techniquement on ne devrait même pas à avoir à se poser la question vu que DirectX est là pour masquer tout ça. Un exemple les premières GF basés sur l'architecture NV1x pouvait utiliser deux Registers Combiners (+ le dernier gratuit) mais au niveau des performances c'était très coûteux ça n'empêche en rien le fait que ce soit possible. Ceci dit je ne défends pas le choix de nVidia je dis juste que ce serait leur faire un mauvais procés de dire que le chip n'est pas conforme à Dx9 pour ça.
 
Autre exemple (j'suis en forme) le R300 ne supporte pas toutes les permutations de registres de la spec ARB_fragment_programs mais il est capable de les émuler en plusieurs instructions c'est plus coûteux (théoriquement la permutation est gratuite) mais ça marche. Est ce qu'on peut l'accuser de ne pas être conforme à ARB_fragment_programs pour ça ?
 

 
Disons que j'ai fait la remarque parce que ça m'a pas mal perturbé lorsque j'ai lu l'article et pendant un petit instant je me suis demandé de quoi il était question.
 

 
Disons que le gros défaut du NV30 c'est qu'au niveau de la performance en virgule flottante sur les fragment programs c'est catastrophique : on a soit deux adressages de texture (non dépendant), soit une opération arithmétiques par pixel et par cycle. A comparer à un adressage de texture ET une opération arithmétique par cycle sur le R300. Si l'on ajoute à ça l'impact lors de l'usage d'un nombre trop important de registres sans compter que le R300 traite 8 pixels en parallèle contre 4 pour le NV30. Le NV35 améliore un peu les choses à ce niveau mais c'est pas la panacée (deux adressages de texture (non dépendant) et une opération arithmétiques par pixel et par cycle ou deux opérations arithmétiques par cycle et par pixel).
 

 
Oui parce que le programmeur "voit" bien douze registres à son niveau le reste n'a "aucune" importance. Ensuite t'as de ces questions toi entre une implémentation purement software faîte par le CPU et une implémentation devant jongler avec peu de registres tu vois pas la différence ? Bon

Mais alors, les bitboyz, je vois pas pourquoi ils se fatiguaent à pondre un chip 3D, ils avaient qu'à pondre un simple ramdac avec des pilotes qui font tout en soft avec marqué sur la boite :
 
"Minimum Configuration :
 
2.200 Opterons 848  
4GB RAM
DD space 200MB"
 

 
bon je vais résumer la situation car tu sembles vouloir comprendre de travers ce que je dis . Si on n'est pas d'accord ça va sérieusement compliquer les choses, mais je vois pas comment on va se départager.
 
A la question combien de registre spécifique a la programmation des shaders en FP32 disposent le NV35 : 2. Un shader qui utilisarait 12 registre peut-il s'executer oui. Comment fait-il pour foncitonner ? quand le nombre de registre disponible pour le shader est dépasser, les drivers / processeur vont puiser dans une autres mémoire de la CG, mais en impliquant des temps de latence bien supérieur.
 
 
Maintenant comme la NV30 dispose bien d'autant de registre nécessaire vu du coté progtrammeur, mais il ne sont pas tous du meêm type avec les même perf. Si le nombre de registre est bien de 12 et plus pouvant être gérer par le NV35 comme l'exige DX9. Les spec DX9 ne précise pas le type de ces registre (en terme de perf) et donc tu pourrais aussi bien les positionner dans le pot de confiture de la gramaire s'il était programmable et reli par réseau a a la CG
 
 
Maintenant il faut bien comprendre que dans mon texte il n'est dit nulle part que le NV35 ne satisfait pas aux pec DX9, et ce n'étati certainement pas dans mon intention de le dire. j'ajoute ça parceque j'ai l'impression que bcp de gesn lise le texte en pensant ça

z'avez pas mal à la tete ?

 
Je crois que tu as défini le fonctionnement de la plupart des processeurs.  
 
processeur x86 -> nbre de registres limités, fait les calculs en s'appuyant sur la pile et en utilisant des algorithmes compliqués à la compilation pour réduire le nombre de push/pop depuis la pile. D'où le besoin de qualité du compilateur pour tenir compte de l'architecture de la machine/carte graphique. Ca n'a rien de spécifique aux cartes graphiques et ce sera probablement de plus en plus comme cela.  
 
De plus si la nv30 (comme ce qui est spéculé) dispose bien de deux registres Fp32, ça ferait 256 bits de disponibles repartissable en simple ou double précision. (en gros 16 flottants à 16 bits de précision). Et ceci par unité de shader (dont le nombre dépend de la version du chip graphique).
 
1 - Il y a donc un cout certain a passer par une API qui ne reconnait aucune différence d'architecture et en spécifiant un seul niveau de registres. 2 - et on peut imaginer que la nv3x peut utiliser en fait beaucoup plus de zones lecture/ecriture intermédiaire que ce qui est spécifié par Microsoft (et c'est une nécéssité parce que les PS2.0 représente simplement la spécification des shaders unit d'ATI).
 
A+
LeGreg

moi si      

 
La GeForce4 Ti a des drivers de niveaux Direct X 9
puisque ce sont les memes que pour la Geforce Fx.
C'est à ça que servent les caps (pour ceux qui programment un peu sous DirectX).
 
On ne parle donc pas de compliance DirectX 9 pour une carte, ce qui ne voudrait rien dire mais plutot on les classe par type de features supportées. (sachant que de vieilles features sont dropées par les nouvelles cartes ou que le niveau de feature exposées peut varier d'une version de driver à une autre).
 
Microsoft ne décerne qu'une seule certification et c'est la certification WHQL.  
 
A+
LeGreg

Legreg : Tu confonds compatible et compliant.
 
Grâce à des bricolos de génie (:D) une Voodoo3 peut être DX9 compatible. Mais elle ne sera jamais DX9 compliant.
 
Maintenant, je ne parlais pas des drivers DX9 compliant des GF4Ti (vu qu'ils sont les mêmes que ceux des GFFX....) Mais bel et bien de nV30Emulate...... Une fonction des détonators XP d'il y à peu près un an, qui permettait d'émuler un nV30.
 
Quant à la certification WHQL, ce n'est qu'une certification des fonctions de base du pilote pour savoir si oui ou non il est stable sous Windows installé "brut".
 
Pour les définitions DX9 des PS 2.0, il me semble que ce n'est pas tout à fait le modèle d'ATI qui est utilisé, bien qu'ATI y ait pris une grande part. Il y a aussi d'autres choses, qui elles dépassent les spécifications minimum des PS 2.0. Par exemple, il supportent le FP32. Or, tu vois les Radeon en FP32 ?  Non.
 
Ce n'est pas parce que ATI a inspiré Microsoft que Microsoft n'a pas fait ce qu'il voulait, en plus...
 
Il faut penser qu'en principe un créateur de GPU travaille avec MS, lui soumet ses idées, et adapte +/- son design à ce qui ressort de l'API, c'est tout un travail d'échanges. Il ne faut pas croire que nVIDIA a découvert DX9 le jour de sa sortie. Ils avaient très certainement leur mot à dire.... a moins que tu ne fasse partie de ceux qui croient en une conspiration Microsoft / ATI... Tu me diras, en 2001, nombre de personnes étaient convaincus de la même chose entre nVIDIA et MS....

 
st'un topic troll de kalitaÿ ici
 
 
 
pas une succursale des nerdz de programmation  
 
 
 
 
 

Je vais réorienter le débat sur la trollerie en question:


Que ca serve d'illustration aux 2 pages techniques précédentes
 
[edit]
Oh mon dieu ils sont dégueulasses leurs gifs!!!
En haut: une beta de halo pour PC
En bas: tomb raider en utilisant ps1.1 puis 1.4 puis en bas 2.0
En vert: 9800pro   En bleu: 5900ultra
souce: http://www.gamersdepot.com/hardwar [...] op/001.htm
[/edit]

 
c koi cette bouillie de pixels ??

 
c une gforce sous dx9  

   
Le gars a du mettre un "antivol" sur ses gifs pour qu'on puisse les lire que sur fond noir. Sinon, on peut voir ici: http://www.gamersdepot.com/hardwar [...] op/002.htm

Y'a pas à dire.... ça schlingue

 
Non non je t'assure. j'ai aussi bossé sur des drivers..
 

 
Pour etre compatible il suffit d'avoir des drivers Dx6.
Tu sais le fameux modele DDI de Microsoft ?
Au debut le runtime fait un getDriverInfo32
pour recuperer les caps et il en deduit le niveau Dx. Le programmeur peut programmer sous Dx9.0 avec n'importe quel driver et n'importe quelle carte et il fait une demande de caps pour savoir ce qui est supporté ou pas par le hardware.
Par ailleurs une GeForce 4 Mx qui est du meme niveau qu'une GeForce 2 (carte de  "niveau" Dx7 si l'on en croit les dates de sortie donc) expose les Vertex Shaders dans ses drivers, fonctions qui ne sont devenus disponible que sous Dx8.
De meme pour tout ce qui est fonctions de captures de state blocks etc..
Ce n'est donc pas aussi simple que tu crois.
 

 
Non la fonction n'était pas dans les drivers et n'aurait pas pu etre utilisable dans un jeu. De plus si tu vois ce que j'ai dit plus haut tu vois que ta question n'a aucun sens.  
 

 
Oui et c'est la seule certification qui est delivree par Microsoft et elle inclut toute sorte de tests 3D je te rassure et notamment le respect des fameuses CAPS. Peu importe la version du driver.  
Ma phrase est à prendre au sens de "il n'y a pas de label de compliance Dx9 ou Dx8 délivré par Microsoft". Voila c'est plus clair ?
 

 
FP32 est spécifique à NVIDIA (pour ce qui est de la précision des shaders). Nulle part il n'est fait reference a un quelconque FP32 dans la doc/reference de Microsoft. Il y a juste un "indice" sur la partial precision mais qui ne spécifie pas la précision demandé par le shader ce qui est un gros défaut mais bon..
Et je peux t'assurer que de meme que les PS1.4 etait le mapping des hardware précédents d'ATI et les PS1.3 le mapping des fonctionalités du GeForce4Ti, le PS2.0 est un mapping très proche de ce que supporte les radeon 9x00.
 

 
Non je ne crois pas à une conspiration, pas plus qu'il n'y en avait une avant entre Microsoft et nvidia.
C'est juste du business.  
 
A+
LeGreg

Ok pour pa mal de choses. Sauf pour nV30Emulate. Tu peux faire tourner pa mal de choses avec. Notamment, avant la sortie des FX, nV avait fait un concours qui demandait de faire des démos nV30 grâce à nV30Emulate. Si des démos de particuliers le font, pourquoi pas des jeux ? Mais bon, quand on voit Dawn à 1 image toute les 5 secondes, bien entendu, ça donne pas envie.....

Dans le dernier joystick, au test matos de la GeForce FX 5600 Ultra revision 2.0, il y a des graphs avec aussi les scores des ATI 9800 Pro et Nvidia FX 5900 U. Est-ce normal que dans ces graphs, la FX 5900 U soit devant la 9800 Pro ?

c'était quels tests ?
 
pis c'est un mag papier

 
oh les tests habituels : 3Dmark 2003 v330, Code Creature, Quake 3, et UT 2003

b'en si c'est testé avec des pilotes pas trop correct du coté de nv ou un truc du genre

Ok :
3D Mark 2003 tut le monde sait que nV retriche. Mais Futuremark ne dit plus rien (sou-sous re-rentrent).
 
Code Creatures : Pixel Shaders 1.3 il me semble. Ou 1.4. Domaine où les FX s'en sortent bien. Pas de triche mise en évidence, mais qui sait.
 
Q3 : LE jeu complètement dépassé (350fps, lol) représentatif de lui-même seul (JK2, RTCW ou même les Star TRek et autre MOHAA ne nous diront pas le contraire).
 
UT 2003 : Triche sur le filtering mise en évidence....
 
Un peu léger comme test, non Vive les mags papier

 
Beuh, c'est dommage, c'était bien avant. Mais apparament c'est un nouveau qui teste le matos (caféine n'a plus le temps de s'en occuper à fond).
 
Le pire, c'est que je connais un boulay à la rentrée qui va me soutenir mordicus que "les nVidia sont plus performantes que les ATI, qui ne valent rien", suite à la lecture de ce test...