La vérité sur la qualité des pilotes graphiques OpenGL

Un développeur revient sur les différents pilotes OpenGL disponibles

Le 13 mai 2014 à 22:51, par LittleWhite

0PARTAGES

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