IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

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 !

La vérité sur la qualité des pilotes graphiques OpenGL
Un développeur revient sur les différents pilotes OpenGL disponibles

Le , par LittleWhite

0PARTAGES

11  0 
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 revient donc sur les différents supports OpenGL disponibles sur le marché. Voici ce qu'il en dit :

Vendor 1

C'est l'implémentation la plus utilisée chez les développeurs, car c'est l'implémentation la plus avancée du marché. C'est le pilote « standard », il est très rapide et ses développeurs préfèrent la sécurité plutôt que de suivre la spécification à 100 %. Les développeurs jouant avec OpenGL utilisent ce pilote car il possède les extensions les plus amusantes. La plupart des choses que vous entendez pour concurrencer Mantle/Direct3D 12 sont réalisées par les développeurs jouant avec ce pilote. Le problème, c'est qu'il n'est pas possible de cibler uniquement celui-ci, sans quoi, une grande partie du marché serait oubliée.

Toutefois, lorsque le moteur Source 1 a été porté sur Linux et que les développeurs de Valve tenaient la main aux développeurs de ce pilote, ils n'étaient même pas capables de mettre à jour un tampon (avec glMap() ou glBufferSubData(), comme on le ferait en Direct3D 9/11) sans que le pilote ne se bloque. Ici, on parle des choses de « driver perf 101 ». De plus, lorsque vous tombez sur un bogue dans ce pilote, celui-ci s'étale complètement la figure contre le sol et crashe soit le GPU, soit Windows. Malgré tout, c'est un pilote solide et sûr.

Cette implémentation supporte énormément d'extensions (dont certaines à la pointe de la modernité) fonctionnant plus ou moins bien, mais dès que vous utilisez les plus importantes, vous sortez des clous de sécurité du pilote et vous tombez dans un terrain miné.

Historiquement, les outils de ce développeur sont nuls ou ne fonctionnent que pendant un certain temps puis arrêtent de fonctionner ou ne fonctionnent que si vous suppliez l'aide auprès de l'équipe de ces outils. Ils possèdent des outils, peut-être comme ceux dans la série Dilbert leur permettant de savoir ce qui se passe. Bien sûr, ces outils ne fonctionnent que sur leurs pilotes.

Ce Vendor est très précautionneux et stratégique lors de l'intégration de leurs développeurs dans les jeux clés afin que les choses marchent. C'est une épée à double tranchant, car ces développeurs vont refuser de déboguer les problèmes des autres développeurs de pilotes et leur vision d'OpenGL ne se fait qu'au travers de leur implémentation. Les développeurs intégrant une équipe feront les choses pour leur pilote, sans se soucier de l'impact sur les autres implémentations.

Historiquement, ce développeur fera des choses comme remplacer la globalité des shaders des jeux clés par leur implémentation afin que cela fonctionne mieux sur leur implémentation (et cela le fait effectivement très bien). La plupart des pilotes font certainement cela occasionnellement, mais ce développeur fera tout pour la performance. Qu'est-ce que cela signifie pour l'industrie du jeu vidéo ? C'est que vous, développeur d'effets et de graphismes, vous n'atteindrez jamais le même niveau technique dans votre jeu (même si vous utilisez les mêmes algorithmes !), car vous n'avez pas les ingénieurs du pilote travaillant spécialement sur votre jeu permettant au pilote de faire exactement ce qu'il doit (en utilisant des shaders bas niveau optimisés) lorsque votre moteur fonctionne. Cela veut aussi dire que les légendes du monde graphique que vous connaissez ne sont pas aussi intelligentes ou capables que ce que l'histoire montre : elles ont reçu beaucoup d'aide.

Pour plaisanter, ce développeur est connu sous le nom de « mafia graphique ». Soyez prudents, si leurs développeurs débarquent dans votre équipe... ils sont sérieux.

Vendor 2

Le pilote est complètement désordonné, possède des performances inconsistantes, est très bogué et les tests de régression sont incomplets, même le parallélisme du pilote est hors contrôle des développeurs officiels. Malheureusement, les GPU de ce constructeur sont standards et sont très corrects, donc vous ne pouvez pas les ignorer. Les fonctions basiques comme glTexStorage() crashent (sur un titre publié) et cela, depuis des mois. Toutefois, les développeurs respectent mieux la spécification que les développeurs du Vendor 1, mais cela n'est pas une bonne chose car la plupart des développeurs utilisent le matériel du premier Vendor et lorsque cela ne marche pas sur ce second matériel, c'est ce Vendor qui est critiqué et non l'implémentation d'OpenGL de l'autre.

