Reprise du message précédent :

C'est ce que je me suis dit après avoir lu

 
J'ai édité    
Sous OpenGL les versions ? Bas sous Windows on est limité à l'interface OpenGL 1.1 (Merci MS   ) tout le reste on le récupère via des extensions en allant questionner directement le driver de la carte 3D pour voir ce qu'elle supporte. Je sais pas si c'est de ça que tu veux parler, sinon en général les nouvelles versions apportent de nouvelles extensions ARB_XXX et intègre des précédentes extensions ARB_XXX au core. Par exemple l'extensions pour le multitexturing est apparue d'abord sous la forme SGIS_multitexture, a été intégré a OpenGL 1.2 sous la forme d'une extensions ARB_multitexture puis a été intégré au core dans OpenGL 1.3.
 
C'est de ça que tu voulais parler ou pas du tout ?  

C'est bien de ça que je voulais parler. Et comment on appelle le multitexturing sous OpenGL 1.3+ alors ? toujours par ARB_multitexture ?
 
Et sous un OS qui ne reste pas avec l'interface "obsolète" de OpenGL 1.1, ça marche comment ?

 
Non tu peux virer les ARB partout
Sinon avec une interface à jour tu n'as pas besoin d'aller taper le driver à la main via le mécanisme d'extension, tu utilises les fonctions (du core) de manière classique. Si c'est une extension tu vérifies qu'elle existe (en récupérant la liste des extensions supportées) et si c'est le cas tu peux l'utiliser.
 
Sauf sous Windows où le truc lourd en plus avec l'implémentation de MS c'est que tu dois récupérer les points d'entrée (i.e les pointeurs) vers les fonctions toi même via la méthode wglGetProcAddress () c'est pas la mort mais c'est vraiment pénible à force surtout pour faire du code portable où tu te retrouves à faire des #ifdef WIN32 un peu partout pour adapter le comportement à l'OS.

Je vois. en gros, c'est transparence pour le programmeur contre lourdeur quoi.....
 
Bon, ben m'sieur les programmeurs, c'est pour quand la librairie OpenGL GNU sous Windows pour schinter celle de MS qui est digne de l'appellation Neanderthal Technology ? ça pourrait être sympa, non ?
 
Remrque, y'a un autre hic pour la portabilité, mais là on sort du moteur 3D : les jeux OpenGL, il me semble que ça fait un bail qu'ils compte sur DX (Sound, Input et cie) pour fonctionner... non ?
 

 
oui.
 
quoique pour la souris/clavier il peuvent se contenter des messages de base (pas plus de 3 boutons pour les souris)
 
du waveOut (pas de positionnement 3D HRTF ni d'EAX, donc très caca), ou de l'OpenAL (3D HRTF+EAX, par contre sais pas comment est exploitée la couche eax)
 
pour le réseau les sockets de base (winsock)
 
pas de retour de force sans DirectInput, enfin y'a moyen de contourner pleinement le DirectX, mais bon ce serait bof bof...
 
disons que les alternatives viables et utilisées sont l'OpenAL par UT2003 et les sockets de base...
mais sachant qu'il n y que la ligne des Audigy et le nForce qui ont un driver natif OpenAL... (et que toutes les autres cartes son ont un wrapper OpenAL->DirectSound3D)
 
par contre pour Doom3, je sais pas ce qu'ils utilisent (faudrait que je regarde), car la musique sera composée en 5.1 (y'aura la version stéréo et 5.1 dans les ressources)

 
c'est pas faux non plus mais disons que force et de constater, que les effets des démos technologiques sont souvent utilisés massivement dans un moteur de jeu, 2/3 ans après les démos... (because manque de puissance)

enfin perso, je ne considère pas que DoomIII soit une classe Dx7, même si fonctionnellement ça l'est, parceque j'aime assimilier un "niveau de puissance" à une carte, et à un moteur donné.
 
donc si l'on considère qu'il faut une Radeon ou une Geforce Fx pour faire tourner de manière confortable perso je l'assigne à une classe Dx9. une geforce 1 bien qu'étant capable de faire tourner le bouzin, donnera une résolution de timbre poste pour une framerate convenable.
 
