Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

4PARTAGES

9  1 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de 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...
1  0 
Avatar de shenron666
Expert confirmé https://www.developpez.com
Le 11/06/2014 à 18:06
Premier constat, le traducteur a fait l'erreur de traduire D3DX en DirectX.
Hors la source parle bien de Direct3D.

A part ce point, une partie des remarques sont fausses ou inexactes depuis OpenGL 3, plus encore depuis OpenGL 4.
D'autres sont liées à l'appréciation du développeur.
Il ne faut pas oublier non plus un détail on ne peut plus important : OpenGL est multi-OS contrairement à Direct3D.

D'autres remarques encore sont à adresser aux développeurs de pilotes (stabilité, compilateur de shader) voire de Microsoft en ce qui concerne les pilotes sous Windows car ce dernier a toujours fait de l'obscurantisme et mis des bâtons dans les roues d'OpenGL (rappelez-vous de Vista qui ne devait supporter OpenGL qu'en tant que surcouche Direct3D).

Bref mon avis : encore un blogueur de bas étage qui aurait pu dire quelque chose d'intéressant s'il n'avait pas cherché à ajouter un max d'arguments pour cracher sur OpenGL qui, à l'heure actuelle, a bien rattrapé son retard sur Direct3D.
Il suffit de voir les benchmark sous Unigine qui sont à ma connaissance ceux qui exploitent le mieux OpenGL.
1  0 
Avatar de shenron666
Expert confirmé https://www.developpez.com
Le 12/06/2014 à 11:46
Citation Envoyé par stardeath Voir le message
xbox, xbox one, windows toute version, windows phone, windows rt, donc non plus.
(contre windows, mac os, linux, les os mobiles étant exclus, opengl es étant suffisamment éloigné pour devoir réécrire systématiquement une partie du code)
oui tu as raison, windows, windows, windows, windows, windows, windows, windows, et... windows
(xbox et xbox one utilisant un ersatz de windows)
ça en fait des plateformes différentes

quand à opengl es, il est bien plus proche que tu ne semble vouloir le faire croire
et tu peux adapter ta remarque à Direct3D vu que tu parles de windows phone
Citation Envoyé par stardeath Voir le message
perdu aussi, ça n'a jamais été le cas
ça c'est fort
Citation Envoyé par stardeath Voir le message
mais bon, on se rattrape comme on peut.
sérieux ?
Citation Envoyé par stardeath Voir le message
je rappelle quand même que vista avait introduit un nouveau modèle de pilote.
aucun rapport avec la choucroute

Citation Envoyé par stardeath Voir le message
*michel denisot* et si on parlait du post que tu viens de faire?
alors désolé mais je ne connait pas "michel denisot", alors si rapport il y a... je ne vois pas
Citation Envoyé par stardeath Voir le message
et en plus opengl n'est pas tout rose
loin de là, sauf qu'il y a un moment où la critique doit être dirigée sinon on passe au troll
Citation Envoyé par stardeath Voir le message
bref, ai-je vraiment besoin de développer?
pas la peine, j'ai parfaitement cerné que tu es pro D3D
ce que je ne peux pas être vu qu'il n'est pas sous linux
1  0 
Avatar de 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 !
2  2 
Avatar de 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 ?
0  0 
Avatar de 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 ).
0  0 
Avatar de mintho carmo
Membre averti 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)
0  0 
Avatar de 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.
0  0 
Avatar de mintho carmo
Membre averti 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)
0  0 
Avatar de 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
0  0