Discussion :

[LittleWhite]

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

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 - Visualiser dans une fenêtre à part

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 - Visualiser dans une fenêtre à part

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

[marsupial]

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.

[RedSkidy]

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...

[cocolapin0]

- 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 !

[RedSkidy]

- à 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 ?

[LittleWhite]

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 ).

[mintho carmo]

(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)

[LittleWhite]

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.

[mintho carmo]

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)

[LittleWhite]

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

[mintho carmo]

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)

[LittleWhite]

Mais, c'est le but du consortium Khronos ... de trouver un compromis et de discuter pour faire un truc qui va au mieux pour tous.
D'ailleurs, dans cette direction, ils ont réussi à se mettre ok pour une implémentation de référence d'un analyseur de shader : http://www.opengl.org/sdk/tools/glslang/ .
Donc, nous pourrions espérer qu'ils se mettent d'accord sur le bytecode et une fois que celui-ci est déterminé, on peut toujours l'optimiser à la volée lors de son traitement/première exécution (c'est souvent ce qui est fait avec le bytecode, dans les autres technos).

[mintho carmo]

(j'ai fait un edit, je sais pas si tu l'as vu)

Merci pour glslang, je connaissais pas

De toute façon, cela ne réglera pas les problème de rétro compatibilité (ou plus précisément l’utilisation de code old-school et le mélange des api nouvelles et anciennes par les devs) et donc de la complexité apparente d'OpenGL (je viens de voir la news sur Swift qui remplacera Objective-C, toujours le même débat nouvelle api vs ancienne api qui doivent être rétro compatible)

HS (encore) : j'ai vu plusieurs fois parler de OpenGL 5 et DirectX 12. C'est vraiment en cours ou c'est de projets lointain ? (cf g-truc par exemple)

[LittleWhite]

J'ai vu l'édit après

Pour DirectX/Direct3D 12, la release est prévue fin 2015. J'imagine que OpenGL 5 (même si je n'en ai pas trop entendu parler) viendra dans la foulée, ou une petite année après. Mais bon, là, c'est une estimation personnelle et je dois dire, je suis assez mal placé pour savoir.

[mintho carmo]

Manifestement, depuis Mantel et DX12, il y a pas de discussions sur le sujet. Par exemple : Rant About Rants About OpenGL (Unity) ou OpenGL Is Broken (Firaxis Games). Et il y en a pleins d'autres
On va attendre que ça se calme

[Invité]

Personnellement il y a beaucoup de vrai dans ce qu'il dit et je n'ai jamais utilisé opengl directement, cette librairie est trop compliquée, je l'utilise en travers d'une librairie déjà existante qui encapsule le contexte opengl. (Car en effet pour la compatiblité entre palteforme c'est une vrai horreur. :/)

Et pour certaines autres choses qui ont été dîtes aussi, je pense que opengl nécessite vraiment une refonte!

Mais bon c'est une librairie de bas niveau donc..., je ne m'attendait pas à mieux, il faut souvent beaucoup d'abstraction si on veut faire de l'optimisation, du multipass-rendering et du code portable et l'opengl moderne avec les layouts nécessite d'en faire encore plus.

D'ailleurs je n'utilise pas l'opengl moderne (à part les VBO qui sont très intéressante) pour la simple et bonne raison que ça ne fonctionne pas toujours avec tout les drivers et puis, ça complexifie grandement les choses, j'utilise encore les anciens glVertexPointer, glColorPointer, etc..., qui marche sans soucis avec les FBO sur tout les drivers, même ceux qui ne supporte pas le GLSL moderne. (Ainsi que les geometry shader ou encore l'instanced rendering)

Mais bon il faudrait implémenter certaines choses dans le pipeline aussi. (et pas tout dans les shaders, selon moi les shaders doivent rester un moyen de faire de meilleurs effets mais ne doivent pas intervenir au niveau de la mécanique de base de opengl)
Un alpha test plus précis qui nous permettrait de comparer l'alpha avec celui du pixel couramment dessiné à l'écran serait le bienvenu également plutôt que de devoir le faire obligatoirement sur une valeur de l'alpha. (Ca a été l'horreur pour moi de devoir faire ça avec des textures semi-transparentes qui se croisent)

[Guntha]

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

Il ne faut pas oublier que beaucoup de drivers PC, notamment sur les chipsets Intel, implémentent OpenGL avec beaucoup de retard et pas mal de bugs. C'est pas très pro de reprocher à ses clients/utilisateurs finaux de choisir la mauvaise machine
Dans OpenGLES, j'ai récemment été traumatisé par les drivers de chez QualComm (je l'ai détaillé sur un autre topic).