car dire que Doom3 est plus simple, oui à certains niveau, non à d'autres, au niveau approche des éclairage il y a un avant et un après Doom3, où le moteur peut simuler les éclairages par des texures, et tu peux avoir autant de texture par triangle qu'il y a de sources de lumières projectives, en plus des 3/4 textures de base (couleur+normale+coefs diffus/speculaire).
 
donc en palette de fonctionnalitée, oui Doom3 est plus "pauvre" que HL2 (l'embm essentiellement), mais en termes de charge (GPU ET CPU à cause des volumes d'ombre) j'en doute....

MagiSim> le problème c'est que cette partie du driver (celle faîte par MS) fait l'interface entre OpenGL et le système de fenêtrage pour pouvoir la refaire il faudrait donc avoir de sèrieuses connaissances sur le fonctionnement interne de Windows tu comprends pourquoi seul MS peux s'en charger (ils avaient promis une nouvelle version il y a trééééééééééés longtemps) mais ils ont d'autres chats à fouetter, OpenGL pour eux c'est loin d'être une priorité. Mais bon les développeurs se sont fait une raison et puis c'est pas si laborieux que ça non plus.
 

 
Tout à fait d'accord avec toi les cartes qui présentent de nouvelles fonctionnalités sont en général trop faibles pour pouvoir vraiment les appliquer pleinement et ça c'est le cas depuis un bon moment :
-La TnT avec le 32 bits (bon Ok avant il y avait eu la Savage et la G200 mais on va pas commencer à être tatillon : je prends les exemples nVidia parce qu'ils ont souvent été les premiers à promouvoir une nouvelle fonctionnalité)
-La GF avec le dot3 (c'est bien beau de faire des donuts Bump mappés mais dés lors qu'on commence à utiliser les Registers Combiners pour faire des effets avancés le fill rate prend un sacré coup et avec même pas 500Mpixels/s de base ça descend vite) ou avec un T&L assez anecdotique.
-La GF3 avec les shaders qui dés qu'ils étaient vraiment utilisés intensivement la mettaient sur les genoux.
 
etc etc...
Concernant les cartes DirectX 9 il y a de bonnes chances que ce soit aussi le cas mais il faut quand même reconnaître un certain mérite à ATI (je vais faire plaisir à quelqu'un là je sens ) qui pour une première carte supportant l'API semble être aussi à même de le faire convenablement. Je ne dis pas que la Radeon 9700 fera tourner les jeux DirectX 9 comme un charme je dis juste que l'impact sur les performances me semble (c'est une impression : j'ai pas de Radeon 9700 chez moi) moins dramatique qu'avec les générations précédentes.  
 
Il n'en reste pas moins que les jeux du futur qui se baseront sur les fonctionnalités de cette génération directement au coeur du moteur (comme le prochain moteur de Carmack probablement) et non pas pour ajouter un petit effet de ci de là, seront sans doute inexploitables sur cette carte tout comme Doom III est inexploitable sur une simple GF.
 

 
C'est une question de point de vue et je te rassurre de suite mon classement au niveau de fonctionnalités DirectX 7 n'est en rien péjoratif et je reste un grand fan du travail de Carmack. D'ailleurs pour moi Doom III, même s'il est moins "tape à l'oeil" qu'un certain autre futur FPS que je ne citerais pas pour ne pas me mettre plein de monde à dos , n'en reste pas moins technologiquement bien plus impressionnant.  
 
Disons que c'est un exemple flagrant qu'il ne suffit pas de se laisser porter simplement par la technologie il faut aussi savoir comment l'exploiter et construire quelque chose autour. Ainsi l'approche choisie par Carmack d'unifier les interactions lumières/surface au sein de son moteur force le respect et l'admiration.
 
Entre un moteur qui se contente d'appliquer sporadiquement quelques shaders DirectX 9 de ci de là et le moteur de Carmack qui se contente de "shaders" trés courts (ne nécessitant même pas la flexibilité qu'ils offrent) mais en fait une utilisation bien plus intelligente mon choix est vite fait. Il ne faut pas perdre de vue que le travail de Carmack sur la technologie de Doom III à commencer à la sortie de Quake III c'est à dire début 2000 s'il avait eu l'approche répandue qui consiste à dire "tiens on va mettre ce nouvel effet à la mode là ça fera branché" son jeu aujourd'hui n'aurait eu aucun impact visuel car les effets d'il y a 3 ans n'impressionnent plus. Au lieu de ça il savait ce qu'il voulait faire et ne s'est pas laisser distraire par des "effets de mode" intégrés aux API, ces dernières sont là pour s'adapter au moteur pas l'inverse et malheureusement c'est souvent le cas    
Bref comme tu peux le constater je suis un grand fan de Carmack donc loin de moi l'idée de dévaloriser son travail
 
Bon je m'emporte je m'emporte et je pars dans mes grands délires, faîtes pas attention ça m'arive souvent
Sur ce je vais plutôt m'effondrer sur mon lit là  
 

Globalement je trouve que els deux approches sont viables, on peut très bien, faire comme Carmack, baser son moteur sur une utilisation massive d'une technologie relativement simple pour la faire s'exprimer comme il se doit, et, avec parcimonie, profiter de quelques effets plus avancés. Non pas par effet de mode, mais parce que, par exemple, une eau plus réaliste, c'est toujours sympa. Dans tous les cas, et c'est bel et bien le plus hard, c'est de garder une homogénéité à l'ensemble, sans que cela ne mette à genou les ordis du commun des mortels fortunés.......  Le principe de lumièress dynamiques de Doom3 est franchement remarquable (:D) et rend excessivement bien. Mais il y a (encore) des inconvénients : soit on a une surface directement illuminée qui renvoie de la lumière à l'observateur, soit elle n'est pas directement illuminée et ne renvoie rien car il n'y a pas de gestion de la... radiosité, c'est ça ? (renvoie de lumière déjà réfléchie). Ce point me gène partiellement. Pas pour Doom3 ou un Resident Evil-like par exemple, mais pour un jeu plus ouvert, cela fait bizarre. A voir aussi, je me trompe peut-être. Il suffirait d'une illumination globale pour résoudre cela...
 
Enfin, tous les points de vues sont défendables, et à terme, il se pourrait bien que tout cela soit mélangé..... Quand on aura encore plus de puissance.
 
Sinon, pour parler des pertes de perfs sous DX9 des R9700 Pro, ça a l'air de se tenir convenablement........... Tomb Raider 6 ne voit pas de gain en passant en DX8.1, quasiment.
 
Les même commentaires ont, il me semble, été faits par Carmck en passant le R300 en codepath R200 (bon, Ok, on sait tous que Doom3 est OpenGL et utilise du shading simple massivement), et dernière par VALVe sur les benchs de HL2.
 
Dans le registre des cartes dont la nouveauté était exploitable, on peut, quand même, citer la Voodoo5.... certes ce n'était pas un hall de démonstration technologique, mais avouons que le FSAA apportait à beaucoup de jeux... C'est sûr, pas en 1600, mais de nombreux jeux étaient jouables en 1024*4x.... Ok, peut-être pas UT (le moteur laggait avec FSAA) ou Q3 (affaire de goût sur la vitesse/qualité).
 
Après, pour avoir du 60fps plus facilement, il fallait quand même se rabattre sur du 1024*2 ou du 800*4.... Ah, le bon vieux temps où j'avais du FSAA for free parce que mon PII 400 tirait la patte
 
On en est bien loin, et tant au niveau vitesse que qualité Vive la technologie !

moi je suis perdu avec toutes ces cartes!!!!
je tourne actuellement avec une gforce3 ti 200 over 500...
mon idee etait d'investir sur une 5900 fx ...
est-ce la bonne carte a acheter ?
faut il queje patiente un peu?
que vaut la carte Ati 9600 pro (171 euros)par rapport a la fx 5900 en pref et en prix....
merci

et www.hardware.fr pour les tests
 
Et moi je conseillerai plutot une Radeon 9800 (une normale, pas une Pro) si tu veux du haut de gamme.

 
Pour les performances de nvidia, c'est normal, confère tout mes autres posts. Les nvidias sont résoluments orientés shaders2, et dévoilent progressivement leur puissance en montant la barre plus haut. De l'autre coté, les ati plafonnent ce qui n'est pas dramatique, car un seul jeux directx9 est sorti.
 
Si on devait comparer les deux types de cartes, on pourrait dire ça:
Les nvidias, la puissance est bien la, on la canalise en fonction des types de situation.
Les ati, la puissance est brute, mais pas canalisable.
 
Pour le sujet sur "dx team", les pro ati réagissent n'importe comment, on l'a vu pour le bench half life qui n'a toujours pas été controllé, pour le mix mode nvidia, et aussi sur ces 50 pages de ces topic de révélations presse people exclusives.  
 
Les pro atis seraient prèt à raconter n'importe quoi pour rester crédibles. Si les fx se montrent beaucoup plus puissantes que les radeons xt sur les shaders2, tout le monde se rendra compte de leur petit manège, et que finalement ils y connaissent 0, zéro, nada, niet.  
 
Et je deviendrais, malheureusement, le martyre du forum ce que je n'espère pas car ça me déclasserait du troll contest of the year m'enlevant tout chance de passer à la postérité.  
 
C'est pourquoi je partage la profonde déception des qui habitent les atistes aujourd'hui, et que je désire de tout coeur (sans troller) que Ati sorte une nouvelle archi résolument orienté directx9 qui puisse rendre la donne aux fx.
 
Cependant, un signal peu prometteur a déjà été passé: L'équipe de développement d'ati a rendu les gants de boxes le mois dernier, en annonçant que dans tout les cas les radeons ne pouvait pas aller plus haut en terme de performances software.  
 
Ati a donc du mouliner, et grapiller par la suite quelques mhz avec ses xt (jusqu'a la limite du gpu), pour essayer de se hisser à la place de leadership sur le directx9.  
 
Malheureusement, on s'attendait à ce qu'ils sortent un lapin de leur chapeau, les impliquants réellement sur le marché, et le développement des futurs jeux, ce qui n'a pas été le cas.  
 
Les performances décevantes de leurs cartes ont entrainé le report de la sortie du jeu half life, jusqu'à une date indéterminée, pénalisant l'ensemble des joueurs ;(
 
Mais ce qui est important comme je l'ai déjà dis, ça n'est pas de se contenter des leçons journalistisques de anadtech et consort, ni de la puissance démonstrative, mais de la puissance éfficace et de la façon dont on peut s'en servir.  
 
Et ça, c'est le gros défaut de Ati en général, ce qui est en somme bien ennuyant pour des cartes fortement orientées directx8 qui devraient maintenant être capable de faire tourner des jeux directx9.

Oui oui    
 
Au fait, j'ai comme l'impression que tu te repetes la, tu l'as deja fait le coup de ATI est a la ramasse et nVidia va tout faire peter un jour (mais quand   ). T'aurais pas de nouveaux arguments techniques qu'on rigole un peu ?

Non pitié, pas d'arguements techniques, je vais mourir... de rire          
 
sans déc, j'en peut plus là    
 
tout les jours on croit qu'il atteint le fond... Mais tous les jours il repousse ses limites.... Tiens, ça ressemble à quelque chose d'autre    

disons que la Geforce Fx semble avoir du potentiel d'évolution, et que les Radeons sont presque à leur maximum de rendement...
enfin wait & see, on verra dans le temps comment ça se passera...
le fait qu'une 9800 noname (pas forcément pourri, marque chinoise importée n'ayant pas fait de pub en europe) à 250?, c'est pas dégueu au niveau rapport perf/prix...

Pour moi un jeu qui utilise des fonctionnalités seulement disponible sous DX9 (par ex PS 2.0) via l'API DX9 est un jeu DX9, même s'il n'en utilise pas tout le potentiel.
 
S'il y certain que les devs utiliseront plus de fonctionnalités DX9 avec le temps, ça m'étonnerai qu'un jeu utilise jamais DX9 à 100%.

T'as lu ce qu'il ecrit ?
Non visiblement, sinon tu dirais pas ca ...
 
Je rappele qu'au debut on a essaye de lui expliquer calmement et objectivement qu'il avait tord sur pas mal de points. Mais il a quand meme continue (et ca a dure des jours). Bref, y en a un peu marre la  
 
Et je sais bien que t'es plutot un pro-nVidia, mais c'est pas une raison pour defendre tous les integristes nVidiots du type de Nicolas_b.  
 
PS: ce message est pas anti-nVidia, ne pas le prendre comme ca  
PS': toi aussi tu penses que la TNT2 est la premiere carte a faire du T&L hardware

Il est de retour
N'empeche que canaliser la puissance, c'est trop dla balle il doivent utiliser une technique Shaolin!

Hardware & Lightning, Hardware & Lightning....  

Pour utiliser Dx9 a 100% il faudrait
utiliser les asynchronous queries (occlusion et events), les MET et les MRT, tous les formats de textures (signés non signés, four character code, flottant, compréssés), les nPatchs et les RT patches, le texture lookup dans le vertex shaders, les branchements et boucles dynamiques dans les vertex et pixel shaders, les centroides et les operateurs de derivations dans les pixel shaders, toutes les qualités de multisampling et la gamma correction lors du blending, la tesselation adaptative et le tracé de boites de dialogues GDI en mode plein écran.
 
Bizarrement j'ai l'impression qu'aucune carte ou aucun jeu ne va supporter tout cela en même temps .
 
LeGreg

 
Tu t'es lu quand t'as bu  

 
je parle meme pas du SHPRT qui n'est pas a proprement parler une feature de DX9 mais qui est poussé par Microsoft (normal: le papier d'origine par PPS qui travaille à Microsoft Research)
 
LeGreg

J'ai pas tout compris, mais je plussois..... Bon, sinon, pour me culturiser, est-ce que tu pourrais expliciter rapidement ce que sont les MET (MRT il me semble que c'est Multiple Render Target....), et les SHPRT ?
 
