Un développeur donne son avis sur la conception d'OpenGL
Et explique pourquoi OpenGL est en retard par rapport à DirectX 12 ou Mantle

Le , par LittleWhite, Responsable 2D/3D/Jeux
Rich Geldreich, développeur chez Valve écrit sur un blog ses opinions personnelles (donc, à ne pas lier avec Valve) sur OpenGL. Son opinion est intéressante, notamment car Rich a été développeur sur le premier moteur utilisant la technique de rendu différé (pour Shrek, sur Xbox), ensuite il a aussi créé une bibliothèque de compression avancée pour le DXTc, pour Ensemble Studios et travaille maintenant chez Valve, notamment sur le portage et l'optimisation des jeux Portal 2 et DoTA 2 sur Linux). Il est aussi un des développeurs de vogl, un nouveau débogueur/profileur OpenGL multiplateforme.


Dans son blog, il donne son point de vue sur la conception d'OpenGL et y explique pourquoi la bibliothèque est en retard par rapport aux récentes solutions proposées par les concurrents (DirectX 12 et Mantle). Même si certains de ces points peuvent être mineurs et négligeables, cela décourage bien souvent les développeurs voulant s'intégrer dans l'écosystème OpenGL.

20 ans d'héritage, OpenGL nécessite une refonte

Il faut qu'OpenGL suive le concept KISS (Keep It Simple, Stupid). En cas de doute, on doit se débarrasser de tel ou tel élément. La bibliothèque doit être extrêmement simplifiée, notamment en enlevant le mode de compatibilité. DirectX 12 et Mantle vont être très agressifs du point de vue de la performance alors que le système de contexte global et le modèle basé sur les liaisons sont pourris. Une bibliothèque reposant sur un accès à l'état direct (Direct State Access) devrait être maintenant un standard.
La plupart des développeurs vont préférer une transition douce en portant leur code de rendu PS4/Xbox One vers DirectX 12 et/ou Mantle. Ils ne vont pas réécrire leur pipeline de rendu en entier pour utiliser un regroupement super agressif des ordres de rendu et autres techniques avancées comme la communauté OpenGL le conseille depuis quelques temps afin d'améliorer les performances. Mais à cause de cela, OpenGL sera toujours considéré comme une solution de seconde zone et aucun portage ne sera fait tant qu'il n'y aura pas de modernisation et simplification de la bibliothèque.

La création de contexte OpenGL est un enfer

La création d'un contexte OpenGL moderne est une source d'erreur inimaginable. Le processus est même dépendant de la plateforme et Rich recommande aux développeurs de ne jamais utiliser des bibliothèque GLX/WGL/... mais plutôt des bibliothèques de plus haut niveau comme SDL ou GLFW (et un truc comme GLEW pour récupérer les pointeurs de fonctions et autres extensions).
Le principe de devoir utiliser des bibliothèques tierces est nul. La bibliothèque devrait être simplifiée et normalisée afin que l'utilisation d'une bibliothèque tierce ne soit plus une nécessité lors de la création d'un contexte.

Le thread du contexte courant pourrait être un pointeur "this" implicite

Les fonctions retournées par GetProcAddress() ne peuvent (ou ne devraient, suivant la plateforme) pas être utilisées globalement car elles peuvent être fortement liées au contexte (en langage OpenGL : dépendante ou indépendante du contexte). En d'autres mots, l'appel à la fonction GetProcAddress() sur un contexte et l'utilisation du pointeur retourné dans un autre contexte est mauvais et provoquera des crashs.

Déficience de glGet()

Ceci est peut-être fortement lié au tracing des appels OpenGL mais cela impacte indirectement les développeurs car les outils sont inefficaces ou inexistants.
La série de fonction glGet* (glGetIntergerv, glGetTexImage...) ne possède pas de paramètre "taille_maximale", donc il est possible pour le pilote d'écraser les données des tampons suivant les paramètres ou l'état du contexte global. Avec un paramètre de taille, la fonction pourrait retourner une erreur si la taille maximale est trop petite et non provoquer un écrasement de mémoire.
Le calcul de la taille du tampon de texture lu ou écrit par le pilote dépend de plusieurs état du contexte global, ce qui est mauvais.
Il y a une centaine d'énumérations acceptées par la fonction glGet() et certaines ne sont acceptées que par des pilotes spécifiques. Si vous écrivez un débogueur ou un traceur, il n'y a aucune méthode officielle pour déterminer comment les valeurs seront gérées par le pilote.

