Reprise du message précédent :

...
 
moi aussi je l'ai vue tourner 500 fois ...
 
j'ai la sensation que si tu lances 10x de suite ca sera pareil mais entre 2 mois d'écart ca a changé, j'en suis SUR

2 mois sans l'utiliser c'est p-e ta mémoire

la fin du botmatch dans anubis:
 
y'a 2 mois ca se finissait dans la salle avec les compresseurs, et ces derniers temps ca se fini dans le couloir avec les fioles de +5 de vie ...
 
les actions des bots sont plus les mêmes et les changements de pt de vue non plus

ou la tienne  

ya pas un patch qui a un peu changé le benchmark justement?

 
Je dirais que c'est plutôt ça, ouais....  

 
 
   
 
 
Planquez vos chevaux
 
 
 

 
Pas que je sache, de toute façon il n'y a pas vraiment de contrôle de prècision avec l'extension fragment_program tout ce qu'on peut faire c'est placer un "hint" : ARB_precision_hint_fastest mais à ce moment là c'est à l'apprèciation du driver qui peut soit l'ignorer soit passer en FX12 pourquoi pas...  
 
Enfin je me suis pas vraiment plongé là dedans vu que pour l'instant je ne peux pas utiliser cette extension  

 
C'est un choix d'architecture. ATI a choisi de ne faire que du FP24 même lorsque ce n'était pas nécessaire ça a pas mal simplifié leur tâche sur certains points et leur a permis d'économiser des transistors, nVidia a fait le choix de la complexiité ils pouvaient se le permettre vu qu'ils visaient le 0.13µ maintenant je trouve normal qu'ils en tirent un certain profit.
 
Lorsqu'il n'est pas nécessaire d'utiliser le calcul en flottant ou la prècision maximale c'est normal que eux qui supportent des modes infèrieurs et suffisants puissent en bénéficier ça me paraît logique... Par contre après on est d'accord sur le fait que :