S'il te plait ?

MET : multielement texture si je me rappelle bien... Je sais pas trop à quoi ça sert à part pour stocker des résultats intermédiaires entre plusieurs passes mais vu mes connaissances sur ce domaine j'irais pas plus loin.
 
SHPRT par contre j'en ai jamais entendu parler.

 
MET = multi element texture,
c'est une texture qui permet d'écrire plusieurs couleurs (ARGB)par texels.  
 
SHPRT= spherical harmonics precomputed radiance transfer,
Dans la radiosité ce qui coute cher c'est le calcul de la fonction de transfert, le reste des calculs peut se faire en temps réel (Cf François Sillion). Peter Pike Sloan (de Microsoft research) utilise des fonctions de base (orthonormée) dans l'espace en coordonnées sphèrique (les spherical harmonics) pour stocker cette fonction de transfert de maniere compacte (au niveau de chaque sommet ou dans une texture). Calculer l'illumination consiste à se donner une description dans le meme jeu de coordonnée d'une fonction de distribution d'irradiance (lumière incidente extérieure au système -> pas de sources internes) et faire le produit scalaire des deux.
 
LeGreg

En gros ça permet de gèrer l'illumination globale d'un objet, non pas avec une bête lumière homogène, mais en tenant compte des éléments alentours ?

