Argument des constructeurs on ne peut plus falacieux.
Si tu veux avoir une excellente vu d'ensemble de l'interieur des puces de CG il te suffit d'aller trainer du coté de HardwareFR.
Tu m'excuseras je coupe le reste parceque ta comparaison n'est pas valable.
On est passé d'un modèle statique (cracheur de poygone + textures avec lissage) a un modèle dynamique. La première génération s'apellait T&L (Transform and Lightning) Grosso modo les cartes ne faisaient plus seulement du rendu "brutal" mais devenait capable d'effectuer des opérations complexes sur les polygones (placement, rotation, éclairage) déchargeant ainsi le CPU d'autant.
On est aujourd'hui passé a un mode de shaders, des suites de micro instructions effectués soit sur un ensemble de vertex (une ligne d'un polygone) soit sur les pixels d'une texture. Pour des raisons de "place" dans le GPU Il n'était pas question d'empiler les transistors pour avoir d'un coté une archi statique, de l'autre une archi T&L et enfin une suite d'archis supportants les shaders de différentes versions pour Directx et OpenGL.
La bonne approche consiste a faire le mieux possible les unités les plus évoluées en émulant les autres quitte éventuellement a rajouter un peu de logique dans le pro pour pallier quelques manques ou faiblesses des perfs par émulation.
En d'autres termes dans un pilotes de cartes graphiques moderne, il y a les Paths Shaders 2, les paths shaders 1.x , les paths T&L et les paths statiques, avec a chaque fois un max d'astuce de programmation pour optimiser l'émulation le plus possible. C'est çà ou faire exploser le nombre de transistor de la puce (et aujourd'hui même SGI fait comme ca sur les CGs des workstation...)
Contrairement a une archi CPU classique on a pas une interface de programmation normalisé et de niveau relativement élevé (si tant est que l'on puisse parler de haut niveau pour de l'assembleur par opposition au byte code) , mais on a une foule d'interfaces qui passent par des chemins différents et qui sont aussi proche du GPU core que possible. Dans un cas on a le manuel utilisateur dans l'autre des plans détaillés pris sous plusieurs angles différents, détaillant composant par composant le chemin pris par telle ou telle instruction haut niveau (au sens appels OpenGL/DirectX cette fois).
Du fait de la versatilité des applications graphiques et des besoins très différents que peuvent avoir les différents intégreurs/éditeurs les fabriquants de cartes graphiques ne peuvent pas "fermer" leur carte dérrière une interface unique comme c'est souvent le cas pour les autres cartes ou processeurs. D'ou leurs craintes de voir les sources de leurs drivers entre les mains d'un concurrent.
[^] # Re: C'est une excellente chose
Posté par Jerome Herman . En réponse à la dépêche Une pétition pour obtenir des pilotes ATI de meilleure qualité. Évalué à 10.
Si tu veux avoir une excellente vu d'ensemble de l'interieur des puces de CG il te suffit d'aller trainer du coté de HardwareFR.
Tu m'excuseras je coupe le reste parceque ta comparaison n'est pas valable.
On est passé d'un modèle statique (cracheur de poygone + textures avec lissage) a un modèle dynamique. La première génération s'apellait T&L (Transform and Lightning) Grosso modo les cartes ne faisaient plus seulement du rendu "brutal" mais devenait capable d'effectuer des opérations complexes sur les polygones (placement, rotation, éclairage) déchargeant ainsi le CPU d'autant.
On est aujourd'hui passé a un mode de shaders, des suites de micro instructions effectués soit sur un ensemble de vertex (une ligne d'un polygone) soit sur les pixels d'une texture. Pour des raisons de "place" dans le GPU Il n'était pas question d'empiler les transistors pour avoir d'un coté une archi statique, de l'autre une archi T&L et enfin une suite d'archis supportants les shaders de différentes versions pour Directx et OpenGL.
La bonne approche consiste a faire le mieux possible les unités les plus évoluées en émulant les autres quitte éventuellement a rajouter un peu de logique dans le pro pour pallier quelques manques ou faiblesses des perfs par émulation.
En d'autres termes dans un pilotes de cartes graphiques moderne, il y a les Paths Shaders 2, les paths shaders 1.x , les paths T&L et les paths statiques, avec a chaque fois un max d'astuce de programmation pour optimiser l'émulation le plus possible. C'est çà ou faire exploser le nombre de transistor de la puce (et aujourd'hui même SGI fait comme ca sur les CGs des workstation...)
Contrairement a une archi CPU classique on a pas une interface de programmation normalisé et de niveau relativement élevé (si tant est que l'on puisse parler de haut niveau pour de l'assembleur par opposition au byte code) , mais on a une foule d'interfaces qui passent par des chemins différents et qui sont aussi proche du GPU core que possible. Dans un cas on a le manuel utilisateur dans l'autre des plans détaillés pris sous plusieurs angles différents, détaillant composant par composant le chemin pris par telle ou telle instruction haut niveau (au sens appels OpenGL/DirectX cette fois).
Du fait de la versatilité des applications graphiques et des besoins très différents que peuvent avoir les différents intégreurs/éditeurs les fabriquants de cartes graphiques ne peuvent pas "fermer" leur carte dérrière une interface unique comme c'est souvent le cas pour les autres cartes ou processeurs. D'ou leurs craintes de voir les sources de leurs drivers entre les mains d'un concurrent.
Kha