Pour ce qui est de la création du contexte, je n'ai pas suivi les dernières évolutions d'OpenGL, mais dans OpenGLES, on a depuis longtemps EGL (qui est aussi spécifié par Khronos) qui permet de créer très facilement un contexte. Donc l'argument du mec de chez Valve est invalide dans ce cas.

Par contre, si un jour je décide de faire une appli 3D sur PC, j'éviterais de vouloir à tout prix implémenter des fonctionnalités d'OpenGL 4 (à mon avis actuellement vaut mieux se limiter au 2.1, et encore. En tout cas faut au moins proposer un fallback vers cette version), et je pense que je proposerais à côté un renderer DirectX, histoire d'éviter les problèmes de compatibilité.

[dragonjoker59]

Moi je suis partisan de la refonte d'OpenGL, il y a beaucoup de code dont on ne se sert plus (ou en tout cas dont on ne devrait plus se servir), pour ne citer que les plus connus : mode direct, display lists...
Cependant ils ne peuvent pas réellement le faire car OpenGL est encore fortement utilisé en milieu industriel, principal frein à ces évolutions, qui casseraient beaucoup d'applications.
Donc je pense qu'ils ont choisi un excellent compromis avec le Core Profile. C'est celui que j'utilise depuis quelques années et je m'en porte bien.

Je dois avouer que la logique objet de DirectX est confortable, ... mais c'est tout en fait. Au fur et à mesure que D3D avance, je trouve qu'il se rapproche de ce qui se fait en OpenGL, notamment au niveau shaders (exit Effect).

Pour la création du contexte OpenGL, il décrit ça comme un enfer, mais pour avoir un contexte X11 et un contexte Windows, je ne vois pas l'enfer. Il est peut-être dommage d'avoir des variations dans la création, mais en même temps dès qu'on touche à de la GUI il est évident qu'il y aura des variations dans le lien entre OpenGL et la GUI. Et c'est la seule variation ! Le reste du code est identique entre Windows, GNU/Linux et Mac (et autres aussi, d'ailleurs). C'est un faible prix à payer je trouve.

Pour le problème qu'il décrit avec GetProcAddress, c'est vrai que gDEBugger râle quand on récupère des fonctions qu'on utilise dans un autre contexte, mais je n'avais encore pas rencontré de problème par rapport à ça. (par contre je l'ai corrigé, sait-on jamais).

glGetError est le meilleur ami d'un développeur OpenGL. Tout développeur OpenGL devrait le savoir, sinon ... Après il est vrai que la spécification est un peu légère sur le debug. Ca tend à se combler avec les extensions ARB_debug_output ou AMD_debug_output, mais il y a des lacunes au niveau des implémentations (surtout côté AMD même si là encore ça s'améliore).

Pour les crash de pilote, ça ne m'est pas arrivé fréquemment, et ça m'est essentiellement arrivé sous GNU/Linux et j'avoue que ça me fait enrager aussi.

[shenron666]

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.

[stardeath]

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.

développez, développez, sinon c'est pas mieux ...

Il ne faut pas oublier non plus un détail on ne peut plus important : OpenGL est multi-OS contrairement à Direct3D.

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)

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).

perdu aussi, ça n'a jamais été le cas, mais bon, on se rattrape comme on peut. de plus, il a juste fallu une ou 2 mises à jour des pilotes de la part des constructeurs pour que opengl marche bien, parce que je rappelle quand même que vista avait introduit un nouveau modèle de pilote.

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.

*michel denisot* et si on parlait du post que tu viens de faire?
et en plus opengl n'est pas tout rose (voir ce qui ce passe dans le mobile avec opengl es, où là pourtant il n'y a pas microsoft; ou encore les devs de dolphin qui ont quelques difficultés avec opengl, où alors ceux sont des dévs de bas-étage aussi?) bref, ai-je vraiment besoin de développer?