Tim Sweeney a dit qu'il allait l'utiliser massivement
pour l'éclairage statique de la prochaine version d'Unreal Warfare (donc pas UT2004 qui est bientot fini).
 
LeGreg

http://research.microsoft.com/~ppsloan/

 
Ok, en fait, si j'ai bien suivi, ça veut dire que c'est le complément idéal du dynamic lighting @la Doom3 : avec ça on aurait pas une impression de lumière directe ou rien comme on l'a actuellement ? Sans toutefois faire appel à des lightmaps précalculés par radiosité comme sur la quasi totalité des jeux qui sortent ?
 
ça ferait vraiment de la lumière dynamique réaliste ça    
 
On peut pas trouver une xemple quelque part ?

 
Je pense que Doom3 doit nécessiter énormément de fillrate. J'ai cru voir dans une interview de Carmack que certains éléments nécessitaient 6-7 textures superposées ce qui nécessite un fillrate énorme. A titre de comparaison il indiquait que le R200 pouvait effectuer ce multitexturing en 1 seule passe là ou il en faudrait 2 à 3 pour les cartes de type GF4.

ça en a l'air, oui.
http://www.presence-pc.com/article [...] =95&page=3

 
Reve pas trop elle n'a rien de dynamique pour l'instant.
Les coeficients PRT n'ont rien d'évident à calculer en temps réel.
 

 
j'ai passé un lien il me semble.
 
