Bon je ne l'ai pas encore vu posté ici mais avec tous les topics sur Doom III ça a pu m'échapper  
 

 
Clair net et sans bavure, alors que certains ne voyaient en John Carmack qu'un PR Nvidia celà met enfin les choses au clair. Après avoir défendu 3dfx du temps des Voodoo 1 et 2 puis nvidia du temps des GF John Carmack se range d côté d'Ati cette fois. Au moins ça prouve une chose, c'est que contrairement à ce que certaines mauvaises langues croyaient l'avis de Carmack n'est dicté que par des considérations techniques et non pas vulgairement commerciales.
 
En tout cas moi qui suis plutôt Nvidia sans tomber dans la "fanboyism attitude" je dois féliciter Ati car avec la Radeon, la 8500 et maintenant la R300 Ati a réussit à non seulement combler son retard mais aussi à supplanter Nvidia ! Enfin attendons de voir pour juger mais c'est un sacré beau coup du Canadien, entre ça et le retour de Matrox et de 3DLabs la concurrence se réveille dans le secteur de la 3D et ça promet

[jfdsdjhfuetppo]--Message édité par Zeross le 29-05-2002 à 00:11:54--[/jfdsdjhfuetppo]

carmack il est bien gentil mais ses paroles ne sont pas l'évangile.
quand il réclame des couleurs 64 bits à l'époque où le 32 bits nous ralentit encore, ça me fait pisser de rire!

   c vrai le dingue    je pense pas ke l'oeil en voit plus de 16 millions

 
t'as toujours pas compris que le combat 16/32 bpp ça influe sur la bande passante mémoire, car c'est le format du framebuffer, alors que le 64 bits réclamé c'est de la précision temporaire qui n'a aucune influence sur la bande-passante ?

 
heu ... ce dont tu parles c'est une prédiction/souhait (selon ). mais le texte là explique ce que c'est passé pour le choix de la carte pour la démo Doom 3 durant l'E3. y a pas de souhait, ni de prédiction.  
 
Il exprime un fait qu'il a vécu.

 
arf  .. grilled
 
heu tout ce que je peux dire c'est que je soutiens l'explication de bjone

peut-être mais ça a une influence sur le nombre de transistors nécessaires, et très peu sur l'effet visuel.

si les gens savaient qu'en S3TC tu as en moyenne 4 bits par pixel pour les textures, y diraient "putain c'est trop du pipo le 32 bpp alors"

Ce que peu de gens comprennent c'est que Carmack souhaitait surtout davantage de précision pour diminuer les artefacts lors de l'accumulation de passes. il voulait ainsi passer à un format de pixels flottants sur 16 bits. Vous noterez que d'une part les stations haut de gamme genre SGI offre déjà un format 48 bits (12 bits par composante) et que petit à petit on y vient sur PC (Parhelia et les RGB sur 10 bits). Bref Carmack n'est pas parti dans un petit trip à lui, il voit à long terme c'est tout.
 
L'oeil ne distingue pas toutes les couleurs reproductibles en 32 bits c'est vrai, mais en même temps le format RGB ne reproduit pas toutes les nuances que l'oeil peut distinger donc ce n'est pas un argument

 
là je suis plus d'accord....
disons qu'en multi-texturing lourd, plus des shaders dont les calculs sont +poussés avoir 16 bits par canal peut aider....
 
enfin le nombre de transistors évoluent beaucoup + facilement que la bande-passante mémoire... donc c'est moins un frein...

 
qu'est-ce t'en sait. tu peux me citer un jeu qui associe 8 texture et fait plusieurs modification d'éclairage dynamique avant de fournir le résultat final ?
 
le prob est là. Les dev limite actuellement le nombre de calul interne pour éviter d'avoir une trop grand perte de précision dans la couleur finale.

 
bon allez fo po toucher à carmack en ce moment

bjone a écrit a écrit : si les gens savaient qu'en S3TC tu as en moyenne 4 bits par pixel pour les textures, y diraient "putain c'est trop du pipo le 32 bpp alors"

 
putain c'est trop du pipo. abat le 32 bits

[jfdsdjhfuetppo]--Message édité par barbarella le 29-05-2002 à 00:24:38--[/jfdsdjhfuetppo]

Pour le 64 bits Carmack voulait quand même un backbuffer 64 bits avec un dithering vers un framebuffer 32 bits lors du swap des buffers. Dans ce cas ça aurait eu un impact direct sur les performances.

