Reprise du message précédent :
J'ai survolé rapidement le forum.  
 
Et j'ai apperçu qu'on parlait d'un directx optimisé nvidia. C'est plutot burlesque parce que jusqu'a maintenant directx etait plutot orienté ati, mais bon ...
 
 Si microsoft fournit enfin une api potable qui prend compte les spefs du matos, en fait, s'ils font leur boulot, ça sera tranquille. Ca leur donnera peut etre une chance pour ne pas se faire ecraser par l'opengl. Par contre, Ati je sais pas ce qu'ils vont inventer , un cable spéciale pour brancher la carte sur du triphasé, ou un bundle kleenex ?

On sera ravi de t'accueuillir dans le club des vioques  

On t'a connu en meilleure forme, c'est même pas drôle

Clair, tous les moteurs 3D de jeux qui sortent en OpenGl en ce moment, c'est la folie !

 
Bah ça peut plus être drôle. Encore, il y a 1 mois quand tout le monde démolissait les nvidias, je passais pour un allumé.  
 
Pour arriver à faire la meme performance, il faudrait que je fasse dans l'irréel. Hors c'est pas possible, nvidia progresse c'est un fait, et tout les perfs nvidia et ati sont plus ou moins homogène.

presque objectif ?  

Ouais et c'est bizarre

Bof, non c'est pas bizarre, la j'ai pas de matière pour travailler.
 
Le topic Half life m'ennuye, en fait j'ai pas d'affection particulière pour ce jeux.  
 
Tout le monde a été bien calmé après son report. Et je passe une partie de mon temps libre à profiter de ma ti 4200 qui se comporte comme un charme dans tout les jeux.

Je te rassure, c'est toujours le cas

Ben ça te génais pas avant

 
Fait gaffe à la DCA...
 

 
Ce qui est plutot burlesque c'est que Microsoft accepte de modifier DirectX alors que c'est Nvidia qui a merdé et qui a sorti des GPU non conformes aux specs de Directx9... ATI a tout simplement suivi les specs qui disaient de faire du FP24 point.
 

 
CQFD: Si Nvidia fournit enfin un GPU potable qui prend en compte les spefs de DX9, en fait, s'ils font leur boulot, ça sera tranquille. Ca leur donnera peut etre une chance pour ne pas se faire ecraser par ATI. Par contre, Ati eux ils ont tout compris et ont bien suivi les specs...

 
Non le RV380 sera l'équivalent du R9600XT en un peu + puissant et sur PCI Express... moi je te parle du R420, une nouvelle architecture également appelé Loki et qui devrait bien déchirer, ca sera d'ailleurs le dernier GPU ATI sur AGP 8X aprés ca sera le R423 sur PCI Express.  

 
T un comique toi    
 

 
Et en Francais ca donne quoi ?
 

J'ai jamais dit le contraire... tant mieux pour eux qu'ils puissent faire évoluer leur archi et leurs drivers dans le bon sens... mais ce que je dit c'est que ce n'est pas à Microsoft à rattraper l'erreur qu'a fait Nvidia en s'éloignant des specs de DX9 et ca c'est un fait avéré.
 

 
Ben mis à part toi j'ai pas vu trop de nerveux ici bas...

je parles du R380 tout cour j'ai jamais rajouté de "V"

p'tit jeune toi-meme  

 
y a du y avoir négociation, parce qu'un atout de nvidia, c'est d'introduire le FP32, et c'est probablement là-dessus que ça s'est joué : directX augmente en précision, donc quelque part "s'améliore" et au passage, on fait en sorte que ce FP32 soit bien utilisé avec les GFFX : tu comprends bien que si ça s'est fait, c'est que ça arrangeait les deux parties, microsoft va pas travailler gratos pour nvidia

Excusez moi Monsieur    
 
   
 
