Dolphin est un émulateur GameCube/Wii Open Source en développement depuis dix ans. La version 4.0 célèbre cet anniversaire et les développeurs en profitent pour dresser un récapitulatif du support d'OpenGL par les différents constructeurs dans l'espoir que le support s'améliore.
Ce classement prend en compte le nombre de bogues trouvés ainsi que la difficulté pour avoir du support de la part des constructeurs. Voici le récapitulatif :
- NVIDIA : excellent
- Mesa : bon
- Intel HD Graphics : bon
- AMD : médiocre
- ARM/Mali : mauvais
- Qualcomm/Adreno : horrible
NVIDIA
Le support d'OpenGL du côté de NVIDIA, que ce soit pour Linux ou pour Windows est excellent. L'équipe de développeurs a tout de même rencontré quelques difficultés, mais sans que cela ne soit directement des bogues. Par exemple, NVIDIA ne propose pas de stockage du coté du client pour les tampons mémoire (alors que AMD le fait), ce qui pouvait considérablement améliorer les performances de l'émulateur. De plus, avoir du support de NVIDIA pour les développeurs Open Source sur les forums est difficile. Toutefois, après la mise en ligne de l'article trois personnes ont contacté les auteurs pour offrir leur aide.
Mesa
L'équipe de développement du projet Mesa, l'implémentation libre d'OpenGL offre un support très convenable. En effet, même si quelques bogues ont été rencontrés, ils ont été corrigés rapidement après avoir été rapportés. Voici quelques exemples :
- retour incorrects de fonctions GLSL intégrées, corrigé dans Mesa 9.1.1, sept jours après ;
- effets de tramage avec les Uniform Buffer Objects, corrigé dans Mesa 9.2.0 ;
- écran noir avec la série Radeon r600, corrigé dans un patch dix minutes après en avoir parlé sur IRC, puis intégré le même jour et publié dans la version 9.1.3 ;
- écran noir pour les pilotes nouveaux avec des Uniform Buffer Objects de plus de 64 ko, corrigé par un développeur de Dolphin et intégré le jour suivant pour la version 9.1.6.
Les Uniform Buffer Objects venaient tout juste d'être implémentés dans Mesa et n'avaient pas été spécialement testés par manque d'applications les utilisant intensivement. Grâce à Dolphin, l'implémentation a été rapidement améliorée et a permis ainsi un meilleur support pour l'implémentation libre et de meilleures performances pour l'émulateur.
Intel HD Graphics
Les développeurs ne connaissent pas de bogues liés à ces pilotes. Cela s'explique notamment par le nombre réduit de puces supportant Dolphin : Intel HD3000.
AMD
Beaucoup de problèmes graphiques sont liés au pilote propriétaire AMD pour Linux, alors que ces mêmes bogues ne sont pas présents sous Windows.
Un des bogues les plus connus est la corruption des textures lors de la génération de mipmaps :
Cela arrive lors de la création d'une texture au format GL_UNSIGNED_SHORT_5_6_5 et l'utilisation de la fonction glGenerateMipmap.
Le bogue est rapporté depuis plus de deux ans, mais a été ignoré par les développeurs chez AMD. De plus, le rapport de bogue sur les forums a été supprimé suite à une transition sur un nouveau forum. Les développeurs de Dolphin ne savent pas si cela a été corrigé. En effet, la gestion des niveaux de mipmaps dans l'émulateur a été complètement revue.
La qualité du code pour la partie utilisateur (à contrario de la partie kernel) du pilote est horrible. En effet, valgrind rapporte de nombreuses erreurs à propos de structures non initialisées et d'accès sur des sections mémoires non initialisées. Quelquefois, il arrive même que le pilote ferme directement l'application au lieu de rapporter les erreurs. Ce bogue a aussi été remarqué par les développeurs de la SDL : https://bugzilla.libsdl.org/show_bug.cgi?id=1210.
Il existe aussi quelques bogues dans l'implémentation du pilote pour Windows, notamment lors de l'utilisation de l'extension AMD_pinned_buffer pour les tampons d'index.
Finalement, il existe un bogue tracker non officiel mais celui-ci ne semble pas lu par les développeurs d'AMD.
ARM/Mali
Passons aux puces mobiles. Les développeurs de l'émulateur ont rencontré énormément de problèmes, mais ont finalement réussi à produire un résultat correct :
Il est à noter que :
- les développeurs du pilote semblent faire moins d'assurance qualité que les développeurs de Mesa ;
- il n'existe pas de bonne documentation sur le pilote ;
- le pilote limite les performances du GPU ;
- OpenGL ES 3.0 aurait pu être supporté plus tôt si les pilotes n'étaient pas si mauvais ;
- peu d'applications utilisent les fonctionnalités avancées et donc Dolphin révèle de nombreux bogues restants.
La réponse des développeurs sur les forums est : "Oui, nous savons que cela ne fonctionne pas", sans plus d'informations. Même Google effectue des contournements pour avoir un support satisfaisant.
Toutefois, il existe le projet LIMA, où des développeurs cherchent à recréer un pilote pour ces puces en faisant de la rétroingénierie. Ils arrivent même à avoir de meilleures performances que le pilote du constructeur mais ils sont aussi confrontés à d'énormes difficultés pour continuer leur travail, notamment pour recréer le compilateur de shader.
Qualcomm/Adreno
Il semble que quelques morceaux de code soient les mêmes que pour Mali. Malheureusement, ils partagent aussi les bogues sur les fonctions glBufferSubData et glMapBufferRange. L'équipe de Dolphin n'est pas la seule à avoir des problèmes avec ce pilote : https://developer.qualcomm.com/forum...n-adreno/27030 .
PowerVR
Pour l'instant les puces de Imagination Technologies ne supportent pas OpenGL ES 3.
Votre opinion
Que pensez-vous des propos des développeurs de l'émulateur ? Avez-vous rencontré ces bogues lors de vos développements ?Source
Blog de Dolphin
Bizarrement, malgré toutes nos instructions, ils n'ont pas réussi à reproduire le problème, y compris sur les appareils du commerce sur lesquels nous l'avons rencontré. Du coup, on se demande si ce n'est pas carrément un problème hardware; à mon avis, c'est un problème de fragmentation mal gérée.