A tous ceux qui pensaient qu'ATI serait toujours à la bourre et aurait toujours des drivers pourris...    Faut dire que dans la 3D la roue tourne, avant-hier c'était 3dfx, hier Nvidia, aujourd'hui ATI....

 
ah tiens je ne connaissais pas cette précision, merci
 
mais pourquoi pas. D'ici - 1 ans on aura des DDR 256 bits a 400 MHz, soit sans recalculer du 25 Go/s de débit.  
 
Bah on verra bien ou ça nous même ..

peut-être mais 64 bits c'est du délire.
c'est bien de voir à long terme mais si ça doit empêcher de voir la poutre qu'on a dans l'oeil...
actuellement ça reste le nombre de polygones et la bande passante.
les fabricants sont en train d'ajouter les pixels shaders alors qu'on arrive déjà pas à afficher assez de polygones sans les utiliser.
déjà le T&L non-programmable c'était une connerie marketing temporaire dont le principal effet était de ralentir les cartes qui le géraient pas, maintenant y'a les vertex shaders. mais avant de faire faire plein de calculs à la carte, ça serait bien de commencer par avoir une carte capable de bouffer tous les polygones qu'un cpu récent avec SSE peut lui envoyer.
actuellement la politique (à laquelle adhère totalement carmack), c'est de laisser faire le moteur opengl, dont la version et les bugs dépend du driver et de la carte vidéo, et de tout faire bouffer à la carte.
On a des cpu capables de faire TOUS les calculs en dehors de l'affichage, au lieu de ça on donne tout à faire à la carte et on manque de bande passante.
a moins que nvidia soit meilleur qu'intel et AMD, je comprends toujours pas pourquoi on veut utiliser une API et des shaders différents d'une carte à l'autre au lieu d'utiliser SSE. A la rigueur si un jour on trouve une carte qui a du temps libre après avoir tracé les polygones, pourquoi pas...

[jfdsdjhfuetppo]--Message édité par wave le 29-05-2002 à 00:37:49--[/jfdsdjhfuetppo]

 
oui, mais avoir un back-buffer 64 bits ne serait utile qu'en cas de multi-texturing/blending (que ce soit du multi-texturing standard ou du pixel shader) intense qui ne passe pas par des registres internes à la carte...
hors les cartes vont être de plus en plus souple au niveau multi-texturing (regsitre de loopback etc etc...)
 
dans ce cas le dithering 64->32 vo mieux qu'il soit au niveau ramdac plustôt qu'un traitement buffer 64 -> buffer 32 (un peu comme les voodoo qui font du 32 interne -> framebuffer 16 buffers ditheré par dithering breveté -> ramdac 24 bits).
 
enfin on va y aller progressivement, d'autant plus que le hard peut augmenter en précision interne sans que ça impose la moindre prise en compte coté moteur... (c bo l'accélération hard qd même )

pour les beaux éclairages avec réflection spéculaire, on additionne tout en virgule flottante AVANT de commencer à tracer le polygone.
tu vas me dire que ça limite au gouraud au lieu du phong, je te répondrai qu'à quantité de calculs égale, on obtient un meilleur résultat en faisant du gouraud et en augmentant le nombre de polygones, ça permet de mieux définir la forme de l'objet.

pas besoin. au moment de l'affichage 32 bits suffisent. A la rigueur on peut monter à 35 bits pour etre parfait (à part peut-être avec les moniteurs qu'on aura dans 20 ans), mais mettre un frame buffer en 64 bits ça bouffe trop de bande passante.

j'attends de voir. les shaders d'ATI ont + de possibilités, mais si la rapidité ne suit pas ça servira pas. Un peu comme afficher du 32 bits sur une TNT1, c'était bien pour les screenshots
a la rigueur ça peut servir aux développeurs, mais ça nécessitera la génération suivante pour etre fluide.

Puisqu'on a dévié voici l'opinion de Carmack sur le 64 bits après tout tout le monde ne lit pas ses .plan et c'est pas avec tois lignes dans un magazine qu'on peut comprendre toute la portée de ce changement :

[jfdsdjhfuetppo]--Message édité par Zeross le 29-05-2002 à 00:52:36--[/jfdsdjhfuetppo]

 
parceque le SSE est un jeu d'instruction implémenté différemment de cpu en cpu, et que si tu voulais faire les choses bien, il te faudrait des routines SSE pour un athlon xp, une pour un p3, et une pour un P4.
rien qu'a l'heure actuelle.
 
alors qu'une API comme le D3D ou l'OpenGL te dégages de certaines restrictions, et te permet d'avoir une application dont les performances suivent linéarement le GPU.
 
