Comment OpenGL de travail au niveau le plus bas?
Je comprends comment écrire OpenGL/DirectX programmes, et je sais que les maths et le conceptuel des trucs derrière elle, mais je suis curieux de voir comment le CPU-GPU de la communication travaille sur un niveau bas.
Dire que j'ai un programme OpenGL écrit en C qui affiche un triangle et fait pivoter la caméra de 45 degrés. Quand je compile ce programme, il sera transformé en une série de ioctl-appels, et le pilote du gpu puis envoie les commandes appropriées pour le gpu, où toute la logique de la rotation du triangle et le bon de pixels de la couleur appropriée est câblé dans? Ou le programme sera compilé dans un "gpu programme" qui est chargé sur le gpu et calcule la rotation etc.? Ou quelque chose de complètement différent?
Modifier:
Quelques jours plus tard, j'ai trouvé cet article de la série, qui, fondamentalement, la réponse à la question:
http://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-graphics-pipeline-2011-part-1/
- Spécification OpenGL état que les commandes sont envoyées dans un mode client/serveur. Le cahier des charges est trop large pour déterminer spécifique de technologies de pointe utilisées par les implémentations d'OpenGL.
Vous devez vous connecter pour publier un commentaire.
Cette question est presque impossible de répondre, car l'OpenGL en lui-même est juste un avant la fin de l'API, et tant qu'une des implémentations conforme à la spécification et le résultat est conforme à ce qu'il peut être fait de toute façon que vous aimez.
La question pourrait être: Comment un pilote OpenGL travail sur le niveau le plus bas. Maintenant, c'est de nouveau impossible de répondre en général, comme un pilote est étroitement liée à certains éléments de matériel, ce qui peut encore faire des choses cependant, le développeur l'a conçu.
Donc, la question aurait été: "Comment est-il en moyenne dans les coulisses de l'OpenGL et le système graphique?". Regardons cela de bas en haut:
Au niveau le plus bas, il y a quelques périphériques graphiques. Aujourd'hui, ce sont les Gpu qui fournissent un ensemble de registres de contrôle de leur fonctionnement (qui enregistre est exactement dépend de l'appareil) ont un peu de mémoire de programme pour les shaders, mémoire de masse pour les données d'entrée (les sommets, les textures, etc.) et un canal d'e/S pour le reste du système au cours de laquelle il reçoit/envoie des données de commande et de ruisseaux.
Le pilote graphique assure le suivi de la Gpu de l'état et de toutes les ressources des programmes d'application qui utilisent le GPU. Il est également responsable de la conversion ou de tout autre traitement des données envoyées par les applications (convertir des textures dans la pixelformat pris en charge par le GPU, la compilation des shaders dans le code machine de la GPU). En outre, il fournit une solution abstraite, pilote dépendante de l'interface de l'application des programmes.
Puis il y a le pilote dépendante OpenGL client library/pilote. Sur Windows, cela devient
chargé par procuration à travers opengl32.dll sur les systèmes Unix, cela réside dans deux endroits:
Sur MacOS X, ce qui se passe pour être le "OpenGL" Cadre de.
C'est cette partie qui traduit les appels OpenGL comment vous le faites dans les appels vers le pilote de fonctions spécifiques dans le cadre du conducteur décrit au paragraphe (2).
Enfin le réel OpenGL API de la bibliothèque, opengl32.dll dans Windows, et sur Unix /usr/lib/libGL.de la sorte; ce la plupart du temps juste passe les commandes à l'implémentation OpenGL bon.
Comment la communication réelle qui se passe ne peuvent pas être généralisées:
Dans Unix le 3<->4 connexion peut se produire soit sur les Sockets (oui, il peut, et de n'aller sur le réseau si vous le souhaitez) ou par l'intermédiaire de la Mémoire Partagée. Dans Windows, l'interface de la bibliothèque et le pilote client sont à la fois chargés dans l'espace d'adressage du processus, de sorte que ce n'est pas tellement la communication, mais de simples appels de fonction et de variable/indicateur de passage. Dans MacOS X c'est similaire à celui de Windows, seulement qu'il n'y a pas de séparation entre l'interface de OpenGL et le pilote client (c'est la raison pour laquelle MacOS X est si lente à s'adapter aux nouvelles versions d'OpenGL, il nécessite toujours un système d'exploitation complet de mise à niveau pour fournir le nouveau cadre).
Communication entre 3<->2 peuvent passer par ioctl, lecture/écriture, ou par le biais de la cartographie de la mémoire dans l'espace d'adressage du processus et de la configuration de la MMU pour déclencher certains pilotes de code à chaque fois que des changements pour que la mémoire est terminé. C'est tout à fait similaire sur n'importe quel système d'exploitation depuis vous de toujours avoir à traverser le noyau et l'espace utilisateur des limites: en fin de compte vous allez par le biais de certains syscall.
De Communication entre le système et le GPU se faire par la periphial bus et les méthodes d'accès qu'elle définit, donc, PCI, AGP, PCI-E, etc, qui fonctionnent à travers le Port I/O, Memory Mapped I/O, DMA, interruptions (Irq).
Vous n'êtes pas loin. Votre programme appelle la installable client driver (ce qui n'est pas vraiment un pilote, c'est un utilisateur de la bibliothèque partagée). Qui va utiliser ioctl ou un mécanisme similaire à transmettre des données au pilote du noyau.
Pour la prochaine partie, il dépend du matériel. Les anciennes cartes graphiques a ce qu'on appelle une "fonction fixe pipeline". Il y avait dédié aux espaces de mémoire de la carte vidéo pour les matrices, et du matériel dédié pour la texture de recherche, de fusion, etc. Le pilote vidéo serait de charger les données et les indicateurs pour chacune de ces unités et, ensuite DMA pour le transfert de votre sommet de données (position, couleur, coordonnées de texture, etc).
Du matériel récent a de cœurs de processeur ("shaders") à l'intérieur de la carte vidéo, qui diffèrent de votre CPU dans chacun de s'exécuter beaucoup plus lent, mais il ya beaucoup plus d'entre eux travaillent en parallèle. Pour ces cartes vidéo, le pilote prépare binaires pour s'exécuter sur le GPU, les shaders.
Votre programme n'est pas compilé pour toute GPU, c'est juste lié dynamiquement à l'encontre d'une bibliothèque d'application OpenGL. La mise en œuvre effective peut comprendre l'envoi de commandes OpenGL pour le GPU, le fonctionnement du logiciel de base, de la compilation des shaders et de les envoyer au GPU, ou même en utilisant le shader de base de commandes OpenGL. Les graphismes paysage est assez compliqué. Heureusement reliant isole vous de la plupart des pilotes de la complexité, laissant pilote exécutants libres d'utiliser des techniques qu'ils l'entendent.
Compilateurs C/C++/linkers faire exactement une chose: ils permettent de convertir des fichiers texte dans une série de la machine spécifique opcodes qui sont exécutés sur le PROCESSEUR. OpenGL et Direct3D sont juste C/C++ Api; ils ne peuvent par magie transformer votre compilateur C/C++/éditeur de liens dans un compilateur/linker pour le GPU.
Chaque ligne de code C/C++ que vous écrivez sera exécuté sur le PROCESSEUR. Les appels OpenGL/Direct3D remet en bibliothèques C/C++, statique ou dynamique, selon le cas.
Le seul endroit où un "gpu programme" entrerait en jeu, c'est si votre code crée explicitement les shaders. C'est, si vous faites les appels de l'API en OpenGL/D3D qui causent la compilation et la liaison de shaders. Pour ce faire, vous (au moment de l'exécution, pas de C/C++ au moment de la compilation), soit de générer ou de charger de chaînes de caractères qui représentent les shaders dans certains langage de shader. Ensuite, vous pousser à travers le shader compilateur, et obtenir un objet dans l'API qui représente ce shader. Vous pouvez ensuite appliquer un ou plusieurs shaders pour un rendu particulier de commande. Chacune de ces étapes se produire explicitement à la direction de votre code C/C++, qui, comme dit précédemment, s'exécute sur le PROCESSEUR.
De nombreux shader langues, le C/C++-syntaxe. Mais cela ne les rend pas équivalent à C/C++.