Reprise du message précédent :

C'est hacké pour 2K3 parce que ca le détecte sinon...

Parle

Si ce sont les mêmes unités de calcul qui font les calculs en FP16 et en FP32, il n'y a pas de raison que ça soit plus rapide en FP16, les unités de calcul sont juste sous exploitées.
 
Enfin, ça dépasse largement mes compétences dans le domaine, donc je vais plutot suivre la discussion et essayer de tout comprendre.

/me me souviens plus bien, mais /me crois avoir lu que les unités du GFFX pouvaient traiter 2 opérations FP16 ou une opération FP32.

 
1. Le minimum requis est FP24, mais pas quand l'attribut _pp est utilisé. Dans ce cas, le minimum est FP16. Si la différence est faible, c'est parce que ce sont les mêmes unités de calcul qui travaillent. Il n'y a pas 2x plus d'unités en FP16 qu'en FP32... C'est très logique. Le gain provient des économies de bp faites en FP16 et d'une meilleure utilisation des registres.
 
2. C'est obligatoire, même s'il n'y a pas d'opération FX12, les fragments doivent y passer. C'est le meilleur moyen de maximiser le rendement du pipeline. Pour s'imaginer le fonctionnement d'un pipeline, il ne faut pas penser letrjaet d'un fragment, mais bien celui du flux de fragment. la nuance est importante pour bien comprendre.
 
4. Flexibilité et performances sont liées. Plus de flexibilité = moins de performances là où la flexibilité n'est pas utile. Ce n'est que dans les cas extrêmes que la flexibilité est utile. N'oublie pas que dans un pipeline, tout doit avancer rapidement. Pas le temps de se poser la question de savoir comment organiser des unités.
 
5. L'exemple du GeForce 3 était là pour indiquer que les dérives ne sont pas nouvelles et qu'elles ont augmenté progressivement...
 
6. Si tu lis l'article, tu comprendras le pourquoi C'est peu puissant en floating car l'architecture n'est pas prévue poyr disposer d'une grande puissance dans ce mode.
 
Tes critiques me paraissent un petit peu trop présomptueuses...
 
C'est quoi cette insinuation à 2 balles comme quoi je me serais inspiré d'un topic de B3D ???? Marc m'a fait la même réflexion  Tout cela parce que j'ai placé les unités dans le même ordre ?  Au lieu de recopiage il serait plus intéressant de parler d'infos qui se recoupent... Si j'avais publié l'autre schéma plus complexe, personne n'aurait fait le raprochement entre mes schémas et celui présent sur le forum de B3D (que j'ai découvert via Marc, après avoir publié l'article)... alors qu'ils représentent exactement la même chose.

J'ai les oreilles qui sifflent arrête de parler de moi

 
C'est ce qu'avait laissé entendre NVIDIA au début, mais ce n'est pas le cas.

Le minimum requis est bien le FP24, le FP16 n'est jamais DX9, reconnu par Nvidia meme... Quant à 2* plus rapide, c'était les infos données par Nvidia aussi...
http://www.beyond3d.com/previews/n [...] x.php?p=24
 

 
Bien, on est pas d'accord
 

 
Heu? C'est bien de redire ce que je dis en d'autres mots, mais cela ne change pas. Performance et flexibilité ne sont pas liées. La flexibilité permet l'obtention de plus d'options, et donc il faut trouver celle qui est la plus efficace, la performance vient de l'habilité de l'utilisateur, et non de la flexibilité elle meme.
 

 
Si tu le dis....
 

 
C'est bien ce que je dis, c'est ta conclusion, mais cela pourrait etre un problème de bugs hardware, d'architecture, etc.
 