Les extensions clés ne fonctionnent simplement pas. Elles sont là, simplement pour montrer l'avancement aux managers. La plupart des développeurs OpenGL n'utilisent jamais ces extensions car elles ne fonctionnent pas. Elles semblent géniales sur le papier et indiquent la progression mais finalement, c'est une démonstration parfaite du non fonctionnement des extensions OpenGL dans la pratique.

Ce pilote ne peut avoir de choses comme les requêtes ou les synchronisations de fonctionnel. Donc n'importe quelle extension reposant sur les synchronisations CPU/GPU ne peuvent pas fonctionner. Les développeurs restant chez ce constructeur souhaitent tout simplement travailler chez le premier Vendor.

Cette entreprise ne peut mettre à jour son pilote sans rien casser. Ils vont vous envoyer des mises à jour ou des correctifs pour corriger un bogue et en rajouter deux. Si vous effectuez du pas à pas sur les points d'entrées de ce pilote, vous allez remarquer des couches et des couches de croûte clouées au fil des ans provenant de développeurs ayant quitté l'entreprise. Personne ne comprend ces couches pour pouvoir les modifier sans risque.

Rich a quelques fois vu des choses bizarres se produisant dans ce pilote lorsqu'il rejouait des flux d'appels OpenGL de jeux commerciaux avec voglreplay. Le jeu en lui-même fonctionne correctement, mais lorsque le flux d'appels d'OpenGL est rejoué, on peut voir une corruption massive du tampon d'image (qui s'en va après sur chaque flush du pipeline OpenGL). Il suppose que le pilote désactive des fonctionnalités entières trop boguées suivant des profils d'applications.

Néanmoins, ce développeur possède une petite équipe pour les outils qui a créé des outils de débogage pratiques et qui fonctionnent la plupart du temps, tant que vous utilisez leurs GPU. Sans ses outils, le portage du moteur Source 1 aurait pris bien plus de temps.

Cela aurait pu être temporaire, mais il semble que du point de vue de la fiabilité cela ne fait qu'empirer (et oui, cela peut être encore pire).

Toutefois, ils connaissent la spécification OpenGL complètement et cela à la syllabe prêt. Si vous pouvez obtenir leur assistance, leurs conseils sont plus ou moins raisonnables pour la spécification d'OpenGL (pas les extensions).

Vendor 3 - Pilote 1

C'est compliqué d'être sincèrement en colère contre ce troisième développeur. Ils ne veulent pas faire de graphismes. Ils ne le font que par distraction, la mode étant de tout intégrer sur une même puce et vu qu'ils ont énormément d'espace à partager sur celle-ci, ils le font. Ce sont des maîtres au niveau matériel, mais du côté logiciel, ils ne sont pas vraiment intéressés. Ils sont les leaders au niveau des pilotes graphiques open source et leurs spécifications matérielles sont presque publiques. Ils ont actuellement tellement d'argent et leur organisation est si grande qu'ils peuvent se permettre d'avoir deux équipes différentes de développeurs pour le pilote ! Hé oui, pour ce développeur, vous pouvez avoir un premier pilote OpenGL pour une plateforme et un second sur une autre. Ce sont deux équipes différentes avec deux codes différents.

En tout cas, l'équipe des ressources humaines de ce développeur est intelligente : elle engage directement les maîtres open source pour faire avancer laborieusement le premier pilote. Ce pilote est moins avancé que les pilotes principaux, mais il fonctionne plus ou moins, tant que vous ne comprenez pas ou que vous n'êtes pas intéressé par le terme « FPS ». Si vraiment il ne fonctionne pas et que vous êtes motivé, vous pouvez essayer de corriger vous-même le pilote et soumettre un patch. Si vous êtes vraiment bon à ce petit jeu, vous pouvez même obtenir un emploi chez ce développeur.