glGetError

Il n'y a pas de glSetLastError() comme dans la bibliothèque Win32, rendant le tracing d'application difficile. Certaines applications n'appellent jamais glGetError(), d'autres une fois par image, d'autres seulement lors de la création des ressources. Certaines l'appelle des centaines de fois à l'initialisation et plus jamais par la suite. Rich a vu des applications dans le commerce ayant des erreurs OpenGL à chaque image (est-ce que les développeurs le savent ?).

Impossibilité de faire des requêtes sur des éléments clés

Comme il n'est pas possible de faire des requêtes sur des éléments tels que les cibles de texture, le débogage d'application est encore plus difficile, notamment dans les cas de rendu d'ombre. Tous les états devraient pouvoir être accessibles.

Les bibliothèques en accès directs aux états ne sont pas un standard et pas toujours correctement supportés

L'accès direct aux états permettra une grande différence dans le surcoût des appels des fonctions OpenGL.

La spécification n'est toujours pas complète en 2014

La spécification XML ne possède pas d'information de types pour les paramètres. Par exemple :
Code xml : Sélectionner tout
1
2
3
4
5
<command> 
    <proto>void <name>glBindVertexArray</name></proto> 
    <param><ptype>GLuint</ptype> <name>array</name></param> 
    <glx type="render" opcode="350"/> 
  </command>
Seule glapi.py est la source d'information la plus complète à ce jour :
Code : Sélectionner tout
GlFunction(Void, "glBindVertexArray", [(GLarray, "array")]),

Pas d'outils standard/officiel pour OpenGL

Il y a besoin de :
  • outil d'aide pour la conversion de texture et de pixel qui ne repose pas sur le pilote ou un contexte OpenGL ;
  • équivalent de DXTEX pour le format KTX (équivalent du DDS), qui fonctionne avec tous les fichiers ;
  • outil de conversion d'image vers KTX ;
  • une bibliothèque pour compiler les shaders.


Extensions décrient comme des diff par rapport à la spécification

Pour comprendre la documentation des extensions, il faut connaître parfaitement la spécification.

Horreur de MakeCurrent()

La fonction peut être extrêmement coûteuse, tout en ayant des coûts supplémentaires avec certaines extensions (NB_bindless_texturing), peut provoquer des crashs si elle est appelée entre des blocs glBegin()/glEnd(). Le comportement de cette fonction devrait mieux être expliqué aux développeurs.

Les pilotes ne devraient pas crasher le GPU, ni le CPU, ni même freezer lors des comportements indéterminés de la bibliothèque

Soit les pilotes devraient mieux être testés, soit la bibliothèque doit être restructurée pour éliminer les comportements indéfinis.
Le pilote freeze en cas de trop nombreux appels à glBufferSubData(). Le pilote peut caler tout le pipeline pendant vos opérations de rendu et rien ne vous indique la raison. Les requêtes peuvent aussi provoquer ce comportement.

Destruction des objets

Bonne chance si l'objet en cours de destruction est lié à un autre contexte.
L'appel de glGet() sur un objet partiellement détruit (encore existant car lié dans un autre contexte) provoque des comportements qui diffèrent entre les pilotes.

Compilation et édition des liens des shaders

Il y a de nombreux problèmes de performances liés à la compilation des shaders. Le système utilisé dans Direct3D fonctionne. En plus, OpenGL n'accepte que des shaders en texte. Les temps de compilation entre les pilotes sont très variables et certains utilisent des techniques d'optimisation alors que d'autres ne le font pas (compilation en parallèle, système de cache).

Multithreading

Certains développeurs ont décidé d'activer leur pilote multithread alors que ceux-ci sont bogués et cela, plusieurs mois après les tests des développeurs de jeux. Même les glGet() peuvent être bogués lorsque le parallélisme est activé. Il n'y a aucune méthode pour savoir si le pilote est multithreadé ou non.

Votre opinion

Que pensez-vous de tous les défauts rapportés par Rich Geldreich ? Sont-ils légitimes ?
Trouvez-vous que DirectX propose une meilleure bibliothèque, exempt de défauts ?
Utilisez-vous OpenGL directement, ou préférez-vous l'utilisation d'un moteur ? Lequel et pourquoi ?

