Jusqu'à présent, j'ai pu découvrir qu'il y a eu un passage de la circuriterie très spécialisée qui implémente les différentes étapes du pipeline graphique à une approche plus générale. Cette transformation s'est partiellement répercutée sur les API 3D sous forme de shaders programmables. La plupart des transistors semblent être dédiés à des unités SIMD massivement parallèles qui exécutent les instructions de shader réelles.
Correct. Fondamentalement, en raison de la taille relativement importante des fonctionnalités des anciens GPU, le seul moyen de mettre en œuvre efficacement des éléments tels que l'éclairage de base, l'anticrénelage, le mappage de texture, la géométrie, etc. était d'utiliser un pipeline à «fonction fixe». Ils ont sacrifié la flexibilité pour des raisons de performances car ils n'avaient pas assez de densité de puces pour pouvoir l'implémenter en utilisant une architecture SIMD massivement parallèle plus générique comme les GPU actuels.
Est un GPU moderne (pensez Nvidia Fermi) essentiellement un ensemble de tableaux SIMD "stupides" qui sont alimentés avec des instructions et des données du CPU et de divers caches, et toute la logique réelle qui mappe le pipeline graphique à ces instructions se produit dans le pilote graphique ?
Certaines choses se font encore dans le matériel; d'autres non. Par exemple, les ROP sont encore utilisés dans la toute dernière étape pour pousser les données de pixels dans le chipset VGA. Notez que j'utilise ici "chipset VGA" comme terme générique pour désigner le mécanisme qui transmet un signal vidéo à votre moniteur, qu'il s'agisse vraiment de "VGA" ou non.
Il est vrai, en général, que les architectures GPU actuelles telles que Nvidia Fermi et AMD Southern Islands sont, pour la plupart, des processeurs massivement parallèles où ils ont un jeu d'instructions personnalisé, et chaque "noyau" individuel est extrêmement faible, mais il y a un ensemble beaucoup de cœurs (parfois plusieurs milliers). Mais il y a encore du matériel spécifique aux graphiques:
Le décodage vidéo matériel est souvent effectué, en grande partie, à l'aide de puces à fonction fixe. Cela est particulièrement vrai lorsque DRM (Digital Restrictions Management) est impliqué. Parfois, le décodage vidéo «matériel» signifie vraiment un ensemble d'instructions guidées par le micrologiciel qui sont simplement servies comme d'anciennes tâches régulières pour les cœurs SIMD. Ça dépend vraiment.
À l'exception de très peu de cartes Nvidia spécifiques au calcul (Tesla), presque toutes les cartes graphiques "génériques SIMD" ont une gamme complète de matériel dédié à la sortie vidéo. La sortie vidéo n'est pas la même chose que le rendu; les éléments de sortie à fonction fixe incluent les codecs LVDS / TMDS / HDMI / DisplayPort, HDCP et même le traitement audio (essentiellement un petit DSP), car HDMI prend en charge l'audio.
La "mémoire graphique" est toujours stockée à bord avec les GPU, afin qu'ils n'aient pas à traverser le bus PCIe à latence bavarde et relativement élevée pour atteindre la RAM système, qui elle-même est plus lente et prend plus de temps à répondre que la plus chère, une mémoire graphique plus rapide et de meilleure qualité (par exemple GDDR5) qui est disponible en plus petites capacités mais à des vitesses plus élevées que la mémoire système. Le processus de stockage des éléments dans la mémoire graphique et de leur récupération sur le GPU ou sur le CPU est toujours une opération à fonction fixe. Certains GPU ont leur propre "IOMMU", mais cette unité de gestion de la mémoire est distincte (distincte) du CPU. Ce n'est cependant pas vrai pour les GPU Intel récents intégrés dans leurs processeurs (Sandy et Ivy Bridge), où l'architecture mémoire est presque entièrement "cohérente" mémoire système) et les lectures à partir de la mémoire graphique sont aussi bon marché pour le CPU que pour le GPU.
Ou existe-t-il des unités de contrôle quelque part dans le GPU qui traduisent les instructions et les flux de données de haut niveau entrants (programmes de shader compilés, données et attributs de vertex et textures) en instructions SIMD réelles et prennent en charge la synchronisation, l'allocation de mémoire, etc.?
La langue «native» des SIMD est presque toujours générée par le pilote dans le logiciel, et non par le propre firmware du GPU. Cela est particulièrement vrai pour les fonctionnalités de niveau DirectX 9 / OpenGL 2.x. Les shaders écrits dans des langages de haut niveau tels que l'assembleur de shaders HLSL, GLSL ou OpenGL ARB sont finalement traduits, par le pilote, en instructions GPU en frappant sur certains registres et en effectuant les cercles PCIe requis afin d'envoyer des tampons par lots de calcul et / ou de rendu commandes.
Certaines choses, comme la tessellation matérielle (DirectX 11 / OpenGL 4.0) sont à nouveau introduites dans le matériel de manière fixe, de la même manière qu'elles faisaient presque tout à l'époque. C'est parce que, encore une fois, les contraintes de performances exigent que la façon la plus efficace de faire ces calculs soit d'avoir un circuit dédié pour cela, plutôt que d'avoir un firmware ou le pilote "programme" les SIMD pour le faire.
Je soupçonne que la réalité se situe quelque part entre ces deux extrêmes, et la réponse serait plutôt longue et basée sur beaucoup de spéculations (il doit y avoir une raison pour que certains fournisseurs de GPU refusent de publier toute documentation sur leurs produits, sans parler de pilote code source ...), mais tout indice dans la bonne direction et ressources utiles seraient grandement appréciés.
AMD et Intel ont une documentation très robuste en plein air sur leurs GPU récents, ainsi que des pilotes graphiques open source pleinement opérationnels pour Linux (voir les projets Mesa et Direct Rendering Manager). Si vous regardez une partie du code de ces pilotes, vous allez rire, car les rédacteurs de pilotes graphiques doivent en fait implémenter la géométrie de choses comme dessiner diverses formes ou motifs, dans "logiciel" (mais en utilisant des commandes matérielles pour soumettre le vrai travail sur le matériel pour le traitement), car ni le firmware du GPU ni les fonctions fixes ne sont plus présents pour le traiter entièrement dans le matériel :) C'est assez drôle ce qu'ils doivent faire pour prendre en charge OpenGL 1.x / 2.x sur les nouveaux Matériel.
L'évolution s'est en quelque sorte déroulée ainsi:
- Il y a très longtemps (avant que le rendu 3D en temps réel soit considéré comme possible): le lancer de rayons sur le CPU était normal pour le rendu non en temps réel. Pour les graphiques simples comme vous le voyez dans les premières versions de Windows, le processeur était assez rapide pour dessiner des formes simples (rectangles, caractères d'une police, motifs d'ombrage, etc.) sans matériel de fonction fixe, mais il ne pouvait pas dessiner des choses trop complexes.
- Il y a longtemps (OpenGL 1.x): presque tout implémenté par du matériel à semi-conducteurs; les fonctions fixes "électriquement" étaient la norme même pour les opérations de base
- Il y a quelque temps (OpenGL 2.x): une transition vers une plus grande programmation des GPU avait commencé. Les "shaders de fragments" (aka pixel shaders) sur du matériel vieux de 5 ans peuvent presque effectuer des calculs arbitraires comme un CPU, mais ils sont limités par l'architecture, qui est toujours très orientée vers les graphiques. Par conséquent, OpenCL / DirectCompute ne sont pas disponibles sur ce matériel.
- Récemment (OpenGL 3.x): La transition vers les GPU à usage général est presque terminée, mais ils sont bien sûr optimisés pour les charges de travail impliquant de grandes matrices de données (pensez à l'algèbre linéaire) soumises par lots, plutôt que pour les processeurs qui peuvent fonctionner efficacement sur longues séquences de très petites données (1 + 1, 2 * 4, 5 * 6 en séquence, etc.) L'informatique à usage général est disponible via OpenCL, CUDA, etc. mais le matériel n'est toujours pas un "coprocesseur SIMD" complet car (a) vous devez encore marteler des registres spécifiques au matériel pour accéder à la fonctionnalité GPU; (b) la lecture à partir du GPU VRAM est très lente en raison de la surcharge du bus PCIe (la lecture à partir du GPU n'est pas très optimisée sur l'architecture actuelle); (c) l'architecture de la mémoire et du cache n'est pas cohérente avec le CPU; beaucoup de matériel à fonction fixe hérité traîne toujours.
- Présent (OpenGL 4.x): s'est débarrassé de beaucoup de matériel à fonction fixe hérité. Amélioration de la latence de lecture du GPU. Les IOMMU permettent un mappage assisté par matériel (traduit) entre la VRAM et la mémoire système. Également introduit une tessellation matérielle, ramenant des éléments de fonction fixe.
- Futur ( HSA): Le GPU est essentiellement un coprocesseur. Il est presque entièrement intégré au CPU avec très peu d'impédance (pour les lectures / écritures) entre le GPU et le CPU, même pour les GPU dédiés sur le bus PCIe. Architecture de mémoire entièrement cohérente - "mi memoria es su memoria" (ma mémoire est votre mémoire). Les programmes de l'espace utilisateur peuvent lire à partir de "VRAM" tout comme ils lisent à partir de la mémoire système sans cale de pilote, et le matériel s'en charge. Vous avez le CPU pour le traitement "série" (faites ceci, puis faites cela, puis faites ceci, puis faites cela) pour des quantités modestes de données, et le GPU pour le traitement "parallèle" (effectuez cette opération sur cet énorme ensemble de données et divisez-le comment vous le jugez bon). La carte sur laquelle se trouve le GPU peut encore avoir des ROP, un codec HDMI, etc. mais ce truc est nécessaire pour la sortie d'affichage,