LeGreg

Au temps pour moi, je viens de le voir, merci.
 
SInon, j'espérais avoir de la radiosité dynamique. Snif, quand, mais quand ? Encore merci pour toutes ces précisions !

 
là ce n'est plus de la technique, c'est de la psychiatrie clinique  

 
Bof pas tellement, c'est purement logique.
 
On a deux cartes.
 
Les deux calculent en 32 bits sauf ... pour les cores des shaders.
 
- Les core des nvidia utilisent soit un mode 16 bits, soit un mode 32 bits (64 ou 128 bits en fait)
- Les core des ati utilisent quoiqu'il arrive un mode 24 bits(96bits)
 
Le mode 24 bits d'ati est completé par une unité logique, ou par l'api  qui peut fait aussi faire la convertion/complement abritraire  24bits -> 32 bits (masquage et shiftage des bits puis écriture en mémoire).
 
Au niveau programme, on a une api: Directx8 ou Opengl qui utilise des shaders 8/16 bits, Directx9 qui utilise et requière  des shaders 32 bits.
 
Quoiqu'il arrive les types de données sont toujours calculés en puissance de 2, et sont calqués sur la norme Ansi et conforme à l'IEEE: on a donc du 8/16/32/64/128 bits.  
 
bool  true or false
int  32-bit signed integer
half  16-bit floating point value
float  32-bit floating point value
double  64-bit floating point value
 