Voir aussi

La vérité sur la qualité des pilotes graphiques OpenGL
Les développeurs de Dolphin dressent un tableau de la qualité du support d'OpenGL
Conférence de Rich Geldreich aux Steam Dev Days
Game Connection 2013 - Europe : Techniques OpenGL ES avancées dans la série des GTA

Source

Blog de Rich Geldreich


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de marsupial marsupial - Membre éprouvé https://www.developpez.com
le 29/05/2014 à 14:37
Que pensez-vous de tous les défauts rapportés par Rich Geldreich ? Sont t-ils légitimes ?

L'expérience de DirectX donne une grande avance sur OpenGL mais est en même temps légitimée par sa spécialisation et l'ouverture exclusive du matériel.
Lequel matériel donne en contrepartie des pilotes graphiques de 100+Mo ultra compressé. ( Le kernel linux pèse 75% faiblement compressé )

Trouvez-vous que DirectX propose une meilleure bibliothèque, exempt de défauts ?

Du fait de son poids, il est plus réactif. Imaginons un microscope électronique( "nanoscope"), en exagérant, avec DirectX, l'OS plus le pilote prendra la taille d'un cluster tel celui du CERN.
Un cluster dans un lanceur, ça pèse son poids à faire décoller pour un télescope qui dispose de lentilles de plusieurs tonnes.

Utilisez-vous OpenGL directement, ou préférez-vous l'utilisation d'un moteur ? Lequel et pourquoi ?
Ni l'un ni l'autre, je laisse à un spécialiste du domaine se prononcer.
Par contre, un "best of both worlds" serait du meilleur aloi.
Avatar de RedSkidy RedSkidy - Membre du Club https://www.developpez.com
le 01/06/2014 à 9:31
je ne suis pas un spécialiste d'OpenGL donc j'ai lu que les titres mais les défauts cités m'ont l'air plutôt légitimes
je ne connais pas directX mais d'après ce que j'ai entendu il marche que sur windows donc si c'est le cas c'est pas terrible
j'essaye de développer directement a partir d'OpenGL et Qt mais en un mois je n'ai toujours pas réussis a faire une fenêtre qui peut afficher une forme (j'essaye d'utiliser opengl 3.0 mais c'est galère avec Qt)
donc oui je pense qu'OpenGL nécessite une refonte et qu'elle permette de créer des fenêtres avec un contexte directement sans que les développeurs aient besoin de manipes compliquées avec Qt, la SDL...
Avatar de cocolapin0 cocolapin0 - Futur Membre du Club https://www.developpez.com
le 02/06/2014 à 12:57
- la doc opengl est complète RTFM. Je pense que Rich a eu un problème avec son navigateur. ex:
http://www.opengl.org/sdk/docs/man3/...ertexArray.xml
chez moi toute la doc s'affiche correctement.

- dans la section "Horreur de MakeCurrent()" : il est cité l'utilisation de blocs glBegin()/glEnd() (utilisé pour définir les sommets un par un coté CPU). Ici ça montre que Rich parle de l'ancienne api : en mode compability qui est deprecated, donc c'est une vision totalement fausse de l'opengl d'aujourd'hui et c'est vraiment pas malin de ça part de vouloir détruire opengl. Dans l'api actuel, il faut créé un buffer object (buffer coté GPU), et upload les datas tous simplement avec un glBufferData(), puis lancer un vertex / fragment shader.

- la création d'un context opengl n'est pas du tout un enfer. L'api laisse de la place au paramétrage, après il faut utilisé la bonne librairie pour la bonne abstraction. On a l'impression que Rich fait parti des personnes qui n'ont pas compris le rôle d'opengl, qui est d'être une api de rendu ! À la différence de directx qui fait vraiment partie de toute un framework proposé par microsoft (rendu, I/O, son, ... )

- lorsqu'il parle de freeze, il utilise des drivers instable, donc ne l'écouté pas !

- pas d'outils standard / officiel d'opengl. Il cite le manque d'outils pour convertir des fichiers : ça n'a absolument rien à voir avec opengl qui est une api de rendu : ces propos sont totalement hors sujet !