Regarde Quake 1/2/3 => il sont fondamentalement T&L.
Ce qui fait que Quake3, profite gentiment des nouvelles cartes 3D même 3 ans après avoir été pondu.
 
Regarde Unreal => il est fondamentalement avec une géométrie logicielle.
Ce qui fait qu'il sature comme un ours même avec du matos récent.  
 
Quake 3 te donne du 300+ images/secs en 640x480 sur un p4 2.4ghz+gf3.
Unreal sature en dessous de 100 fps (alors que hum la charge polygonale est loin d'être supérieure)
 
Ensuite:

 
Si tu programmais en D3D eou n OGL, et qui tu faisais tes propres tests et lisais des docs de programmation de nVidia/Ati, il y a un goulot d'étranglement entre le CPU et le GPU qui est l'Agp.  
 
Quelque soit le débit vertex/secs qu'atteindra le CPU, ce sera bridé par l'Agp.
 
Ensuite même si il n'y avais pas cette restriction, à MEME année, la bande passante en local à la carte 3D est 5x à 10x (oui 10x) supérieure à ce que l'on peut avoir sur une carte mère.
 
Dans l'absolu, un GPU a la POSSIBLITE de monter bien plus haut qu'un CPU en géométrie...
Et il le font...
 
Il faut pas oublier une chose: déjà il y a toujours des GPU qui seront plus performants que des CPU en vertexs/secs, mais en plus les GPU ne seront pas pénalisés dans certains cas.
 
Par exemple, la normalisation des vecteurs normaux de chaque vertex est déjà quasiment transparente rien que sur une Geforce 1 (tu perds à tout casser 5% en performances géométriques à activer la normalisation automatique)

 
A quantité de calculs égale. elle est bonne celle-là. Ben on le sait que gouraud fait un interpolation sur des valeur et non sur des vecteurs. mais si on utilise phong c'est pas pour avoir moins de calcul mais plus de précision.
 
Pour s'approcher du BM de Blinn t'es obligé de prendre du phong ou un truc qui y ressemble.

[jfdsdjhfuetppo]--Message édité par barbarella le 29-05-2002 à 00:55:40--[/jfdsdjhfuetppo]

non!
le SSE sur P3/athlon XP est le même.
sur P4 aussi, rien à voir avec SSE2 qui fait de la double précision.

oui, c'est pour ça qu'on utilise la carte pour tracer les polygones, opération qui demande beaucoup de bande passante et beaucoup de registres, bref pas adaptée à nos cpu.
pour les calculs T&L il en est autrement: moins de bande passante, + d'opérations complexes auquelles SSE est parfaitement adapté.
En parlant de bande passante AGP, bizzarement les voodoo sans T&L n'avaient aucun problème de ce côté-là.
 

unreal sature à 100FPS (c'est pas grave), si on y met une grosse carte vidéo.  
mais l'évolution de nos machine ne se limite pas à la carte vidéo, les cpu progressent autant.
et puis ça m'étonnerais qu'unreal exploite pleinement SSE, vu l'époque où il est sorti.

c'est pas mortel non plus pour un cpu comme opération. Par contre un éclairage spéculaire prend du temps à une gf1.
et puis le cpu peut calculer PENDANT que la gpu trace un polygone. Ca devient difficile de juger ça parce qu'avant la généralisation de SSE les moteurs étaient déjà orientés T&L hardware, mais franchement je suis convaincu que j'arriverai à fatiguer une carte vidéo récente uniquement avec le tracage de polygones quand j'aurai optimisé mon moteur SSE. Avec tous les avantages que ça comporte: meilleure compatibilité d'une carte à l'autre, coordonnées après transformations connues par le cpu pour les tests de collisions, possibilité de subdiviser les polygones manuellement là (et uniquement là) où on en a besoin (éclairage, forme courbe,...).

[jfdsdjhfuetppo]--Message édité par wave le 29-05-2002 à 01:06:26--[/jfdsdjhfuetppo]

enfin tout se défends...
 
wait & see....
 
enfin tout l'art du hard, c'est d'être adapté aux besoins du moment, un peu en avance mais pas trop
 
enfin dans 2/3 ans, les CG auront certainement un cache à framebuffer de porc en interne (les bitboys étaient cho pour foutre 32 mo dans le core du chip graphique avec un bus de 1024 bits alors....)

ce que je dis c'est que le phong augmente fortement le nombre de calculs par pixel. Autant augmenter le nombre de polygones suffisemment pour atteindre le même résultat visuel en gouraud au niveau de l'éclairage, ça permet d'affiner la forme des objets sans finalement faire + de calculs.

heu,
 
le débat il est ou là ? sur l'interet de faire calculer le CPU plus que le GPU ?
 
Le CPU pourra pas suivre. enfin lui peut-être mais les transfert entre CPU/GPU non. Y a pas que la bande passante, y a aussi les temps d'attentes.  
 
Entre un accès d'une info entre GPU et sa RAM, et le GPU et la RAM de l'ordi y a un monde !

oui, mais je soupsçonne que l'art du hard deviennt dicté par la marketing: augmenter le nombre de fonctions pour vendre davantage que la concurrence. Ce qui m'a beaucoup déçu c'est les gf1 qui demandaient beaucoup au cpu et à l'AGP par rapport à une voodoo. Ce qui était un peu contradictoire avec le but recherché.
Mais bon on verra bien, faut que je finisse mon moteur

ce monde est largement rempli par le temps de traçage d'un polygone. surtout que pendant ce temps la RAM vidéo est déjà fortement sollicitée.

 
c'est vrai que ça se défends, toute solution a ses avantages & ses inconvéniants...
 
par contre pour le SSE je suis pas d'accord, le jeu d'instruction est supporté par tous les CPUs, mais chaque CPU a un flux d'instruction optimal qui lui est propre.
C'est comme le MMX, tu peux cibler différents CPUs.
 
Une voie CPU impose plusieurs variantes pour chaque implémentation de processeurs...
 
Alors qu'une voie GPU reporte un code source "asm" (dans le cas des Vertexs Shaders/Pixels Shaders) qui va être compilé par le driver.
 
Fondamentalement, une voie CPU souffrira d'une restriction d'évolution.
 
Ce que tu écrits comme code SSE comportera ptet des contres-optimisations pour un P5 ou un Hammer, tout comme du code "486 ou Pentium" ont pu être des contre-optimisations pour un Pentium Pro...
 
Après fo peser le pour et le contre...

mouais en général les différences de vitesse sont assez faibles entre un code générique à peu près adapté à tous les cpu et un code spécifique à un seul cpu. Mais bon on verra ce que ça donne.

 
Je comprends, mais il y apparement une différence de fonctionnement que tu n'a pas saisies entre gouraud et phong.
 
L'augmentation de poly peut-être une solution pour gouraud pour des surface lisse, une sphère par exemple (exemple classique). mais pour des surface en relief, la faible précision qu'offre les calcul de gouraud n'est pas suffisante pour faire du BM.
 
La raison essentielle :
 
Une fois que t'as fait la moyenne des normales, gouraud considère que la direction de l'aclairage est constante sur le poly a shader. Si t'applique ça sur du BM t'es mort, parceque la direction varie en permanence.
 
Ensuite, la meilleure précision qu'on peut obtenir avec le BM c'est d'utiliser une normal map (bum map décrite qu'avec des normal). A partir de la tu peux faire des tas de calcul vectoriel avec des élcairages.
 
en fait on verra bien. apparement Doom3 utilisera un BM de type Dot product qui normalement est associé a du phong.  
 
Maintenant si tu trouve une méthode pour faire du BM, je ne parle pas de surface bien gentilles, bien lisses, avec du gouraud, alors c'est cool

Par contre fo savoir que Doom3, même si Carmack prêche le tout OpenGL (mais fo pas rêver l'algorithmie est loin d'être baclée), il y a quand même un pan majeur du moteur qui est complètement dépendant du CPU: La génération des volumes d'ombres.
 
Actuellement il n'y a pas de support Vertex Shader ou autre pour faciliement et efficacement déterminer les arrêtes de volumes, arrêtes à partir desquelles on détermine les zones d'ombres...
 
(Enfin comme d'hab il y en a certainement un max qui est précalulée, ou rafraichie à une fréquence limitée, comme les Cube Maps des jeux...)
 
Tiens d'ailleurs Wave, par voie CPU, comment tu fais pour du Cube-Mapping ? Là je crois que c'est cas chiant.

 
Exact mais sur Athlon, Duron ? On retombe sur le même problème : le chaos général dans lequel évolue le monde PC avec ses normes différentes qui ne sont finalement adoptées qu'au moment où elles ne sont plus utiles.
Et puis ne crois pas que Carmack qui est toujours à la recherche de nouveaux moyens d'optimise son code n'a pas expérimenté le SSE :
 

 
Oui mais une fois que tes vertex sont transformés par le CPU il faut bien les renvoyer au processeur graphique via le bus AGP ? Sans compter qu'à chaque nouvelle passe (même si c'est moins fréquent désormais grâce aux loopbacks) tu dois retransformer les mêmes vertex et les rebalancer via le bus AGP. Les Voodoo n'avaient pas de problème car les jeux de l'époque (et les jeux actuels) étaient ridiculement faibles en polygones dés que tu commences à compter en millions de poly/s la bande passante devient un facteur primordial et vu les performances de l'AGP....
 

 
Oui les processeurs évoluent mais certaines choses n'évoluent pas notamment la pénalité lors des accés mémoire et la baned passante de cette dernière. Et puis entre une GF (15MVertices/s théoriques et une GF4 110MVertices/s) on trouve un rapport de 7 je ne suis pas sûr que les CPU d'aujourd'hui soit capables de traiter 7 fois plus de vertices que ceux de l'époque de la GF (Athlon 600 si ma mémoire est bonne).
 

 
le moteur T&L calcule aussi pendant que les polys sont tracés tout est entièrement pipeliné dans le GPU.

j'avoue que ça reste une question à creuser (y'a pas de miracles, on peut trouver des inconvénients à ma méthode).
Faudra jongler entre augmenter fortement le nombre de polygones (mais bon ça risque d'arriver avec toutes les méthodes, vu la puissance de calcul qui grimpe), et les méthodes de bump associables au gouraud (moins maitrisables pour l'éclairage spéculaire). Pour l'instant y'a pas trop de phong dans les jeux, on verra aussi comment ça évolue.
en fait je vois mal une carte qui fait du phong sur tous les polygones avec plusieurs lumières avant un certain nombre d'années.