Pgase > l'alcool spabieng  

 
Directx9 est fp 32 bit. Les types de données sont fait pour etre calculés sur du 32 bits/64/128 bits, et non du 24/96 bits.  Ca existe pas le 24 bits dans directx que ça soit le 8, le 9, ou le futur 9.1, essayez de trouver un  seul document émanant de microsoft  concernant le directx qui explique comment développer en 24bits les shaders sous windows ?
 
 Vous n'en trouverez pas, sauf si vous regardez dans des sections de developpement affiliées à ati, ou du coté de rendermonkey.
 
Les spécificités de Directx9 collaient à celles des nvidias, n'ont pas par chance mais parce que NVIDIA avait suivi l'IEEE, comme il l'avait déjà fait précedement avec sa gamme professionnelle de carte graphique QUADRO.
 
Les spécificités d'ati ne collent pas à directx9, parce qu'Ati opèrent des calculs avec une précision arbitraire qui trompent l'api en lui faisant croire que c est du 32bits pour utiliser le path pixel shader 2. Si ati ne camouflait pas le caractere 24 bits de sa carte, soit l'api la considerait comme une carte dx8 et lui ferait compilé des shaders 1.x, soit l'api refuserait la compilation.
 
Pour directx9, c'est normal que microsoft sort une nouvelle api, c'est leur boulot. Microsoft avant l'arrivé de directx9 a dit en gros:
 
On va pondre une api pour les shaders qui ne prendra pas en compte le matériel sur laquelle elle repose, même traitement pour tout le monde. Heu .... bah ok, mais M. Microsoft votre api, elle sert à quoi alors étant donné que tout le monde utilise des gpu différents ?  
 
Memo: l'api de crosoft, intègre un compilo qui devrait normalement crée du code spécifique pour chaque gpu (et non du code générique). Le but du langage de haut niveau c'est de programmer des fonctions sans connaitre les spécifités du matos en dessous, l'api s'occupant ensuite de pondre du code optimisé pour chaque matos.
 