Parce qu'il n'y a que toi qui peut critiquer sans etre présomptueux?

 
1. NVIDIA n'a pas dit 2X plus rapide mais "jusqu'à 2X plus rapide". En tout cas, c'est ce qu'ils m'ont toujours dit. Et c'est 2X plus rapide en cas de bande passante limitée ou en cas de besoin de plus de registres, ce qui revient en fait au même problème de bande passante. Le FP16 estdéfini par Microsoft dans DX9. Tu ne veux pas le croire. Soit. Mais c'est ton choix à toi, pas celui de MS Le FP16 est défini par l'attribut _pp qui se place derrière les instructions. Mais le FP16 ne peut pas fonctionner par défaut et les puces doivent supporter au moins le FP24 par défaut.
 
2. Je vais pas te faire un cours sur les pipelines quand même Je reconnais que ce n'est pas spécialement facile à comprendre, mais si tu réfléchis en terme de flux de fragment, tu devrais comprendre.  
 
4. Plus c'est flexible, plus tu consacres des cycles à paramètrer ta flexibilité et plus tu désoptimises le pipeline. Ce sont des règles élémentaires en micro-architecture.
 
5. Bah là c'est à l'interprétation de chacun. Tu n'aimes pas l'exemple, moi je trouve qu'il illustre bien. Mais encore une fois, tout ce qu'il illustre c'est l'évolution de la politique marketing. En exemple ancien était nécessaire pour le clin d'oeil/extrapolation vers l'avenir.
 
6. Qu'est-ce que ça change ??? Bugs hardware ou problème d'architecture ? Dans les faits, l'unité de calcul floating point ne peut pas fonctionner en même temps que l'unité de texturing. Personne ne viendra contredire ça... (même NVIDIA ne nie pas) Ca vient du fait, à priori, que l'unité de calcul floating partage les même ressources que le processeur d'adresses floating alors qu'ils sont découplés sur les Radeon... Peut-être que NVIDIA va corriger le problème ou modifier l'architecture pour les découpler dans le NV35.
 
 
Bah, je pense que c'est moins présomptueux de baser son analyse sur des tests pratiques, des discussions avec des dev, de très longues discussions avec NVIDIA, ATI et MS que de se baser sur des pensées perso ou des lectures aussi bonnes soient-elles.

1-

 
 
http://www.beyond3d.com/forum/view [...] t=fp16+dx9
 
2- Désolé, je ne sais pas réfléchir    
 
4- Ben oui
 
5- Vi
 
6- Ca change rien au perf, ca change bcp sur les raisons
 

  Parce que mes lectures ne peuvent etre aussi bien que tes discussions?  

 
1. Le texte que tu cites fait directement mention au FP16 qui comme je le dis est défini par DX9 quand l'utilisation du suffixe _pp est utilisé. FP16 est correct dans DX9. Bien que les cartes puissent fonctionner en FP16 dans DX9, elles doivent par défaut travailler en FP24. C'est le développeur qui doit choisir d'utiliser le FP16 parfaitement autorisé dans DX9 mais avec le flag _pp... Ce qui n'est pas autorisé dans DX9, c'est le FX12.
 
2.
 
6. Pour moi, que le GeFFX ne puisse pas faire du FP en même temps que du texturing à cause d'un bug hardware ou d'une limitation d'architecture revient au même. Etant donné que les ingénieurs de NVIDIA sont loin d'être des clinches, je penche fortement vers la limitation/choix d'architecture que vers la présence d'un gros bug que NVIDIA n'aurait pas corrigé en 1 an
 
 
Je ne dis pas que tes lectures ne sont pas fiables. Je dis que c'est présomptueux de ta part de penser "savoir mieux" uniquement grâce à elles et de critiquer si surement ce qui ne colle pas à ce que tu as lu ou plutôt ce que tu as choisi de lire.

si j'ai bien compris, le FP16 fait partie des specs DX9, mais il faut suporter le FP24 pour être full DX9. Un peu comme les PS1.3 et 1.4 pour DX8.1

 
Pour être DX9, il faut être minimum FP24. Mais on peut proposer du FP16 comme possibilité secondaire pour améliorer les performances quand le FP16 est suffisant. Si un programmeur mets "addition", ça doit se faire en FP24 minimum, mais s'il met "addition_pp", ça peut se faire en FP16.  
 