[jfdsdjhfuetppo]--Message édité par wave le 29-05-2002 à 01:26:27--[/jfdsdjhfuetppo]

 
Là je suis ceptique quand même
 
On voit bien ce que ça a donné sur l'évolution 486/Cyrix/Pentium/PentiumPro/Athlon/P4.
 
Un code idéal pour un CPU en est loin de l'être pour un autre...
 
Le seul cas "propre" était le passage du 486 au Pentium, ou l'on pouvais optimiser pour le Pentium au niveau entier sans trop pénaliser le 486...
 
Mais tu prends par exemple un match Athlon/P4....
 
Si tu fais des routines ciblés Athlon, les gars qui ont des P4 hurlent...
Et inversement si tu fais des routines optimisées P4, les gars qui ont des Athlons crient au scandale (intel vendu, tout comme on a entendu 3dmark2001 vendu à nvidia)
 
C'est comme le Cyrix P166+ qui d'après PC Achat allait aussi vite qu'un Pentium Pro 150 sous Word, ce qui était vrai, mais ce qui était aussi vrai c'était que  sous Quake 1 ou un soft de calcul maths dont le flux d'instruction FPU était un peu optimisén, un PPro 200 alais 2x-3x plus vite qu'un Pentium 166 qui laminais le Cyrix....
 