- à un moment il parle des temps de compilation des shaders. Encore une fois ça n'a rien à voir avec une api. Une api sert juste à définir des spécifications. La compilation dépend de l'implémentation du compilateur, avec les drivers de nvidia, c'est le compilateur cg qui est utilisé.

---------
Pour résumé, Rich n'a rien compris à ce qu'était opengl, et fait parti des personnes qui attendent que tout soit mi sur un plateau. J'utilise opengl es 2 (qui est sous-ensemble d'opengl 3), donc opengl avec les shaders. J'utilise opengl es 2 dans mes programmes écrit avec le framework Qt en C++, et mon code est multi-plateforme: sur les ordis, tablettes, smartphone. De plus avec le langage glsl (langage des shaders : vertex et fragment shader) le code est à la fois compatible dans une application riche (ordi, smartphone, ...) mais aussi dans les navigateurs web. À ma connaissance aucune autre api de rendu ne propose ça.

Et en règle générale il faut se méfier de tout ce qui vient de chez Valve. Quand Valve dit qu'il est pour le libre, c'est n'importe quoi ! il n'y a qu'à voir la plateforme steam qui est la plus grosse plateforme de drm jamais créée !
Avatar de RedSkidy RedSkidy - Membre du Club https://www.developpez.com
le 02/06/2014 à 16:49
Citation Envoyé par cocolapin0  Voir le message
- à un moment il parle des temps de compilation des shaders. Encore une fois ça n'a rien à voir avec une api. Une api sert juste à définir des spécifications. La compilation dépend de l'implémentation du compilateur, avec les drivers de nvidia, c'est le compilateur cg qui est utilisé.

c'est pas OpenGL qui compile les shaders ?
Avatar de LittleWhite LittleWhite - Responsable 2D/3D/Jeux https://www.developpez.com
le 02/06/2014 à 17:54
OpenGL n'est qu'une bibliothèque ou plus précisément une spécification d'une bibliothèque. Chacun des constructeurs de cartes graphiques va réimplémenter (recoder les fonctions décrite dans la spécification) comme il le souhaite. Parmi l'une de ces fonctions, il y a glCompileShader() qui accepte une chaîne de caractère contenant le code source et qui le compile en un shader GPU. Le compilateur est implémenter par les constructeurs et cette implémentation (comme le reste de la bibliothèque) se trouve dans le pilote graphique.

Donc, en soit, OpenGL ne fait rien. Ce n'est qu'une liste de fonctions que les gens doivent suivre pour supporter OpenGL.

- dans la section "Horreur de MakeCurrent()" : il est cité l'utilisation de blocs glBegin()/glEnd() (utilisé pour définir les sommets un par un coté CPU). Ici ça montre que Rich parle de l'ancienne api : en mode compability qui est deprecated, donc c'est une vision totalement fausse de l'opengl d'aujourd'hui et c'est vraiment pas malin de ça part de vouloir détruire opengl. Dans l'api actuel, il faut créé un buffer object (buffer coté GPU), et upload les datas tous simplement avec un glBufferData(), puis lancer un vertex / fragment shader.

Ouep, mais le pilote ne devrait pas crasher, même dans un tel cas, vous ne croyez pas ?

- à un moment il parle des temps de compilation des shaders. Encore une fois ça n'a rien à voir avec une api. Une api sert juste à définir des spécifications. La compilation dépend de l'implémentation du compilateur, avec les drivers de nvidia, c'est le compilateur cg qui est utilisé.

Oui, mais pourquoi ne pas permettre d'utiliser des shaders précompilés (à l'instar de DirectX) ? Cela est dit dans cette vidéo : http://jeux.developpez.com/videos/Op...r-jeux-OpenGL/
Là, la spécification ne permet pas les shaders précompilés, du tout. Donc, oui, là, cela peut revenir à un soucis de bibliothèque et de sa spécification.

- pas d'outils standard / officiel d'opengl. Il cite le manque d'outils pour convertir des fichiers : ça n'a absolument rien à voir avec opengl qui est une api de rendu : ces propos sont totalement hors sujet !

Ici, vous avez une spécification, mais aucune implémentation de référence, aucun outil pour bosser avec les implémentations actuelles, ou les applications qui l'utilisent. Même si ce n'est pas un soucis de spécification à la base, il en reste que cela démotive les développeurs à l'utiliser, car dès qu'ils se plantent sur l'utilisation de la bibliothèque, ils ont rien pour trouver l'erreur.