ATI fait tout en FP24, qu'il y ait _pp ou pas.  
 
NVIDIA, en théorie, fait FP32 par défaut et FP16 avec _pp. Mais dans certains cas, NVIDIA essaye de faire du FX12 avec _pp...

bon, je pense qu'on parle pas de la meme chose. Pour etre certifié DX9, un il faut des FP 24 min. Maintenant, _pp est possible, mais alors ce n'et pas certifié. Le FX12 est aussi dans DX 9, mais pas dans le PS2. N'oublies pas que DX est backward compatible.
 

  le FX12 c'est DX8.1 (cf : http://www.hardware.fr/articles/431/page5.html ) alors que le FP16 n'apparait qu'avec DX9 même s'il faut gérer le FP24 mini pour être certifié DX9.

 
Tu joues sur les mots là... Quand on parle DX9, on parle pipeline de rendu DX9... Bien entendu, dans DX9, il reste le pipe DX8, DX7 et DX6...  
 
Si, _pp est certifié. Mais le chip ne peut pas être que _pp. Un jeu qui utilise _pp est certifié DX9. Une carte qui fonctionne en FP16 dans un jeu qui utilise _pp est certifiée DX9. Mais une carte qui fonctionne en FP16 sans _pp n'est pas certifiée DX9.

 
Exactement.

C'est plutot, une carte est cettifié DX9 si elle est FP 24 minimum. Le _pp n'entre en jeu qu'en option. Si Nvidia n'avait pas de FP32, elle ne serait pas une carte DX9. Par contre si elle avait que du FP 32 elle serait DX9. On voit d'ailleurs que c'est le cas pour la R300 qui fait du FP24 que ce soit en _pp ou non.
 
Sinon, ce que je veux dire c'est bien que le FP est introduit dans DX9, mais que le fait de pouvoir faire du FX12 n'enlève pas la certification DX9, c'est un plus comme le _pp.

http://www.beyond3d.com/forum/viewtopic.php?t=5372

 
Pour la précision minimum, tu arrives à dire exactement ce que je dis depuis le début Pas bien de chercher à contredire juste pour le sport
 
C'est là que tu te trompes ! Le fixed n'est pas pris en charge à la base par DX9 (et je parle de ps_2_0 et ps_2_x), même en option ! C'est le compilateur Cg de NVIDIA qu permet de le forcer En HLSL, les fixed sont interdits.

Ou je me contredis?    Tu me dis que le _pp suffit pour etre DX9, ce qui est faux. Il faut un FP24 minimum, c'est nécessaire et suffisant. Le FP16 n'est ni nécessaire et suffisant pour etre DX9. C'est Nvidia qui fait un compromis et non Ati.
 
 
Pour le PS2, certes on peut pas utiliser de FX12, et je n'ai pas dis le contraire. Je dis simplement que le FX12 n'invalides pas le fait d'etre DX9, c'est une option pour les anciens jeux tout comme le FP16 pour gagner en perf.  
 
Bon, débat clos pour moi.

pfff ça n'en finit pas votre discussion sur un détail moisi
 
DX9 ou pas, la geforce FX n'est pas adaptée zux jeux dx9

Si tu n'es pas content t'as qu'a pas lire  

Quels jeux ?

 
Ah t'as remarqué ça toi aussi.

J'ai pas tout compris aux discussions mais c'est l'impression que ca me donnait aussi  

tetris ?

+1 , il est pas mal

aquamark 3 euh 3DMark03 zut screen saver ATI aaahh: DAWN

 
En parlant d'AquaMark, met du temps à sortir celui là
Vu que NVIDIA est faché avec 3DMark, me demande pas si ils sont pas en train d'aider massive à faire que leur moteur ai des supers perfs sur FX