Directx utilise en mode high precision, des vecteurs ou des matrices de 4 floats.
 
Quand il a été question de passer aux shaders2, Microsoft n'a pas donné les spécificités assez tot aux constructeurs. Ils se sont posés la question, les shaders2 seront ils en 16bits ou passeront -ils en 32 bits.
 
Du coté de nvidia, la question a été résolu de cette façon: La carte gera aussi bien le 16 , que le 32.
 
Chez Ati, ils ont coupé la poire en deux:
32 bits - 16 = 16 bits / 2 = 8 bits
32 - 8 = 24 ou 16 + 8 = 24 bits
 
Le 24 bits d'Ati est née de ça    
 
 Plus sérieusement, historiquement parlant, les buffers des cartes grand publique utilisaient auparavant que 24 bits (colorimétrie) sur les 32 bits, les 8 bits restant étant reservé au canal alpha. Chose que l'on ne prendra pas en compte, tellement c'est devenu absurde d'utiliser du 24bits, avec l'arrivée des shaders.
 
 Ca serait donc beaucoup moins couteux de sortir une carte, et de lui rajouter une unité logique qui convertit les données au dernier moment, que des unités axé 32 bits qui ne seraient pas entièrement utilisées. Dans le meilleur des cas, l'Ati serait plus rapide en 16 bits, et dans le pire un peu moins rapide en 32.
 
Maintenant, si on regarde les conséquences que ça entraine au niveau des jeux avec les shaders 2, ça donne à peu près ça.
 
Chez Nvidia, le mode 16 bits est utilisé pour crée des petits shaders dynamique qui ne demandent pas des gros calculs, le mode 32 bit est utilisé pour les shaders complexes, par exemple les fonctions logarythmique ou exponentielle qui demandent au minimun 22 bits de précision.  
 
Pour ati quoiqu'il arrive le traitement est de 24bits.
 
Prenons un exemple vulgaire(fictif pour que tout le monde comprenne) avec une simple division. On doit donc operer une division qui doit donner un resultat avec un nombre de chiffres donnés après la virgule :
 
en 16 bits, pas de problemes, le resultat doit avoir 2 chiffres après la virgule et donne 2 chiffres après la virgule.
en 24 bits, pas de problemes, on a 3 chiffres après la virgule de demandé, et 3 chiffres après la virgule de renvoyé
en 32 bits, la division est effectué avec des nombres à 3 chiffres max après la virgule (le quatrième étant zappé), et la division nous renvoit un resultat avec trois chiffres après la virgule completé par un 0.
 