Et oui, cette api c'etait du vent ....
 
 Nvidia voyant ça (entre autre), a dit puisque microsoft n'en glande plus une, on va faire le boulot à leur place et creer un vrai compilo spécial pour notre matos. Ce compilo pouvant remplacé celui de l'api directx, si les developpeurs font appels à ces routines (il faut encore qu'ils aient envis de se faire chier à jongler entre les deux compilos).
 
ATI, ils s'en foutaient etant donné que l'archi ati, c'est pas une archi dx9, mais une dx8 gonflée orientée sur les shaders 1.x. Les shaders 1.x ne font pas appel au compilo.
 
Quant aux shaders 2, comme microsoft pond une api peu regardante sur les spécificités du materiel, ils ont utilisés une précision arbitraire, qui travaillaient plus vite en 24 bits avec de fortes dégradations de qualité, voir des bugs, en faisant croire à l'api que c'est du 32bits high precision (path ps2 << pixel shader 2 de directx).
 
Finalement, Microsoft a décidé d'intégrer dans l'api, des fonctionnalités dérivées de cg, et des formes d'optimisations. La raison est simple, on l'a vu depuis le début de l'année à cause des conneries de Microsoft, les utilisateurs n'ont pas pu exploiter la puissance de leur carte graphique, ni des shaders 2, et finalement ceux qui s en sortent le mieux, en directx 9, c'est ceux qui trompent leur api(belle publicitée).
 
Mais le verdict est le même du coté d'ati, l'arrivé d'un compilo qui pond du code spécifique, pourra leur permettre d'éliminer tout les problemes de precisions 24->32 en travaillant exclusivement en 24 bits.

Yes, enfin on te retrouve
 
Merci merci c'est toujours aussi énorme
 

Question : au lieu de nous demander de trouver une spec Microsoft qui dit que les shaders sont en 24 bits (spec qui n'existerait pas d'apres toi), tu pourrais pas plutot nous donner celle qui dit qu'ils doivent etre en 32 bits ?
 
Oups désolé, je te demande de citer tes sources. Au temps pour moi, c'est contraire à tes convictions
 

nicolas_b a écrit, de nouveau    :

 
rhhhhhaaaaaa   c bon  

 
Bah je l'ai déjà dit. Il suffit de regarder du coté du code ansi. Les types de données fonctionnent par puissance de 2. Ou bien du coté du white paper de Microsoft sur le hlsl de directx9:
 
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
 
Le type matrice c est 4 floats par 4.
 
Le type vecteur à 4 dimensions (pour l'utilisation de l'exposition) c'est 4 floats = 128bits << (résultat du pixel shader2).
 
 

Tiré du white paper de microsoft:
A vector of dimension 4; each component is of type float (4x32 bits = 128 bits).
 
"The 4D vector result of this blend is the final output of the pixel shader. All pixel shaders must return a 4D RGBA color at a minimum.". << ce qui correspond à du 128 bits réel spécifité minimun de directx, et non à la pseudo norme 24/96 bits d'Ati.  
 
http://msdn.microsoft.com/library/ [...] tionto.asp

 
 
L'Ati ne peut pas utiliser ces types de données tel quel en 24 bits, elles calculent en 24 bits, et utilisent une convertion arbitraire pour retourner un resultat en 32 bits.

Le rapport avec la choucroute ?
 
Tu penses nous expliquer ce qu'est le codage binaire c'est ca
 
24 = 2^4 + 2^3
 
Et c'est quoi le rapport entre la norme ANSI ? Laquelle d'ailleurs ? Et ca doit être en little ou en big endians tes 32 bits au fait ?

heu... pour une fois, je crois que nicolas_b a raison
 
à moins que zeross nous ramène de la bonne science dont je raffole, pour l'instant, nicolas_b mène la barque avec de vrais docs...

Il a raison mais il parle pas de la meme chose
 
Ces docs parlent du codage des entiers, flottants dans le langage HLSL. Un entier est codé sur 32 bits. Normal, rien de spécial là.
 
Mais ça correspond pas à la précision des shaders  
(FP 16, FP 24, FP 32 ...)

Tu ne tiens pas compte d'une chose : ton article (qui est tiré d'un livre intitulé ShaderX² au passage et n'est pas un whitepaper MS) parle de la valeur en sortie qui est donc un vecteur de 4 flottants soit 128bits et ATI se conforme à la règle. Dans tout l'article il n'est pas fait état de la précision minimum à laquelle les calculs doivent être effectués en interne. La seule fois où je me souviens l'avoir vu évoquer c'était lors de la présentation de DirectX 9 et ce que l'on pouvait y lire alors c'est ceci :

 
Maintenant cette histoire de précision a pris des proportions bien trop importantes et c'est peut être un peu de la faute de MS qui a été trop "coulant" à ce sujet (tout du moins pas assez clair) et surtout à cause de la guéguerre ATI/nVidia. On le voit la précision n'est utile qu'à certains endroits précis du pipeline la plupart du temps du FP16 peut s'avérer nettement suffisant alors venir critiquer le FP24    
 
A terme (d'ici DirectX 10) je suis persuadé que tout le monde sera passé au 32 bits uniquement pour des raisons de commodité pas vraiment pour des raisons de précision.

Tiens, une reponse toute prete a utiliser pour toi, Nico:
 
Non, c'est pas vrai ce que vous dites.

Ah ben non, j'avais bien compris on dirait
 
Faut dire, j'avais pas tout lu

j'aime bien quand zeross explique

Si les jeux DX9 rament sur les GFFX, les developpeurs risquent d'hésiter avant de s'engager dans cette voie. Si M$ leur donne un moyen d'avoir de bonnes perfs sur les GFFX, DX9 sera plus utilisé dans les jeux donc M$ s'y retrouve.

C'est vraiment pas bon ce que fait Ati:
 
http://www.materiel.be/news.php?start=0#news2975
 
Quelle sale idée de transformer leurs cartes en toaster...
 
Je trouve l'argumentation sur le resultat 32bits, et le calcul opéré avec une précision moindre, leger. Dire que la precision 32bits sera utilisée comunément dans directx10 ne rime à rien, car elle est requise et standardisé par directx9.
 
Directx9 va meme plus loin etant donné qu'il introduit le mode double precision 64 bits, qui n'est pas encore utilisable tel quel par les cartes graphiques actuelles mais qui va le devenir.  
 
Directx9 supporte aussi effectivement le mode half precision 16bits. Ce mode etant utilisé pour les petits shaders compilé à l'execution, qui demande un rendu rapide et de bassé qualité.
 
Seul les cartes Ati ne sont pas capable de faire du 32bits high precision sans émulation, c'est à dire tout simplement les shaders2, et il faudra attendre la sortie des prochains chips pour avoir du 32bits.
 
Quoi qu'il en soit les jeux dx9, demanderont d'office la precision 32bits, etant donné que le path générique des shaders2 directx9 est 32bits.
 
Pour en revenir à la spécificité minimun du résultat 128bits, de quoi parle t on ? Est ce qu'on parle de la precision du résultat en 128 bits, ou de l'espace qui stocke ce resultat sur 128 bits ?
 
Quand microsoft a publié ces specifications, on a tous compris qu'ils demandaient un resultat avec une precision minimun de 128 bits, et non pas un espace de stockage d'au minimun 128 bits pour stocker des resultats de precisions moindre.  
 
Si ça n'avait pas été ça, la taille minimun de stockage en sortie aurait pu etre directement de 96bits, égale à la précision du résultat.  
 
C'est pour ça que Nvidia a été surpris par le choix technique d' Ati, et qu'ils ont été fair play quand ils se sont exprimés sur le sujet, car ils savaient qu'ati allait se planter.
 
 Quand on regarde la façon dont est opéré le calcul, à travers les spécificités de directx9, les registres temporaires doivent faire la taille d'un float (32bits).
 
 On ne parle pas de float 24 bits etant donné que ces registres sont destinés à contenir 4 composants de 8 bits chacun, R-G-B-A ou x-y-z-w, qui sont calculés à partir des registres vx de 8 bits (stockant un composant à la fois) et des constants registres qui stockent eux aussi des floats de 32bits.
 
Si ati fonctionnent en 24bits, c'est qu'ils zappent à un moment ou à un autre des bits pour chaque composant. Ce qui nous donne pour 2 bits de zappés, 6 bits par composant (6x4= 24bits), soit un pannel de 64 couleurs sur chaque canal au lieu de 255, ce qui équivaut à un rendu 16bits + le canal alpha (transparence - opacité).
 
Voila, en gros pourquoi les ati ne pourront pas, de toute manière  afficher un rendu correct/exact, requis par les shaders2. Alors bon, c'est vrai on a pu critiquer les nvidias avec leur mode half precision au temps ou les cartes étaient castrées par l'api. Mais il ne faut pas se tromper le 16bits de nvidia  est moins bon que la qualité 24bits de ati. Le 32bits de nvidia est largement supérieur à la qualité 24bits d'ati.
 
Maintenant que Microsoft prend en compte les spécificités des gpu dans directx, les cartes nvidia vont développer leur potentiel et pouvoir utiliser les shaders2.

chut.

et en passant, t'as compris ce que c'est qu'un flottant ?
parce que j'en ai pas l'impression en lisant tes 5 dernier paragraphes ...

Toujours aussi enorme

bon ya rien a dire
sinon qu'il s'est totalement decredibiliser le pauvre
 
le "24 bits" qu'il a decrit c'est pas du FP24 mais du FX6 ())
sans commentaire  

MDR, il a toujours pas arrêter l'asticage de son pngouin

bon bref, avec toutes ces histoires, j'ai même pas renouvelé ma CG et je suis toujours avec ma geforceDDR

tout à fait ...
 
merci donc à n_b pour son post montrant ainsi qu'il ne raconte que des conneries

 
Tu n'as pas lu ce que j'ai écris... ou pas compris
 

 
Don't hold your breath :

 
Si des moteurs de rendu comme ceux de Pixar, autrement plus complexes que ce que l'on peut voir actuellement ne nécessite pas plus de précision que le format flottant je ne pense pas que la double précision soit intégrée aux cartes 3D avant tréééééés longtemps : ça demanderait beaucoup trop de ressources (la différence FP24/FP32 au niveau du nombre de transistors est déjà énorme alors FP32/FP64 je te laisse imaginer) pour un gain invisible à l'oeil nu dans probablement tous les cas. Il ne faut pas perdre de vue une chose : pour l'instant en infographie on n'utilise pas de calcul scientifique nécessitant une précision extreme. En temps réel les différents modèles utilisés sont empiriques ils n'ont pas véritablement de réalité physique on se base sur la règle du "if it looks good then it IS good". L'avantage principal du format flottant sur le format fixe c'est la plus grande dynamique autorisée, la précision, je le répète,  n'est vraiment requise que pour l'adressage de textures.
 

 
Relis les specs que je t'ai données. Et puis je te parie que le R420 sera FP24.
 

 
Non il ne demandera pas du 32 bits ils demanderont un float, sur ATI il obtiendra un float 24bits sur nVidia un float 32 bits et hors cas trés particuliers (je pense à la démo Mandelbrot d'Humus) et pas forcément applicables dans un jeu la différence ne sera pas visible.
 

 
On parle d'un pipeline : la sortie d'une étape d'un pipeline est l'entrée d'une autre étape du pipeline c'est pour cette raison que le format DOIT être fixé. Ce n'est pas une question de précision mais de format.
 

 
Et bien vous avez mal compris : MS demandant des registres temporaires au format FP24 je me demande comment il pourrait exiger une précision de 32 bits du résultat.  
 

 
Oui mais dans ce cas ça obligeait les implémentations FP32 à perdre de la précision au passage ce qui est, tu le conçois j'imagine, ridicule, le format choisi permet de ne pas perdre de précision pour ceux qui font le calcul en FP32 et convient tout à fait à ceux qui font du FP24. Et puis le format 32 bits est plus pratique pour ce qui est des alignements mémoires et autres choses de ce genre donc il est plus adapté à un format de sortie.
 

 
Tu n'as pas lu ce que j'ai écris... ou pas compris.
s16e7 : un bit de signe, 7 bits d'exposants, 16 bits de mantisse = ... bits ?
 
Et je ne l'ai pas inventé ce format il est tiré d'un post d'un ingénieur de Microsoft sur la mailing list DirectX.
 

 
 
Non chaque composant EST sur 16/24/32 bits soit un vecteur de 64/96/32bits.
 

 
 
Non non pas du tout ! Là tu me décris le format du Flipper de la GameCube
Sur le R300 le format est de : s16e7
Alors qu'en 32 bits le format est de : s23e8
Mais dans tous les cas en sortie tu retrouveras ton format RGBA 32bits classiques ! le seul que les moniteurs peuvent afficher. Là on parle d'un format pour les calculs internes et je te le répète quand on parle de FP24 ce n'est pas pour le quadruplet RGBA mais pour chaque composante.  
 

 
Donc pour toi avec les ATI on est revenu au temps du 16bits ?
Tu devrais te renseigner un peu plus ce n'est pas du tout ça.

Merci Zeross pour ce post très instructif

en fait nicolas_b et Zeross sont complices pour nous apprendre des trucs : le 1er raconte des trucs farfelus et le second corrige.
 
bravo, c est tres pédagogique.