• Lorsqu'un programmeur demande la pleine prècision il faut l'utiliser.
• ça demande un peu plus de boulot mais bon avec les HLSL ce sera moins sensible et puis c'est dans l'habitude des programmeurs (moi j'avais perdu des points à un DS pour avoir utilisé un double là où un float s'avérait suffisant j'peux te dire que depuis je fais attention à la taille de mes variables )

Moi je reste adepte du "si ça ne change pas la qualité souhaité par le programmeur alors ça me va" en d'autres termes que le chip magouille tout ce qu'il veut en interne pouvu qu'il me sorte exactement ce qui était prêvu par le programmeur. Je trouve qu'on fait une fixation sur cette histoire de prècision et que ça devient un peu excessif : Ok sortir du FP16 ou pire FX12 là où l'on veut du FP32 ça conduit à une diminution de qualité et c'est inacceptable, mais dire qu'il est injuste de comparer deux cartes parce que l'une fait tout en FP24 alors que l'autre peut mixer plusieurs prècision sans perte de qualité là je ne suis pas d'accord, sinon on ne peut jamais rien comparer vu qu'en interne rien ne sera jamais identique.

 
Oui je connais    
Il y a une spec définitive ? Il y a un compilateur ? Non je ne crois pas. GL2 c'est pas encore pour tout de suite, en attendant le seul HLSL en OpenGL c'est le Cg.

 
Pour le split avec deux viewports ça doit se faire facilement non ?

 
Ce n'est pas moi qui ai markettisé le FP32.
Il est marrant de voir que nVIDIA l'a markettisé comme un bourrin, et que dés qu'ils peuvent, ils repassent en FP 16 ou en FX12... Ok, dans de nombreux cas le résultat est similaire. Mais c'est quand même dommage pour un chip sensé apporter cette évolution sans compromis........ nVIDIa avait raison en markettisant le FX : Nouvelle référence graphique : vi, FP32. Nouvelle référence de vitesse ? Ouais, en FX12 à la rigueur FP16. Mais nouvelle référence graphique et de vitesse ? Nan m'sieur, pas les deux en même temps.
 
Le rendu n'est pas le même qu'en FP16 et encore moins qu'en FX12. Sauf là où le FX12 suffit.
 
L'architecture du GeForce FX bidouille les utnités de telle façon qu'il perd la moitié de ses perfs en passant de FP16 à FP 32.
 
Est-ce un drame ? Non. Pas pour l'instant. certainement pas à l'avenir dans le sens où quand le FP32 sera utilisé, tout ce beau monde sera à la retraite....
 
 
 
Reste qu'un développeur préfèrera sûrement travailler avec un hardware qui se comporte tranquillement décemmant sans à avoir à le prendre par la main en permanence, plutot que de lui dire : là tu fais du FX12, là du FP16, là du FP32, là gniah-gniah...... surtout quand la différence de vitesse au final entre les deux est négligeable, comme celle de qualité. D'un côté, ça va tout seul, de l'autre le programmeur il perd du temps. Alors si il préfère le chemin tordu, il est maso le programmeur......................
 
Si au moins ça permettait au FX de prendre une envolée face à ATI ? Mais même pas ! (Sauf sur les benchs avec le gros tampon nVIDIA). Au final, il aurait peut-être vallut faire une archi qui soit moins dans les extrèmes, et qui soit plus simple à programmer..... Non pas que le FP32 ou le FP16 ou même le FX12 soient mauvais, non !
 
Mais pourquoi ne pas faire une archi, sans surprise, qui gère tout d'une seule façon ?
 
Le R3x0 il le fait aussi le FX12 (path R200), pourtant il en se tape quasiment pas de gain de perfs en retombant à ce niveau........... Alors ? Peut-on en déduire perfs bridées en FX12 ? Ou perfs en FP24 qui sont bonnes car y'a pas 36 unités, mais juste un certain nombre qui savent tourner indifféremment sous les deux ?
 
Enfin, pour en revenir aux benchs, va falloir t'enfoncer dans le crâne que pour comparer deux choses, tu leur fait exécuter le même code. Sinon, où est l'intérêt ?
 
Comme je l'ai déjà dit, on ne fait pas un sujet par étudiant lors des examens..... On en fait un par promo......
 
Il est normal que Carmack ai bossé sur les paths nV20 et R200 car les archis ont vraiment des niveaux différents en nombre de passes.
 
Mais entre les R3x0 et les nV3x, ça devrait être kif kif, je dirais même qu'avec ses PS et V 2.0+, les FX devraient en faire de la pâtée des Radeon.......... en ARB2............
 
MAIS, le nombre d'insctruction est tel que sur chaque archi le nombre de passes est de 1 tout le temps.
 
Mais, comme il y a une couille chez nVIDIA qui fait qu'une carte dés qu'elle est utilisée à fond se met à ramer sévère, le programmeur doit s'atteler à la tâche pour optimiser pour le moteur. Soit. Pas de pb. Pour le jeu....... Pas pour le bench.
 
Tu vas me dire que ce sera représentatif des perfs sous les autres jeux basés sur ce moteur...
 
Tu as vu les différences de comportement entre Quake 3 et les autres jeux sur le même moteur (JKII,  et cie) ?
 
Plutôt criticable donc......
 
Sinon, c'est bon  hein, la prochaine fois que j'ai un examen, je demande un sujet exprés pour moi, comme ça j'aurai une meilleure note...... Après tout...........

G mis tout ce temps pour m en remettre ma famille on envoyer un avis de recherche alors k en fait G T devant mon PC .....    
 
kan ils m ont retrouver aujourd'hui

 
est-ce qu'il sera possible de forcer le FP16 ou le FP32 par les  drivers alors ? ? ?

 
Kesse ki t'es arrivé ? Tombé sur la vidéo de HL 2 ?

 
Uttar (B3D) a pondu qq chose qui permet de le faire sur Dawn.
 
http://www.beyond3d.com/forum/viewtopic.php?t=6072

 
 
nop celle la mes parents ont fe venir le SAMU , pour me reanimé ,il y a 2 semaines.

Pauv' ti gars, va falloir que tu fasse un peu de sport pour te fortifier.... k'est-ce tu dirais d'un peu de dada ?
 

mouhahahahahahaha  
 
on dirait moi le matin devant le miroir pour me razer !!!

O faite,
Vous pensser à quand le nv40???
Dans 6 mois ou bien une evolution nv3x?

M'ouais, pas bien réveillé le matin quoi....
          \
           \
http://magicsim.dyndns.org/imgs/babapourmousse.jpg

kler
mais C LA VIE !!

Ouais, klair, et vive les WACANCES (encore 11 jours, encore 11 jours !

O tu as des actions chez le chouhal ou quoi laaaaa
On se demande ce qu'un gen peut bien regarder sur un site comme ca??

 
ben tu as bien de la chance, yen a qui bossent et qui ont pas de vacances.

 
Le second (en gros plan), c'est mon gros poilu à moi

 
T'inquiètes, encore un an et je serai dans le même cas (en maîtrise cette année.)
 
PS : suis parti pour être un collègue à toi.

 
Tout dépend en fait du nombre de registres utilisés, visiblement c'est ça qui influe grandement sur les performances des NV3x et comme on a deux fois plus de registres en FP16 qu'en FP32...
 

 
Comme je l'a idis lorsqu'on aura des HLSL ce sera nettement plus facile à mon avis. On peut utiliser la même technique sur les CPU : pourquoi utiliser des types char, short, int, long, float ou double ? Après tout on met tout dans un double on est sûr que ça marchera tout le temps ben ouais mais en contrepartie on a une perte de performances, de bande passante, etc...
 

 
Non le R300 fait tout en mode FP24
 

 
Tout dépend de ce que tu recherches... Ton approche consiste à voir quelle architecture aura les meilleures performances en général. Moi ce qui m'intéresse c'est en optimisant au mieux chaque architecture, en tirant partie de ses spècificités pour obtenir la meilleure performance possible laquelle s'en tire le mieux. Mon approche n'a peut être qu'un intérêt théorique alors que la tienne a une réalité pratique mais chacun cherche ce qui l'intéresse. Note que je ne demande pas forcément deux codes différents : il suffirait d'indiquer la prècision pour le NV3x, le R300 peut très bien ignorer les indications de prècisions et tout faire en FP24.
 
Le problème c'est comme Carmack l'a dit on ne peut pas se débrouiller pour faire faire exactement la même chose aux deux cartes, c'est strictement impossible ! Comparer les deux en mode ARB2 ? l'une sera en FP24 l'autre en FP32, tu me diras qu'on ne voit pas la différence mais qu'est ce que ça change : les deux cartes ne font pas la même chose donc c'est invalide à tes yeux, de toute façon même le FP16 serait sans doute suffisant pour Doom3. Et de toute façon c'est toujours comme ça et ça l'a souvent été : on ne sait rien du fonctionnement interne des cartes comment comparer exactement ?  
 
Certaines cartes avaient plus de prècision en interne que d'autres ça ne nous a jamais empêché de les comparer : les 3Dfx effectuaient le rendu en 24 bits avant de faire un dithering vers du 16 bits est ce que ça veut dire qu'on ne peut pas comparer avec du 16 bits nVidia ? Pourtant j'ai déjà vu ce genre de comparatifs. Sous Quake II 3dfx utilisait un code path spècifique non ? ils n'avaient qu'un mini driver alors que les autres avaient des full ICD ça n'a pas empêché les comparatifs. Pareil avec PowerVR qui effectue un rendu en 32 bits en interne et qui avaient aussi un code path spècifique... De la même façon les fragments shaders du R200 offrent une dynamique supèrieure que ceux du NV20 est ce que ça a empêché les comparatifs ? Connais tu avec exactitude la prècision des vertex shaders du R300 et du NV30 ? Non... Rien ne fonctionne pareil sur les deux archis si on voulait poser un cas d'école où les deux cartes feraient exacement la même chose on n'y arriverait pas.  
 
Alors pourquoi dénigrer Doom 3 en tant que bench pour ses code path spècifiques alors que de tout temps à jamais on a toujours effectué des comparatifs approximatifs ? Je répète ce que j'ai déjà dit : cette histoire de triche a un peu tout embrouillé, en ce qui me concerne je veux voir les deux archis utilisées à leur maximum : si nVidia gagne des perfs en utilisant du FX12 là où c'est suffisant grand bien leur en fasse, pourvu qu'au final le rendu soit tel qu'il devrait être.

 
Il a réécrit les shaderrs il me semble
Et surtout Dawn utilise NV_fragment_program qui permet d'indiquer exactement la prècision souhaitée contrairement à ARB_fragment_program.

 
L'intérêt est de voir la différence de vitesse justement.
 
 
Sinon, je vais simplifier un peu cette histoire. Il y a les développeurs qui préfèrent avoir du matériel sans surprise se comportant pareillement jusqu'à un certain degré de complexité pour pouvoir se concentrer sur les effets, et d'autres qui aiment faire joujou et indiquer au GPU si il doit pousser dans la vitesse ou la qualité au cas par cas, leur donnant l'impression d'avoir un surcroit de flexibilité.
 
Comme je l'ai déjà : ce serait plus simple d'avoir un compromis permanent qui permette d'avoir le meilleur des deux en permanence.
 
La flexibilité a un intérêt si elle apporte quelque chose par rapport à ce qui se fait déjà : soit la qualité, soit la vitesse. Or, tu prends une GFFX 5900 Ultra et un R9800 Pro sous Doom3, la différence de qualité est négligeable, la différence de vitesse loin d'être impressionnante.
 
Pour t'appuyer, tu prends les exemples du passé qui divisaient la programmation.... Mais, l'avenir n'est-il pas dans la simplification de la tâche ? Pour se consacrer au contenu ? LE contenu est de plus en plus riche et prend de plus en plus de temps. ce n'est pas pour rallonger la phase de programmation parce que chacun veut faire à sa manière.
 
L'efficacité, c'est savoir faire quelque chose qui nécessite le moins d'intervention possible, et qui sait faire un compromis. L'efficacité doit venir du constructeur lui-même qui doit savoir créer un chip pour son temps.
 
Les GFFX sont rapides avec les précisions basses, et ont les précisions hautes pour demain. Mais demain, à quelle vitesses iront-elles ?
 
Quand le FP32 sera démocratisé, les GFFX rameront, et les R3x0 se rabattront comme elle le font déjà avec des performances honnêtes pour l'époque. Sur les GFFX, ce sera : FP 16 en dessous niveau qualité, ou FP32 qui rame. Tu vas me dire : les développeurs pourront toujours appliquer selon l'effet... Et oui, mais, quand les jeux seront forcés en qualité max supportée par la carte, est-ce que les développeurs voudront toujours  optimiser pour les GPU de 2 ans qui soient tournent mal, soit sont en dessous niveau qualité si on s'occuppe pas d'eux ?
 
Et bien même si ils ne le veulent pas ils seront obligés.... Et zou, ils perdront du temps......
 
La flexibilité par la multiplication des options c'est bien, quand elles ne sont pas déjà des compromis..... Il vaut mieux à ce moment là avoir un compromis strict qui se comporte bien sans intervention.
 
Je suis pour la simplicité, mais pas au prix d'un capharnaüm.

sans être aussi calé que zeross, je sais au moins quelques trucs en programmation dont celui là : que ce soit pour un langage, une base de données ou quoique ce soit d'autre, c'est pas pour rien qu'on utilise des int, des float et des double. la langage qui n'utiliserait que des double serait foutrement lent.
 
en somme, les R3xx calculent tout en double alors que le nv3x dispose d'int, de float et de double plus précis que ceux des R3xx pour effectuer ses calculs
 
après, évidemment, si les nv3x s'en servent pour tricher, en remplaçant un double par un float voire un int, c'est dommage, mais par contre, si on enlève le côté triche, désolé, mais c'est bcp plus efficace de tout gérer comme ça, sinon, ça fait longtemps qu'on programmerait les jeux en Visual Basic
 
(int, float et double sont utilisés ici à titre d'exemple pour se rendre compte de ce que c'est, ça ne traduit pas la réalité exactement, juste un point de comparaison à peu près correct)

ya pas encore de specs definitives, mais elles ont l'air bien avancée si on croit cete page :

http://www.opengl.org/developers/d [...] workgroup/
 
et il y a aussi un compilo
http://www.3dlabs.com/support/deve [...] /index.htm

 
En effet, c'est bougrement efficace quand tu compare un nV3x qui fait tout en float et un nV3x qui fait tout en mixé. Parce qu'au lieu de faire quelque chose d'équilibré, les nV3x font du double trop fort pour ce qu'elles supportent.  
 
Tu compare à un R3x0, le double est pas si gourmand que ça devrait l'être.
 
Y'a pas de raison, sinon, tu verrais bien écrit en gros que quand le nV3x utilise le codepath nV30 il exploserait les R3x0... Ils sont plus rapides, mais loin de montrer une plus grande efficacité.
 
Pour moi l'efficacité c'est avant tout que le programmeur n'ait pas à se prendre la tête. Or, là, on a une archi qui impose au dév de se prendre la tête à moins de laisser l'archi se trainer comme un veau.
 
Quand tu fais un calcul en FX12 au lieu de FP24, tu es loin d'avoir le gain de vitesse observé en passant de FP32 à FP16 sur un GFFX.......
 
Pour la simple et bonne raison que c'est équilibré.
 
Dans l'informatique, le principal est l'équilibre. sans équilibre, t'es obligé de contourner, de bidouiller, de passer outre plein de trucs.... C'est le même genre de conneries que de voir un PIV 2.8 en magasin avec une GF4MX au cul (vu y'a pas encore si longtemps).
 
Là, l'équilibre requis est différent, mais c'est toujours cette notion d'équilibre.
 
Le R3x0, il s'en fout de tourner sur un jeu de niveau DX8 ou 9. FX12 ou FP24, il s'en bas les couilles, passez moi l'expression, il se content de faire son boulot sans rechigner.
 
Au moins le FP24 est utilisable à plein temps sur R3x0. Contrairement au FP32 chez nVIDIA.  
 
Je ne sais pas si vous vous rendez compte que le FP32 de nVIDIa est presque 2x plus lent que le FP24 chez ATI...............
 
Bref, tout ça, c'est une histoire d'esprit de clocher chez certain qui appellent ça de la flexibilité. Moi j'appelle ça markettiser une fonction non implémentée complètement.  
 
Y'a un hic quelque part, et je trouve débile que ce soit les programmeurs qui aient à s'emmerder avec ça.
 
Le GPU devrait être capable de proposer des vitesses potables pour ce qu'il propose. Vous me direz, c'est l'effet TnT + 32 bits...... On dit qu'on le fait, mais on dit pas à quelle vitesse.

 
Oui je sais, j'essaie un peu de suivre ça mais bon je me méfie lorsque je vois des specs "bien avancées" avec l'ARB quand je vois le temps qu'il a fallut pour valider les dernières extensions (vertex_program, fragment_program, vertex_buffer_object) loin de moi l'idée de critiquer parce que c'est très bien ce qu'ils font à l'ARB mais je pense pas qu'il faille s'attendre à voir quelque chose débarquer à court terme. Alors pour l'instant on a un HLSL sous DirectX c'est vrai mais sous OpenGL on a des specs que peu de monde connaissent et pas vraiment de compilo pour pouvoir tester.
 
3DLabs ménage pas ses efforts, mettre les sources du compilo c'est bien mais il manque le back end spècifique à chaque carte pour pouvoir commencer à tester. A l'heure actuelle il n'y a que les WildcatVP qui en ont un et je crois qu'il n'est pas vraiment à jour. C'est là que le Cg peut jouer sa carte vu que pour l'instant et pour encore un bon moment il n'y a aucune alternative sous OpenGL c'est pour ça que je n'étais pas d'accord lorsque tu disais qu'il s'agissait d'un langage mort né
 
Ceci dit c'est vrai que lorsque les deux API auront leur HLSL là ce sera plus compliqué pour nVidia de justifier de l'existence du Cg, il n'y aura guère que l'argument d'indépendance vis à vis de l'API qui restera et ce sera bien maigre.

Ben ça prouve que c'est une architecture flexible, c'est plutot un bon point
Si le FP32 n'est pas nécessaire, autant utiliser le FP16 et doubler les perfs
 

mais bien sûr
Dis moi, tu connais beaucoup de developpeur pour affirmer ce genre de chose ?
 

On peut en déduire que le R3x0 fait tous ses calculs avec les mêmes unités de calcul (que ce soit en fixed ou en FP)
 

c'est quoi le rapport ?

 
désolé, mais (toujours en restant dans nos équivalences, certes un peu rapides mais pas totalement fausses), un programmeur qui est pas capable de dire que telle variable a besoin d'être un double alors que pour telle autre, un int suffit, ben heu, c'est une programmeur de merde quoi

MagiSim>Il me semble que j'ai trouvé un peu mieux la source de notre désaccord, tout du moins en partie : on ne parle pas de la même chose. Je te parle d'une idée, d'un concept qui consiste à n'utliser que la prècision nécessaire pour une variable toi tu me réponds NV30 et R300. Il faut bien veiller à distinguer deux choses à mon avis : l'idée et son implémentation et ne pas se baser sur l'un pour juger l'autre. L'idée c'est d'avoir plusieurs prècisions pour les fragments, l'implémentation c'est l'architecture NV3x. Toi tu dis le NV3x est une mauvaise architecture donc le fait e pouvoir avoir plusieurs types pour les fragments est mauvais et là je ne suis pas d'accord ça veut tout simplement dire que l'implémentation du NV30 des fragment program est mauvaise ça je pense qu'on est tous d'accord là dessus. Dans un autre style une analogie serait de comparer avec la Parhelia. La Parhelia a été un précurseur dans pas mal de domaines et a implémenté pas mal de choses que l'on retrouve partout aujourd'hui comme par exemple un bus 256 bits. Pourtant si tu en juges par l'implémentation de la Parhalia tu pourrais juger que c'est inutile et pourtant...
 
Tu vois la nuance, donc comme je le disais on ne parle pas vraiment de la même chose. Mais rassurres toi dans le futur je pense que ça va dispraître parce que ce sera plus simple de gérer tout à la prècision maximale et qu'en plus si l'on en croît les rumeurs celà s'inscrit dans la logique qui consiste à partager des ressources entre VS et PS. On aura donc du FP32 partout mais je reste persuadé que l'idée de départ est bonne.

tout à fait d'accord.