URL: https://linuxfr.org/users/kalenx/journaux/chromium-n-aime-pas-la-nouveau-te Title: Chromium n'aime pas la nouveau-té Authors: Kalenx Date: 2019年01月07日T19:15:15+01:00 License: CC By-SA Tags: nouveau, ubuntu, nvidia et chromium Score: 45 (vous m'excuserez pour le jeu de mots du titre, mais à quoi bon baptiser des projets libres avec des noms francophones si on ne peut pas s'en servir pour ça) Alors que Linus nous rappelle [qu'il n'aime pas les nombres qu'il ne peut compter avec ses doigts et orteils](https://lore.kernel.org/lkml/CAHk-=wgKYnrL3LjhVkH2Fp+ecmWhLqezT9zmR6CzfcpwcJX0qA@mail.gmail.com/T/#u), un autre débat intéressant se profile : que choisir entre collaboration entre projets libres et satisfaction de l'utilisateur? Pour être plus précis, supposons que : 1. Vous êtes responsable d'un logiciel libre utilisé par des millions de personnes 2. Votre logiciel utilise certains périphériques pour améliorer l'expérience utilisateur 3. Parmi les pilotes (libres!) des dits périphériques, certains sont de mauvaises qualité et tendent à faire planter votre produit Vous avez le choix A) de travailler avec les développeurs des pilotes problématiques pour les améliorer ou B) de "blacklister" le pilote en question dans votre logiciel et de fermer les rapports de bugs le concernant. C'est moins efficace pour vos utilisateurs, mais votre logiciel fonctionne encore et ne plante plus. Que serait votre décision? Pour Chromium, la liste noire est la bonne solution ----------- Un [rapport de bug de cet automne](https://bugs.chromium.org/p/chromium/issues/detail?id=876523) rapporte un problème de corruption graphique, avec le driver nouveau (le pilote libre des cartes nVidia, inclus par défaut dans la plupart des distributions). Rien de trop étonnant de prime abord. Toutefois, la réponse des développeurs est quelque peu brutale :> Over the years we receive many bug reports related to nouveau driver statibility, so we draw the conclusion nouveau is unstable not just from this bug report, but from a aggregation of many. [...] We thought about blacklisting nouveau driver long time ago, and decided to let more adventurous users to play around. Now that Ubuntu ships with nouveau on default, maybe it's time to blacklist it in Chrome. [...] So we will disable all GPU acceleration by default. [...] As mentioned in #37, we don't have the resources in house to test and debug nouveau related issues. If community can narrow down a finer scope, we'll reconsider. We want a stable & secure browser first, a GPU-accelerated one second, only if possible. The default [nouveau] driver on Ubuntu LTS has severe issues, asking non-technical users to update their driver is just not acceptable as a prerequisite to use Chrome. Pour résumer la position des devs de Chrome, donc : trop de problèmes avec nouveau, pas le temps de les régler/identifier de leur côté, les mises à jour corrigeant les problèmes de nouveau n'arrivent pas assez vite aux utilisateurs, donc le pilote est purement et simplement mis en liste noire (tout est alors rendu côté CPU). Le fondement de leur décision semble être "nous voulons offrir un produit stable à nos utilisateurs en premier lieu, et nouveau va à l'encontre de cet objectif". Du côté de nouveau ----------- Je ne suis pas lié de près ou de loin au développement de nouveau. La seule chose que je sais est que son développement est rendu malaisé par la volonté manifeste de nVidia de n'apporter aucune aide ([voire de nuire](https://www.phoronix.com/scan.php?page=news_item&px=Nouveau-XDC2017)). Toutefois, un élément semble particulièrement choquer les développeurs de nouveau, et [c'est celui de devoir se battre contre des fantômes](https://lists.freedesktop.org/archives/nouveau/2019-January/031798.html) :> they (at the end) suggested that we try to make nouveau a first-class citizen with chromium. However I will never be able to present concrete evidence that inconcrete issues are resolved. I did run the WebGL CTS suite, but that resulted in some hangs from the the max-texture-size-equivalent test, and some browser-level weirdness after some tests where later tests all fail (due to what I have to assume is a browser bug). I don't think I managed to properly track down the true reason why. I didn't want to reach out to them with such results, as that's just further evidence of nouveau not working perfectly. En gros, les tests demandés plantent de manière régulière sur des éléments soit non liés au driver, soit des tests carrément fautifs, soit qui correspondent à des cas d'utilisation extrêmement restreints (le cas de charger une texture de>2Go est évoqué). Alors que la situation actuelle est que ce sont les utilisateurs qui sont aussi pénalisés :> In the meanwhile, end users are losing accelerated WebGL which in practice worked just fine (at least in my usage of it), and probably some other functionality. Au final, les moyens proposés pour son retrait de la blacklist sont totalement hors de portée des capacités techniques de nouveau (en termes d'effort de développement). Cela soulève plusieurs questions : ### 1) Nouveau est-il réellement significativement plus problématique que les autres pilotes? Je n'ai pas forcément de réponse à cette question, mais les développeurs de nouveau soutiennent qu'on leur demande beaucoup plus que les autres pilotes. Tout pilote graphique aura des bugs, c'est indéniable. À partir de quand considère-t-on que c'est "trop"? ### 2) Est-ce vraiment du ressort de Chrome de décider quel driver peut être utilisé ou non? Un des éléments d'achoppement qui ressort est que les devs de chromium se placent ici en conflit avec les décisions des utilisateurs -- ou, à défaut, des distributions qui décident des drivers à inclure ou non. Si chaque logiciel se met à décider de ce qu'il "accepte" ou non, on s'en va vers un fouillis indescriptible et très difficile à corriger. ### 3) N'y a-t-il pas de solutions intermédiaires? La liste noire appliquée à toutes les configurations utilisant nouveau, quel que soit le GPU ou la version du pilote, constitue l'option nucléaire ici. Il est vrai qu'il y aurait clairement moyen d'au moins restreindre ce genre de filtre, surtout qu'il appert que la plupart des configurations fonctionnent bien. Même le cas du bug qui a tout déclenché est révélateur : sans dire qu'il s'agit d'un problème bénin, il s'agit tout de même d'une corruption sans plantage qui ne s'affiche que sur certains sites après plusieurs heures d'utilisation. On est loin d'un crash sans appel 10 secondes après chaque démarrage. De plus, les développeurs de nouveau ont suggéré aux devs de Chromium de fermer automatiquement tout rapport de bug concernant nouveau et de le rediriger, encore une fois automatiquement, vers freedesktop.org, ce qui nécessiterait au final très peu d'efforts pour Chromium. De ce qu'est un écosystème ----------- Je ne crois pas que les devs de Chromium aient pris la bonne décision ici. Les bugs dus au driver nouveau ne sont pas leurs problèmes, c'est indéniable. Mais justement, en décidant unilatéralement de prendre position simplement tout mettre en liste noire, ça _devient_ leur problème! Aux temps glorieux (hum) des débuts de KDE 4, de nombreux problèmes avaient été soulevés avec cette fois le pilote nvidia propriétaire ([exemple](https://www.osnews.com/story/20857/kde-42-released-short-interview-aaron-seigo/)). La solution des devs de KDE n'avait pas pour autant été de tout blacklister, non plus que d'implémenter des mesures de contournement sans fin : la solution avait été de laisser ces bugs documentés jusqu'à ce que nVidia les corrige finalement. Tout cela avait au final amélioré tout l'écosystème. La solution de la liste noire peut sembler alléchante _localement_ pour les devs de Chromium, mais elle n'est clairement pas la bonne solution _globale_. Et en attendant, les utilisateurs de Chromium avec nouveau n'ont simplement plus aucune accélération graphique et ce **même s'ils utilisent une configuration qui n'est pas/plus affectée**... Beau succès... Pour finir ----------- Un développeur de nouveau a proposé de simplement "mentir" à Chromium en faisant croire qu'il s'agit d'un autre pilote (avec GL_VENDOR). Je crois qu'il ne s'agirait là que d'une escalade dans ce conflit, qui ne règlerait absolument rien, si ce n'est déclencher une nouvelle bataille de "comment détecter/cacher un driver via autre chose que GL_VENDOR" et couper tous les ponts restants avec l'équipe de Chromium. Répondre à un coup bas par un autre coup encore plus bas n'a pas le potentiel d'améliorer grand chose...