Malheureusement, ce premier pilote est très en retard dans la spécification OpenGL, mais peut-être que dans une année ou deux, ils rattraperont ce retard et implémenteront la spécification de l'année dernière. Mais vous ne pouvez pas ignorer ce pilote car ils ont un marché important et en expansion. Donc, si un développeur de jeux souhaite atteindre ce marché, il ne peut pas utiliser les extensions amusantes ou les dernières améliorations d'OpenGL « modernes » supportées par le Vendor 1 et 2.

Ce Vendor ne propose absolument aucun outil pour OpenGL. Si vous souhaitez déboguer votre programme... bienvenue en 1999.

Vendor 3 - Pilote 2

Un désastre complet. Le pilote de cette seconde équipe est à peine utilisé par les titres OpenGL. Il y a tellement de morceaux de code qui ne fonctionnent pas. Ils ne peuvent pas mettre à jour un tampon sans une corruption massive aléatoire. Cette équipe va faire des choses comme vous donner un pilote bogué unique et différent pour chaque titre afin de réaliser des analyses de performances et des tests. Cette équipe vous demande honnêtement si c'est la performance ou la justesse qui est le plus important.

Rich a vu une équipe de développeurs bien connue passer plus d'une année pour avoir leur moteur de rendu OpenGL 4.X avec extensions fonctionnel sur ce pilote. Ce pilote ne fonctionne simplement pas. Faites simplement un moteur de rendu OpenGL 3.X avec des hacks.

Du bon côté, le Vendor 3 fournit plus d'informations internes sur leur matériel que la première équipe, faisant que le pilote a tendance à être un petit peu plus rapide, lorsqu'il fonctionne.

Les autres pilotes

En plus des implémentations précédentes, il existe aussi des pilotes open source, développés par la communauté pour les puces du Vendor 1 et 2. Ils sont souvent en retard d'un point de vue OpenGL, mais il parait que cela fonctionne bien. Rich n'a pas d'expérience réelle avec ces pilotes, car il a toujours été craintif de travailler avec ces pilotes open source/développés à l'aide de rétro-ingénierie ce qui aurait pu énerver les équipes de développement des pilotes fermés.

Le Vendor 1 déteste ces pilotes car ils sont profondément établis dans la façon dont les choses sont faites. Ces développeurs reçoivent des fonds et hypothèques pour subsister et il y a donc beaucoup d'inertie. Il n'y a absolument aucune chance qu'ils publient leurs spécifications top secrètes ou même qu'ils rendent open source leur pilote. Le Vendor 1 devra sauter dans le train de l'open source prochainement afin de mieux concurrencer le modèle ouvert du troisième Vendor, que cela leur plaise ou pas.

Le deuxième Vendor aide sans enthousiasme le pilote open source en fournissant une petite équipe les aidant à maintenir les choses fonctionnelles. À un certain point, le pilote open source pour le deuxième Vendor pourra être plus viable que leur pilote fermé semi-fonctionnel.

Conclusion

Pour publier votre jeu, vous devriez tester votre code sur chaque pilote et contourner tous les problèmes. Que les « dieux d'OpenGL » vous aident si vous faites face à des corruptions de GPU aléatoires, des corruptions de pile, des freezes ou des crashs. Soyez très gentils avec les équipes de développement des pilotes et leurs managers, car sans eux, vos chances sont quasi nulles.

Votre opinion

Avez-vous reconnu chacun des Vendors ?
Vous étiez-vous déjà aperçu de cet état de fait ?
Quels ont été vos déboires avec OpenGL ?

Voir aussi

Les développeurs de Dolphin dressent un tableau de la qualité du support d'OpenGL
Conférence de Rich Geldreich aux Steam Dev Days

Source

Blog de Rich Geldreich

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

Avatar de math_lab
Membre éprouvé https://www.developpez.com
Le 16/05/2014 à 13:07
Ce que je préfère dans l'article original, c'est la reponse de John Carmack:
Just wait until you meet Vendor D, E and F in the mobile space.
4  0 
Avatar de forthx
Membre éprouvé https://www.developpez.com
Le 15/05/2014 à 6:39
Avez-vous reconnu chacun des Vendors ?

