Faudrait qu’ils se bougent le cul sous linux, avec les grosses franchises qui commencent à débarquer, on voit clairement que Nvidia a beaucoup d’avance sur eux, ou les perfs sont même supérieures par rapport à Windows, là ou AMD fait moitié moins avec filtres, sans parler des bugs graphiques et des soucis de fonctionnalités manquantes et défauts d’initialisation des cartes…







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.

Tirr Mohma a écrit :



Rome total War II (au hasard) ^^



Je suis d’accord monter un PC avec du AMD complet et vouloir installer un linux dessus c’est être maso.







Et Metro Last Light, Xcom , L4D 1&2, Civilisation V, les Half Life, Portal, SS3… Et pas mal de rumeurs du côté de Blizzard, et Deep Silver. (Et côté jeux peu gourmand, y’en a une floppée aussi, entre trine, worms, hotline miami, etc…)



Sinon AMD ça fonctionne plutôt bien sous Linux, tant qu’on ne joue pas (trop)… Et comme le rapport hardware/efficience/prix est souvent à leur avantage, j’en avais pris une l’année dernière… Parfois je regrette un peu mon choix…

Cara62 a écrit :



Déjà que amd ne met pas à jour pour les CG switchable, en tout cas sous W8.

Même pas la peine d’essayer sur mon linux….







Y’a quand même eu de grosses améliorations depuis les pilotes 13.XX, pour la série Radeon HD 7XXX, mais c’est loin d’être parfait, on le sent bien sur les gros jeux (avec Metro LL, c’est bien flag !), et surtout, le support des anciennes cartes a été complètement délaissé, alors que Nvidia propose encore le support via leurs drivers, d’aussi vieilles cartes que les Gforce 2 MX…



Du coup si la prochaine fois, je dois mettre 50 ou 60€ de plus pour un meilleur support/service, je le ferais… " />

Mais c’est dommage, côté efficience énergétique sur les cartes moyen de gamme, pour l’instant AMD s’en sort un peu mieux…