C'est un peu ça le problème de l'approche CPU, alors que dans le cas de la 3D, tu peux facilement extraire des primitives rentables à cabler, et dans le cas de code asm comme les Vertexs/Pixels Shaders, le driver embarque un compilateur optimiseur ciblé pour le matos du fabricant...

prenons un exemple
 

 
tu peux charger la démo ici  
 
http://www.ati.com/developer/indexsc.html
 
Une équipe allemande du Max planck institut fait la même chose avec une GF2 (ils l'ont fait avant d'ailleurs), mais il propose une méthode software du DM pour implantation en hardware.
 
PDF ici
 
http://www.mpi-sb.mpg.de/~jnkautz/ [...] ntGI01.pdf
 
 
Franchement sans DM est faire les calcul essentiellement en CPU je vois pas comment c'est possible

[jfdsdjhfuetppo]--Message édité par barbarella le 29-05-2002 à 01:32:22--[/jfdsdjhfuetppo]

je parlais d'une comparaison voodoo5/gf1 ou 2 sur le même jeu.
La voodoo5 se contente d'un bus PCI sans ralentir.
en fait le cpu va calculer les coordonnées/couleur d'UN point pendant que la carte va tracer un polygone de 10*10 pixels avec plusieurs couches de texture. Alors heureusement que la mémoire vidéo va + vite!
 

ce facteur 7 n'est surement pas vérifié en faisant la même quantité de calculs sur chaque polygone. Il suffit de regarder le nombre de transistors et la fréquence des gf1 et gf4.