je dirais respectivement Nvidia, ATI(Amd), et intel (je garde un doute sur l'ordre entre les 2 premiers).
Vous étiez-vous déjà aperçu de cet état de fait ?
En partit, on note rapidement des grosses différences de perf et de stabilités pour un même code qui roule sur 2 machines équipées de drivers/GPU des vendor 1 et 2.

Quels ont été vos déboires avec OpenGL ?
Je me suis arrêter a la manipulation de polygones (et quelques bricoles pour le fun) je ne suis pas rentrer dans les derniers retranchement de l'api et j'ai soigneusement éviter les dernières nouveautés (dans l'idées de compatibilité avec de plus vielles machines).

Je doit admettre que cet présentation m'a surpris, sans pour autant, je m'attendais a une certaine rigueur de la part d'au moins un des vendor
1  0 
Avatar de Jbx 2.0b
Membre chevronné https://www.developpez.com
Le 15/05/2014 à 10:09
Avez-vous reconnu chacun des Vendors ?
Idem, j'aurais dit nVidia, AMD et Intel.

Vous étiez-vous déjà aperçu de cet état de fait ?
C'est le pilote « standard », il est très rapide et les développeurs de ce pilote préfèrent la sécurité plutôt que de suivre la spécification à 100 %.
C'est vrai qu'nVidia a plus tendance à prendre des largeurs sur les specs OpenGL. On le voit bien dans les shaders, ou sur une carte ATI certains ne compileront tout simplement pas alors que sur une carte nVidia ils seront acceptés malgré des erreurs sur les types par exemple.
Les cartes Intel ne font plus du tout partie de mes cibles, mais j'ai souvenir de démos désastreuses sur ces machines il y a quelques années ("Tiens, ou sont passés mes textures ? Oh! Mais c'est quoi cet éclairage ? Ah, ça rame en 800x600... *Petit tour dans le gestionnaire de périphériques* Ah d'accord, vous avez une carte graphique Intel. Enfin, si on peut appeler ça une carte graphique.)

Quels ont été vos déboires avec OpenGL ?
Remarquer après plus d'une semaine de recherche, que certaines implémentations d'androïd et OpenGL ES (je ne sais à qui est la faute) ne supportent pas plus de 32768 indices pour les VBOs (j'en parle ici), alors que c'est spécifié nul part à ma connaissance.
1  0 
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 15/05/2014 à 11:17
Personne ?
Pourtant, il y a quelques mois, il y a eu cette news, où les développeurs de Dolphin, cherchant à faire un portage Android, on taillé dur dans les implémentation mobiles : Les développeurs de Dolphin dressent un tableau de la qualité du support d'OpenGL
1  0 
Avatar de Mat.M
Expert éminent sénior https://www.developpez.com
Le 23/05/2014 à 21:42
Citation Envoyé par jean_kevin_musclor Voir le message
bonjour, moi je suis développeur directx et je tiens à signaler que nos drivers sont aussi merdiques que ceux d'opengl

tant qu'on reviendra pas à des machines basse conso on sera obligés de faire de la daube sur des usines à gaz buggées pour cause de forcing de vente de merdes inutiles servant à engraisser trois morbaques milliardaires qui vivent de sabotage
dommage la remarque pourrait être intéressante mais elle est un peu vulgaire...
pour ce qui est de la consommation ça c'est les utilisateurs qui veulent de la puissance mais à un prix trop élevé.
Ensuite si tu veux une machine super puissante pour un super framerate pour des FPS avec toutes les options graphiques, je doute que tu puisses trouver des composants basse consommation réellement.
Apparemment tu n'as pas eu de cours d'électricité...la loi de Joule stipule qu'un circuit avec une résistance entraine une dissipation de chaleur, donc des circuits intégrés ça dégage toujours de la chaleur..
1  0 
Avatar de Zefling
Expert confirmé https://www.developpez.com
Le 15/05/2014 à 10:20
Avez-vous reconnu chacun des Vendors ?
nVidia, AMD et Intel.

Vous étiez-vous déjà aperçu de cet état de fait ? Quels ont été vos déboires avec OpenGL ?
Je ne peux pas dire pour Intel, j'ai pas. Pour nVidia, ç'a l'air d'être de loin le plus stable de ce que j'ai pu tester. Son équivalent open source Nouveau ne supporte pas ma carte (800×600 et un seul écran gérer). Pour AMD c'était juste la catastrophe, openGL fini systématiquement pas planter et son équivalent open source est aussi buggé, mais plus stable et quasi sans accélération 3D.
0  0 
Avatar de pcaboche
Rédacteur https://www.developpez.com
Le 15/05/2014 à 10:40
Citation Envoyé par LittleWhite Voir le message
Avez-vous reconnu chacun des Vendors ?
Petit jeu amusant : relire la news avec la voix de Julien Lepers de "Question pour un Champion" :

"- Qui suis-je ?
- Catégorie "cartes graphiques"
- Un indice pour nos téléspectateurs (C'est l'implémentation la plus utilisée chez les développeurs car c'est l'implémentation - la plus avancée du marché.)
- TOP !
- Je suis le pilote « standard », très rapide et les développeurs de ce pilote préfèrent la sécurité plutôt que de suivre la spécification à 100 %. Les développeurs jouant avec OpenGL utilisent mon pilote car il possède les extensions les plus amusantes..."


Blague à part, j'avais un doute entre Vendor 1 et Vendor 2, mais il a été levé en lisant cela :

Citation Envoyé par LittleWhite Voir le message
Vendor 1
(...)
La plupart des choses que vous entendez pour concurrencer Mantle/Direct3D 12
Mantle -> AMD, donc:

Vendor 1 : nVidia
Vendor 2 : AMD
Vendor 3 : Intel (aucun doute là-dessus)

Citation Envoyé par LittleWhite Voir le message
Vous étiez-vous déjà aperçu de cet état de fait ?
En partie.

J'étais mort de rire en lisant cela :

Citation Envoyé par LittleWhite Voir le message
Vendor 3 - Pilote 1

C'est compliqué d'être sincèrement en colère contre ce troisième développeur. Ils ne veulent pas faire de graphismes. Ils ne le font que par distraction, la mode étant de tout intégrer sur une même puce et vu qu'ils ont énormément d'espace à partager sur celle-ci, ils le font. (...)
Ils ont actuellement tellement d'argent et que leur organisation est si grande qu'ils peuvent se permettent d'avoir deux équipes différentes de développeurs pour le pilote !
Tellement vrai !

ou encore ça :

Citation Envoyé par LittleWhite Voir le message
Vendor 2

Le pilote est complètement désordonné, possède des performances inconsistantes, est très bogué et les tests de régression sont incomplets, même le parallélisme du pilote est hors contrôle des développeurs officiels. Malheureusement, les GPU de ce constructeur sont standards et sont très corrects, donc vous ne pouvez pas les ignorer.
Et c'est pas nouveau.

Déjà en 1999, je trouvais que le hardware ATI était sensationnel mais leurs pilotes complètement horribles. Ils se sont beaucoup améliorés depuis, mais ce n'est pas la panacée.
0  0 
Avatar de Juda-Priest
Membre actif https://www.developpez.com
Le 15/05/2014 à 11:06
Sans vouloir être critique ou méchant, j'ai eu du mal à saisir l'article traduit, j'ai du faire un tour sur la source (Ce qui n'est pas un mal) .

En tout cas, comme les posts précédant, c'est surement Nvidia, AMD, INtel. Mais bon... Personne ne parle de la situation encore plus catastrophique côté mobile.
0  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 16/05/2014 à 6:45
Pas mieux sur le classement :
  1. nVidia
  2. ATI-AMD
  3. Intel
0  0 
Avatar de Juda-Priest
Membre actif https://www.developpez.com
Le 16/05/2014 à 10:22
Citation Envoyé par LittleWhite Voir le message
Personne ?
Pourtant, il y a quelques mois, il y a eu cette news, où les développeurs de Dolphin, cherchant à faire un portage Android, on taillé dur dans les implémentation mobiles : Les développeurs de Dolphin dressent un tableau de la qualité du support d'OpenGL
Merci de souligner ce point LittleWhite, j'avais lu cet article en diagonale et je n'avais pas prêté attention à ce détail.

Je voulais surtout faire remonté qu'il y-a plus de bruit pour les fixes que pour les mobiles, alors que la situation n'est pas fameuse, pire, voire médiocre.
0  0