Pour OpenGL ES, l'avantage, c'est que la spécification est un sous ensemble de OpenGL, donc qui limite énormément les complexités d'implémentation et qui réduit les trucs inutiles (le pipeline fixe a été viré très tot, ainsi que les fonctions associés, dans cette spécification). Oui, vous aurez une application portable, mais vous n'aurez pas les dernières fonctionnalités de vos cartes graphiques OpenGL 4, avec une application en OpenGL ES 2. Vous vous êtes énormément limité en terme de rendu possible (même si, je ne doute pas que cela suffise à vos besoins ).
Avatar de mintho carmo mintho carmo - Membre actif https://www.developpez.com
le 02/06/2014 à 22:19
(OpenGL permet d'utiliser les shader programs compilé, cf glGetProgramBinary/glProgramBinary. Quand au reste, j'ai l'impression que c'est le perpétuel débat "vieux quelque chose qui doit maintenir la rétrocompatibilité" vs "nouveaux truc qui peut repartir sur une API neuve" : C++ vs D, GL vs Mantle, etc. Bof)
Avatar de LittleWhite LittleWhite - Responsable 2D/3D/Jeux https://www.developpez.com
le 03/06/2014 à 10:56
Dans cette vidéo, si je me rappelle bien, ils disaient que certes, il y a cette extension, mais que chaque pilote produit son propre binaire et que ce binaire n'est compatible que pour la carte qui compile/la version du pilote en cours. Du coup, même en ayant le binaire, qui est une représentation trop dépendante de la machine/pilote, on ne s'en sort pas.
Avatar de mintho carmo mintho carmo - Membre actif https://www.developpez.com
le 03/06/2014 à 11:03
Le but de glGetProgramBinary/glProgramBinary est de pouvoir enregistrer les binaires après compilation sur une machine, pour ne pas avoir à les recompiler ensuite. Et en effet, les binaires ne sont pas destiné à être partagé entre plusieurs machines. Dans un sens, ça peut paraître limité, mais d'un autre côté, c'est le cas de tous les binaires quelques soit le langage (si on chercher à optimiser un binaire généré en C++ en utilisant des features hardware spécifique d'un processeur, le binaire ne sera pas non plus portable). On peut imaginer aussi des binaires compilés à l'installation et pas au premier lancement.
Sinon, HS : Apple vient de lancé aussi un concurrent à OpenGL (Metal)
Avatar de LittleWhite LittleWhite - Responsable 2D/3D/Jeux https://www.developpez.com
le 03/06/2014 à 11:06
Ouep, mais DirectX, ils le font, avec un bytecode. Pour Metal, j'ai vu les news, mais je ne m'y suis pas encore penché dessus
Avatar de mintho carmo mintho carmo - Membre actif https://www.developpez.com
le 03/06/2014 à 11:09
bytecode = machine virtuelle (donc ils faut qu'ils soient d'accord sur les spécifications) et moins performant (?) Ok, je vois l'idée, un "pré-compilé". On fait les étapes de compilation qui sont "portable" et la fin de la compilation quand on a besoin des shaders (alors que OpenGL compile tout lorsque l'on a besoin). C'est effectivement une solution pour gagner du temps (alternative à getProgamBinary)

De toute façon, avoir des binaires portables, cela veut dire que les constructeurs de gpu soit d'accord sur le format... impossible. Du coup, une API comme Mantel spécifique à AMD peut faire ce genre de chose (idem pour Microsoft qui décide lui même des formats). Mais pour une API comme OpenGL, où plein de monde à son mot à dire, aucune chance que cela n'arrive. Mais cela veut probablement dire aussi que le premier type d'API ne pourra pas devenir un "standard" (Mantel ne sera portable que sur AMD, DirectX n'est portable que sur Windows)
Offres d'emploi IT
Data scientist senior H/F
Safran - Ile de France - Magny-les-Hameaux (Saclay)
Architecte technique des systèmes d'information H/F
Safran - Ile de France - Évry (91090)
Responsable transverse - engagement métiers H/F
Safran - Ile de France - Corbeil-Essonnes (91100)

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique 2D - 3D - Jeux : LittleWhite -