D'autres problemes interviennent avec des problemes d'arrondi sur le 0, ou sur les types de données signés en limite de typage, le signe s'inverse.
 
En gros, quand une Ati doit executer un shader en 32bits, les erreurs d'arrondi se propagent sur l'intégralité du calcul, il y a ce qu'on appelle un overflow ou underflow. Visuellement, il y a l'apparition d'artefacts, ou on peut dire simplement que les shaders partent en vrille.  
 
C'est assez flagrant sur le bench de anandtech de gunmetal2 qui utilise les vertex shaders2(qui peut requerir des fonctions mathématiques qui demandent une precision importante), on voit entre autre un probleme d'artefact au niveau du canal alpha et de la colorimétrie:
 
L'image en full precision 32 bits nvidia:

 
L'image avec les artefacts 24 bits ati:

Regardez la luminosité générale, la couleur du sol, des flames.
 
 
Anandtech a aussi parlé de ces artefacts: clignotement des textures des murs, disparition de l'eau, dans le bench de tombraider qui utilisent les pixels shaders2, sans savoir d'ou ça provenait.  
 
En fait, les shaders2 quand ils simulent le comportement de l'eau d'une façon à peu près réaliste, requièrent une précision 32 bits. Et lorsque l'on s'approche d'un mur et que ça clignote, c'est le z-buffer qui n'a pas une précision suffisante pour arriver à determiner la profondeur de champs. Ca entraine que les pixels se superposent(et donc disparaissent et apparaissent).
 
Toutes ces choses ne devraient pas arrivé, si le programme utilisait un mode dégradé de l'api directx avec les bias, complement, saturate etc... ou tout simplement si la carte ne masquait pas sa précision réelle. Dans ce cas, le compilo de directx refuserait tout simplement de compiler le shaders pour une archi 32bits.  
 
L'ide rendermonkey permet de transformer les shaders vers une precision amoindrie 24 bits pour les ati.
 
Mais bon Tomberaider, est un jeu qui est sorti à la va vite, non optimisé pour le 24bits ati, mais qui nous en dit quand meme assez sur les performances des ati en 32bits avec le path générique dx9.
 
Au niveau shader(je ne parle pas du reste), les cartes Ati sont donc plus lente en 16 bits(car elles opèrent le calcul en mode 24bits), plus rapide en 32 bits sur des shaders car elles font les calculs en 24 bits(24->32), et ne peuvent pas utiliser tel quel les shaders 32 bits.  
 
C'est entre autre pour ça, et à cause de l'exigeance des utilisateurs envers les jeux dx9, qu'Ati a eu des grosses sueurs froides. Tout le monde voyait le dx9 à la porte avec les radeons, alors qu'il était bien loin.
 
Ati en voyant ça, s'est rapprochés de Valve, createur du plus gros jeu de l'année directx9. Il aurait été plus bénéfique pour Ati que ça soit des jeux du style: tomberaider, etc qui sortent en premier car ils utilisent très peu les shaders 2, et ça aurait justifié au bout d'1 ans, que l'archi etant vieillissante, il faudrait donc passer maintenant en full 32 bits pour faire peter les shaders 2.
 
Mais la, ils etaient mal, le deuxieme jeu dx9 qui sort, c'est THE monstre qui va tapper directement dans les ressources de la carte graphique avec des shaders 32 bits.
 
 
Ca n'était donc pas dans l'interet d'Ati que le jeu sorte trop tot (imaginez tout le monde se rend compte que les radeons forcent le mode 32bits en trompant le compilo de l'api et font donc en réalité du 24bits ce qui entraine des bugs). En plus, dans l'état de half life, avec un path générique dx9 32 bits, les ati n'avaient clairement aucune chance.
 