en FP16

spas DX9 dawn

justement

Dawn nude c'est un jeu Direct X X X X X X X X X    
 

Les spécifications du NV35 ?  
 
 
UTTAR un habitué du forum de nVNews qu'on pourrait presque soupçonner de travailler pour NVIDIA dit avoir reçu la liste complète des spécifications du NV35.  
 
Voici cette liste de Prévert :  
 
 
 
 
CineFX ( TM ) Shading Architecture  
 
Support for the Microsoft DirectX® 9.0 Pixel Shader 2.0  
 
Support for the DirectX 9.0 Vertex Shader 2.0  
 
Long pixel programs up to 1,024 instructions  
 
Long vertex programs up to 256 static instructions  
with up to 65,536 instructions executed  
 
Dynamic, conditional execution and flow control  
256-bit advanced memory interface combines a wider memory data path with next generation controller technology for superior performance and throughput.  
 
Full 128-bit, studio-quality floating point precision through the entire rendering pipeline with native hardware support for 32 bpp, 64 bpp and 128 bpp rendering modes  
 
Accelerated pixel shaders allow for up to 12 pixel shader operations/clock  
 
Up to 16 textures per rendering pass  
 
Support for sRGB texture format for gamma textures  
 
IntellisampleTM performance technology, a Hi-Res compression technology (HCT), increases performance at higher resolutions through advances in compression and anti-aliasing technology.  
 
Shadow Volume Accelerator ? accelerates shadow volumes by maintaining them more accurately and discarding useless information.  
 
Full nViewTM multi-display technology capability  
 
Integrated NTSC/PAL TV encoder supporting resolutions up to 1024x768 without the need for panning with built-in Macrovision copy protection  
 
Microsoft® Video Mixing Renderer (VMR) creates support for multiple video windows with full video quality and features in each window  
 
DVD and HDTV-ready MPEG-2 decoding up to 1920 × 1080i resolutions  
 
Dual, integrated 400 MHz RAMDACs for display resolutions up to and including 2048 × 1536 @ 85 Hz  
 
Dual DVO ports for interfacing to external TMDS transmitters and external TV encoders  
 
Dual internal TMDS encoders (one single and one Dual link) able to drive next-generation flat panel displays with resolutions greater than 1600 × 1200  
 
Digital Vibrance Control 3.0  
 
0.13 micron process technology for higher levels of integration and higher operating clock speeds  
 
40 mm × 40 mm, BGA 1309 flip-chip package  
 
Comprehensive Microsoft DirectX® 9.0 (and lower) and OpenGL 1.4 (and earlier) support  
 
DirectX and S3TC texture compression  
 
Si on en croit cette liste qui n'a rien d'officielle, mais qui est tout aussi indigeste que les traditionnels communiqués de presse, les principales nouveautés du NV35 seraient, l'interface mémoire 256 bits, l'accélération des ombres volumétriques et les pixels shaders accélérés qui en ont bien besoin !  
 
 
 
 
 
3dchips
 
 
bah grilled

Oui
 
Sinon la 9600 est pas top vis à vis des 5600 suis décu
 
http://www.hardware.fr/articles/461/page1.html

Et la 9600 Pro est bien poussive par rapport a la 9500 Pro
 
On pouvait certes s'y attendre mais c'est quand meme dommage

on s'y attendait, je comprend pas d'ou peut venir la larme de déception qui coule sur vos joues

Bah, je m'attendais que ce soit qd meme un peu mieux que cela. Surtout qu'ils ont poussé la pro Faut croire qu'ils voulait pas perdre sur la pro aussi....

Si la r9600pro avait éé superieure aux r9500pro,c'est carrément aux r9700 qu'elle aurait pu faire de l'ombre ^^

Evildeus > keske tu va raconter sur les comment de b3d toi, zont juste fait des tests de HSR avec Villagemark et glextrem c normal qu'ils tirent cette ccl