Cette alliance leur a permis de commencer à implanter dans le jeu, un path 24 bits spécifique, qui corrigeait les problemes de calculs dont j'ai parlé au dessus en réduisant la precision générale. Path qui a été caché à la presse, jusqu'a la semaine dernière ou le leakage des sources a montré qu'un developpeur d'ati etait intervenu dans les phases de developpement. Dans ce mode 24bits, les nvidias ne peuvent pas avoir des performances équitables, et visuellement correctes.
 
 En fait, les nvidias font les calculs 24bits, à la vitesse du 32bits avec une qualité dégradée, tandis que les ati tournent à plein régime.  
 
Mais, bon tout ceci n'est pas le seul probleme des ati, il y a aussi le nombre d'emplacements pour les instructions qui constituent un fragment shaders: 160 pour les ati , contre 1024 pour les nvidias(qui collent aux spécifications fragment shaders 3).
 
Carmack avait d'ailleurs fait une petite reflexion en janvier, les shaders2 des ati sont plus rapides car ils sont calculés en 24 bits, la ou les fx font du 32bits, mais les ati atteignent rapidement leurs limites du fait du petit nombres d'emplacement pour les instructions ...  
 
Il a complété en parlant des modes dégradés, qu'il y a peu de chances pour que les jeux dx9 dans l'avenir utilisent que des shaders de faibles precisions (il parlait du mode 16bits, et 24bits pour ceux qui n'ont pas compris). Ce qui est tout à fait normal, car Carmack se bat depuis des années pour travailler avec des shaders 32bits et qu'il est en quelque sort le père spirituel des fx.
 
 
 
Tout ceci, n'est donc pas le fruit du hasard, Ati avait planifié la sortie d'une architecture qui devait introduire le directx9, et non le supporter à toc.  
 
En gros, les radeons actuelles supportent des petits shaders 2 simples quand ils sont optimisés pour, et parfaitement les shaders 1.x. Mais, ces cartes ne sont pas du tout faites pour supporter, les shaders 2 high precision 32bits de directx ou opengl, et des jeux qui arrivent.
 
Regardez un peu le parcours de ces cartes, ça fait quand meme 1 an qu'elles sont là, et elles ont gagné leur pari: faire tourner  les jeux de leur époque à des vitesses respectables.
 
J'espere n'avoir déçu personne, mais on le savait tous au fond de nous, que le trucage mathématique 24 bits, ne pouvait pas faire de miracle et était une solution provisoire à un probleme concret. Les shaders requièrent 23 bits de mantisse, 1 bit de signe, et 8 bits d'exposants.
 
 Combien de sites ont posé la question pourquoi "le 24 bits des Ati est plus performant que le 32" etc... Au point que le 24 bits était devenu quasimment la norme informatique    
 
Mais les articles ont zappés l'essentiel. Pourquoi Nvidia utilise des unités 32 bits pour des calculs qui demandent une précision de 32 bits. Pourquoi les gens qui travaillent dans les jeux vidéos et dans l'infographie utilisent du 32 bits au détriment du  24 bits.
 
Enfin, voila toujours est il que chez Ati, ils font bien marrer. Leur dernière invention pour tenir la route, c'est l'overdrive. En gros maintenant, ils overclockent les cartes pour tenir la route face aux nvidias, est ce qu'il faudra overclocker aussi les nvidias pour faire des benchs ? Et ça, bien que l'idée sortie du contexte ati vs nvidia soit séduisante, ça sent le cramage à plein nez, ou l'usure du matos acceleré.

Heink ??
 
LeGreg

C'est rien, il mélange juste la profondeur de couleurs (genre en 32 bits sous le bureau de Windows) et la precision en bits pour les shaders
Rien de bien pire que d'habitude ...
 
Cela dit, y a des trucs qui semblent plus crédibles que d'hab, bel effort. Ou alors, c'est moi qu'y ai trop bu (c'est pas impossible  )
 
 

y a-t-il un médecin parmis nous ?

Coupier Coller Powa

Y'z pas à dire, il a attentin un sacré degrés d'évolution dans la connerie
 
Kicéki lui explique que déjà DX9 ne requière pas 32 bits mais 24 bits ?
 
Kicéki lui explique la vie ?
 
on aurait plus de chances à transformer mon cheval en crack de la programmation que ce nain intellectuel en mozart de la 3D...
 
Il le fait exprés, spa possible autrement, hein, rassurez moi....