Mesa llvmpipe ou SwiftShader pour Chromium sous Linux

Un serveur Linux sans GPU a quand même besoin d'un rastériseur logiciel pour offrir un WebGL fonctionnel à Chromium. Avec ANGLE, il y a deux choix pratiques : SwiftShader, et Mesa llvmpipe, atteint par le backend OpenGL d'ANGLE. Dans la mesure de BotBrowser, une session headed sur un écran virtuel (Xvfb) a exécuté environ 25 secondes de dessin Canvas 2D plus un shader WebGL2. SwiftShader a consommé environ 999 % de CPU pour cette charge et Mesa llvmpipe environ 513 %. Cela représente environ 49 % de CPU en moins, avec WebGL1, WebGL2 et l'adaptateur WebGPU toujours disponibles dans les deux cas.

TL;DR

• Dans la mesure headed sur Xvfb, SwiftShader a utilisé environ 999% de CPU et Mesa llvmpipe environ 513%, soit environ 49% de moins, avec WebGL1, WebGL2 et l'adaptateur WebGPU toujours disponibles.
• En mode headless par défaut, les deux backends ont consommé environ 713.5% et 713.3% : la migration y apporte une stabilité de capacités, pas du CPU.
• La voie llvmpipe tient en deux options, --use-angle=gl --bot-gpu-emulation=false, après installation de libgl1-mesa-dri, libglx-mesa0, libegl-mesa0 et libvulkan1.
• --disable-gpu seul fait renvoyer null à requestAdapter() et casse getContext('webgl') et getContext('webgl2'), et il l'emporte sur --use-angle=gl quand les deux sont présents.
• La ligne lavapipe à environ 153% perd WebGL2 et l'adaptateur WebGPU sous Ubuntu 22.04, donc son CPU plus bas n'est pas comparable.

Sommaire

• Ce que montre la mesure
• Pourquoi SwiftShader coûte plus ici, et en quoi les trois backends diffèrent
• Pourquoi --disable-gpu seul supprime les adaptateurs WebGL et WebGPU
• La configuration llvmpipe à deux options
• Écarts de sortie entre rastériseurs et reproductibilité par graine
• Déploiement par hôte canari sur un parc Linux

Ce que montre la mesure

Le résultat a une limite claire. Il provient d'une seule charge headed sur écran virtuel, sur un hôte Ubuntu 22.04 x86_64 avec un profil Windows 11, en additionnant le CPU de ps sur tous les processus Chromium et en moyennant deux exécutions. Il ne décrit pas toutes les charges ni tous les hôtes. En mode headless par défaut, les deux backends consomment presque le même CPU.

Mode	Backend	CPU moyen	Ce que cela signifie
Headed sur Xvfb	SwiftShader	~999 %	Référence
Headed sur Xvfb	Mesa llvmpipe	~513 %	Environ 49 % de moins que la référence
Headed sur Xvfb	Mesa lavapipe	~153 %	WebGL2 désactivé, inutilisable en production
Headless par défaut	SwiftShader avec l'ensemble complet d'options unsafe	~713.5 %	Référence
Headless par défaut	Mesa llvmpipe	~713.3 %	CPU à peu près égal, pic de mémoire supérieur d'environ 100 MB

La ligne lavapipe est un avertissement, pas une recommandation. Son faible CPU vient d'une configuration qui perd WebGL2 et l'adaptateur WebGPU, si bien que le gain n'est pas comparable à celui des deux autres lignes.

Lisez le tableau selon le mode que vous utilisez. Si une partie de votre pipeline est headed, par exemple un écran virtuel pour des captures, des vérifications manuelles ou l'ancien chemin headless, le gain de CPU est réel. Si vous utilisez déjà le mode headless par défaut, n'attendez pas de gain de CPU. La raison de migrer est alors d'obtenir un WebGL, un WebGL2 et un WebGPU stables sans dépendre des options --enable-unsafe-*. Pour savoir quoi comparer entre sessions headless et headed, consultez Cohérence des profils entre navigateurs headless et headed, qui explique comment consigner la paire prise en charge et classer les différences.

La même lecture, organisée par type de déploiement, donne ceci :

Type de déploiement	Attente côté CPU	Raison de migrer
Session headed sur écran virtuel	Plus faible avec llvmpipe, dans l'ordre de grandeur mesuré ici	Gain de CPU et ensemble d'options plus petit
Ancien chemin headless ou pipelines de captures exécutés en headed	Plus faible avec llvmpipe, à vérifier sur votre propre charge	Gain de CPU et compatibilité future
Mode headless par défaut	À peu près comme SwiftShader	WebGL et WebGPU stables sans options unsafe
Déploiement figé pour l'instant	Aucun changement tant que vous ne migrez pas	Planifiez la migration avant la prochaine mise à jour majeure de Chromium

Pourquoi SwiftShader coûte plus ici, et en quoi les trois backends diffèrent

SwiftShader est un rastériseur CPU qui implémente OpenGL ES et Vulkan en logiciel. Chaque appel de shader s'exécute sur les cœurs du processeur, ce pour quoi il a été conçu. Il est autonome et n'a pas besoin des paquets Mesa du système, ce qui en fait le chemin sur lequel beaucoup de parcs Linux atterrissent par défaut.

Une valeur de 999 % signifie qu'environ dix cœurs de CPU étaient occupés pendant la charge. Multipliez cela par le nombre d'instances d'un hôte et le backend de rendu devient une part importante du budget CPU. La mesure montre l'écart entre les backends, mais elle n'isole pas la raison pour laquelle l'un coûte moins que l'autre, elle n'affirme donc rien sur leur fonctionnement interne.

Mesa documente llvmpipe comme un rastériseur logiciel qui utilise LLVM pour générer du code à l'exécution et qui s'exécute en multithread sur les cœurs du processeur. Sur un serveur sans GPU matériel, Mesa le sélectionne automatiquement lorsque ANGLE vise la pile OpenGL du système.

ANGLE est la couche que Chromium utilise pour traduire les appels WebGL vers une API graphique native, et l'option --use-angle choisit l'API visée. Ce choix décide quel rastériseur logiciel fait le travail. Trois chemins existent :

• SwiftShader via ANGLE est la solution de repli historique. Les versions récentes de Chromium la gardent derrière --enable-unsafe-swiftshader, et le mot unsafe dans ce nom est le signal d'upstream que ce chemin n'est plus celui par défaut.
• Mesa llvmpipe via ANGLE GL utilise --use-angle=gl. ANGLE s'adresse à la libGL du système, et Mesa la lie à llvmpipe lorsqu'aucun GPU matériel n'est présent. Les points d'entrée WebGL1, WebGL2 et WebGPU restent disponibles, et aucune option de la configuration n'est étiquetée unsafe.
• Mesa lavapipe via ANGLE Vulkan est le rastériseur Vulkan logiciel. Il exige des extensions Vulkan qu'ANGLE attend pour WebGL2, et toutes les versions de Mesa ne les fournissent pas.

Backend	Options requises	Adaptateur WebGPU	WebGL1	WebGL2	Compatible à l'avenir
Mesa llvmpipe (recommandé)	--use-angle=gl --bot-gpu-emulation=false	oui	oui	oui	oui
SwiftShader	--disable-gpu --enable-unsafe-swiftshader --use-gl=angle --ignore-gpu-blocklist	oui	oui	oui	obsolète et protégé par unsafe
Mesa lavapipe, bare metal, Ubuntu 22.04	--use-angle=vulkan --enable-features=Vulkan,DefaultANGLEVulkan,VulkanFromANGLE	non (null)	oui	non	oui sur Ubuntu 24.04 et suivantes
Mesa lavapipe, Docker, toute distribution	identique à la ligne précédente	non (null)	non	non	non viable en production
--disable-gpu seul	--disable-gpu seul	non (null)	non	non	utilisable seulement avec des options supplémentaires

navigator.gpu en tant que propriété est présent sur toutes les lignes. La colonne WebGPU indique si navigator.gpu.requestAdapter() renvoie un adaptateur utilisable. Pour comprendre comment l’adaptateur est exposé et ce qu’il révèle, consultez Fingerprinting WebGPU : la nouvelle génération de pistage GPU, qui couvre les détails de l’adaptateur et la façon de les contrôler.

Lavapipe mérite un examen plus attentif, car son chiffre de CPU est tentant. Sur Ubuntu 22.04, le Mesa 23.2 empaqueté ne fournit pas toutes les extensions Vulkan dont ANGLE a besoin pour WebGL2. WebGL1 fonctionne encore en bare metal, mais WebGL2 échoue et l'adaptateur WebGPU est null. Dans Docker, le chargement de l'ICD Vulkan est lui aussi fragile, si bien que lavapipe ne démarre souvent pas du tout et que WebGL1 cesse de fonctionner également. Ubuntu 24.04 avec Mesa 24.2 ou plus récent améliore le cas bare metal, tandis que le comportement en conteneur reste peu fiable aujourd'hui. Réexaminez lavapipe lorsque vos hôtes utiliseront un Mesa plus récent, et d'ici là considérez-le comme pas encore prêt pour la production sur la configuration testée.

Les projets upstream décrivent eux-mêmes leur rôle en termes simples. Le README d'ANGLE présente ANGLE comme la couche qui traduit les appels OpenGL ES vers d'autres backends graphiques tels que Vulkan et OpenGL de bureau, ce qui explique qu'une seule valeur de --use-angle suffise à faire passer Chromium d'un rastériseur à l'autre. Le dépôt SwiftShader décrit une implémentation de l'API graphique Vulkan fondée sur le CPU, qui apporte l'indépendance vis-à-vis du matériel. La documentation de Mesa décrit llvmpipe comme faisant partie des pilotes logiciels Gallium que Mesa maintient. Ensemble, ces sources expliquent pourquoi llvmpipe est un chemin logiciel pris en charge et non une porte de secours.

L'option SwiftShader est aussi une question de calendrier. Chromium a marqué ce chemin comme protégé par unsafe, ce qui laisse penser qu'il pourrait ne pas rester disponible, mais aucune date de retrait n'est publique. Les pipelines qui en dépendent perdront WebGL si l'option est un jour retirée, et migrer tôt transforme donc une bascule forcée en changement planifié.

Pourquoi --disable-gpu seul supprime les adaptateurs WebGL et WebGPU

De nombreux tutoriels Chromium pour Linux suggèrent --disable-gpu comme correctif en une ligne des problèmes de rendu sur serveur. Sur le Chromium actuel, cette option seule désactive la découverte d'adaptateurs WebGPU et les deux contextes WebGL. navigator.gpu reste présent, mais requestAdapter() renvoie null, et getContext('webgl') comme getContext('webgl2') échouent. Canvas 2D continue de fonctionner, ce qui explique que le problème passe souvent inaperçu jusqu'à ce qu'une page ait besoin de WebGL.

De nombreux déploiements de production évitent cet échec parce qu'ils empilent des options de contournement au-dessus de --disable-gpu :

--disable-gpu
--enable-unsafe-swiftshader
--enable-unsafe-webgpu
--use-gl=angle
--ignore-gpu-blocklist

Chaque option de cette pile a un rôle distinct. --enable-unsafe-swiftshader garde le chemin SwiftShader disponible, --enable-unsafe-webgpu garde le chemin WebGPU logiciel disponible, --use-gl=angle force le branchement d'ANGLE et --ignore-gpu-blocklist ignore la liste de blocage GPU de Chromium. Aucune n'est nécessaire sur le chemin llvmpipe.

Cette pile de cinq options fonctionne au sens où WebGL1, WebGL2 et l'adaptateur reviennent. Elle attache aussi le déploiement au chemin SwiftShader et à quatre options dont le nom contient unsafe ou ignore. Chaque mise à jour de Chromium pose alors la question de savoir si l'une de ces options a changé de comportement.

Il y a un autre piège. --disable-gpu l'emporte sur --use-angle=gl, en modes headed comme headless. Si vous ajoutez l'option Mesa en laissant --disable-gpu, llvmpipe n'entre jamais en jeu et la configuration donne l'impression que la migration n'a rien changé.

La sortie la plus propre consiste à supprimer --disable-gpu et les quatre options de contournement, puis à remplacer tout le groupe par les deux options de la section suivante. Un opérateur qui sait nommer la pile de cinq options, la pile de deux options et la raison pour laquelle --disable-gpu seul supprime la découverte d'adaptateurs a compris toute la migration.

La configuration llvmpipe à deux options

Installez d'abord les paquets Mesa en espace utilisateur qui permettent à ANGLE d'atteindre llvmpipe :

sudo apt-get update
sudo apt-get install -y \
    libgl1-mesa-dri \
    libglx-mesa0 \
    libegl-mesa0 \
    libvulkan1

Lancez ensuite avec les deux options. En mode headless par défaut, aucun affichage n'est nécessaire :

chromium-browser \
    --headless \
    --no-sandbox \
    --user-data-dir="$(mktemp -d)" \
    --bot-profile="path/to/profile.enc" \
    --use-angle=gl \
    --bot-gpu-emulation=false

Pour une session headed sur écran virtuel, retirez --headless et fournissez un affichage :

DISPLAY=:10.0 chromium-browser \
    --no-sandbox \
    --user-data-dir="$(mktemp -d)" \
    --bot-profile="path/to/profile.enc" \
    --use-angle=gl \
    --bot-gpu-emulation=false

--use-angle=gl fait passer ANGLE par la pile OpenGL du système, et Mesa charge llvmpipe lorsqu'aucun GPU matériel n'est présent. --bot-gpu-emulation=false demande à BotBrowser de laisser le vrai pilote GL produire le rendu WebGL, tandis que le bruit Canvas 2D et la couche de variation de --bot-noise-seed restent actifs. L'option est volontairement étroite : elle ne désactive ni le profil ni le reste de la protection d'empreinte.

--bot-gpu-emulation accepte trois valeurs. false est le réglage de cette migration. true est le mode standard par défaut. priority ajoute un ordonnancement GPU prioritaire pour les charges avec de nombreux contextes concurrents dans une instance du navigateur, fonctionne indépendamment du choix du backend GL et devient inutile dès que false confie le travail GPU au vrai pilote.

Lorsque vous migrez un déploiement existant, retirez ces options avant d'ajouter les deux nouvelles. Plusieurs entrent en conflit avec --use-angle=gl, et n'importe laquelle peut annuler le changement sans aucune erreur.

Option à retirer	Raison
--disable-gpu	Désactive la découverte d'adaptateurs et les deux contextes WebGL, et l'emporte sur --use-angle=gl
--enable-unsafe-swiftshader	Nécessaire seulement pour garder SwiftShader en vie
--use-gl=swiftshader	Choix explicite de SwiftShader, remplacé par llvmpipe
--use-gl=angle	Ancienne forme remplacée par --use-angle=gl et susceptible d'entrer en conflit avec elle
--ignore-gpu-blocklist	Inutile, car llvmpipe ne figure pas sur la liste de blocage
--enable-features=Vulkan,DefaultANGLEVulkan,VulkanFromANGLE	Impose le chemin lavapipe, qui désactive WebGL2 en bare metal sous Ubuntu 22.04
--use-angle=vulkan	Force le même chemin lavapipe
--disable-vulkan-surface	Ne concerne que le chemin Vulkan

Dans un conteneur, ajoutez les mêmes quatre paquets Mesa à l'image et passez les deux mêmes options au lancement. Exécuter le conteneur avec --shm-size=2g donne plus de mémoire partagée à Chromium et améliore la stabilité. Rappelez-vous que lavapipe est le backend qui échoue en conteneur, un déploiement en conteneur est donc une raison de plus de rester sur llvmpipe via ANGLE GL.

Conservez --headless, --no-sandbox si vous l'utilisiez déjà, toutes les options --bot-* dont --bot-profile et --bot-noise-seed, ainsi que vos réglages réseau et --user-data-dir. Pour les lancements avec Playwright ou Puppeteer, les mêmes options vont dans la liste args :

const browser = await chromium.launch({
  executablePath: 'path/to/botbrowser',
  args: ['--use-angle=gl', '--bot-gpu-emulation=false', '--bot-profile=path/to/profile.enc'],
});

Écarts de sortie entre rastériseurs et reproductibilité par graine

Des rastériseurs logiciels différents produisent des pixels différents pour le même shader. Après le passage de SwiftShader à Mesa llvmpipe, les octets exacts de readPixels ou de toDataURL seront différents. C'est le comportement attendu de deux rastériseurs distincts, pas le signe d'un échec de la migration.

Les champs qu'une page lit comme identité restent sous le contrôle du profil. User-Agent, plateforme et chaînes de fournisseur et de moteur de rendu non masquées viennent de votre profil et ne changent pas avec le backend. Le comportement de --bot-noise-seed ne change pas non plus : la même graine reproduit la même sortie dans le backend choisi, et une graine différente produit une sortie différente et stable.

Deux règles pratiques en découlent. Conservez des captures de référence par backend au lieu de comparer des octets entre SwiftShader et llvmpipe. Et lorsque vous comparez avant et après une migration, comparez des exécutions du même backend avec la même graine, afin qu'une vraie régression ne soit pas masquée par un écart attendu entre rastériseurs.

Déploiement par hôte canari sur un parc Linux

Validez le changement sur un hôte canari avant de toucher au reste du parc. La séquence suivante garde chaque étape observable :

1. Installez libgl1-mesa-dri, libglx-mesa0, libegl-mesa0 et libvulkan1 sur l'hôte canari.
2. Remplacez la pile d'options GPU par --use-angle=gl --bot-gpu-emulation=false sur une instance et redémarrez-la, car les changements d'options ne sont lus qu'au lancement.
3. Confirmez que les contextes WebGL1 et WebGL2 sont créés et que navigator.gpu.requestAdapter() renvoie un adaptateur non null.
4. Ouvrez chrome://gpu et vérifiez que les lignes WebGL, WebGL2 et WebGPU indiquent un rendu logiciel via ANGLE et OpenGL plutôt que désactivé. La même page affiche la chaîne ANGLE et pilote active, ce qui confirme que llvmpipe est utilisé.
5. Échantillonnez le CPU face à une référence SwiftShader équivalente, dans le même mode headed ou headless et sous la même charge.
6. Répétez les vérifications avec la même graine et avec une graine différente, puis étendez le changement au reste du parc.

Le tableau suivant relie les symptômes les plus courants à leur cause habituelle.

Symptôme	Cause habituelle	Correctif
Adaptateur null et échec des deux contextes WebGL	--disable-gpu seul, ou lavapipe dans Docker	Retirez --disable-gpu et les options Vulkan, gardez seulement les deux options
WebGL1 fonctionne, WebGL2 et adaptateur null	lavapipe en bare metal avec un Mesa ancien	Retirez les options Vulkan et passez à --use-angle=gl
libGL error: failed to load driver: swrast	Les paquets Mesa en espace utilisateur sont absents	Installez libgl1-mesa-dri, libglx-mesa0 et libegl-mesa0
chrome://gpu affiche encore SwiftShader	Une option le réimpose, comme --use-gl=swiftshader	Retirez l'option et redémarrez le processus
Le CPU n'a pas baissé	Mode headless par défaut, où la charge domine	Normal, la valeur y est la stabilité et la compatibilité future
La sortie de pixels WebGL a changé	Rastériseur différent	Normal, reconstruisez la capture de référence pour le nouveau backend

Une comparaison équivalente est ce qui rend le chiffre de CPU fiable. Utilisez le même hôte, le même profil, la même charge et le même mode pour les deux backends. Exécutez une charge assez longue pour garder le rendu occupé, par exemple environ 25 secondes de dessin Canvas 2D avec un shader WebGL2. Additionnez le CPU de tous les processus Chromium de l'instance, répétez l'essai au moins deux fois et faites la moyenne des exécutions pour qu'un bref pic de charge de l'hôte ne décide pas du résultat. Un gain mesuré dans un mode ne dit rien de l'autre mode, lancez donc la référence dans le mode que vous livrez. Pour savoir comment examiner la sortie de Canvas, WebGL et WebGPU selon le backend, consultez Valider la confidentialité selon le backend de rendu, qui couvre une matrice de rendu et un ordre de test contrôlé.

Prévoyez le cas où le CPU ne bouge pas. En mode headless par défaut, le rendu va dans un tampon hors écran quel que soit le backend actif, si bien que le travail Canvas et WebGL domine et que les deux backends coûtent à peu près autant. La migration reste utile dans ce cas, sous la forme d'une stabilité des capacités et d'un ensemble d'options plus petit qui ne dépend pas d'options unsafe.

BotBrowser documente un chemin de backend GPU sous Linux où --use-angle=gl avec --bot-gpu-emulation=false permet à Mesa llvmpipe de produire le rendu WebGL tandis que le bruit Canvas 2D et la reproductibilité de --bot-noise-seed restent actifs, ce qui vous permet de valider la migration à deux options sur un hôte canari avant de changer le reste du parc. BotBrowser ne peut pas rendre Mesa llvmpipe plus rapide que l'hôte ne le permet, ne garantit pas de gain de CPU en mode headless par défaut, ne peut pas garder identiques les octets de pixels WebGL d'un rastériseur à l'autre et ne contrôle pas le calendrier d'upstream Chromium pour la dépréciation de SwiftShader. L'option --bot-gpu-emulation exige ENT Tier 2.

Pour la préparation de base de l'hôte, lisez le guide de configuration d'un serveur headless et le guide de déploiement Docker. Pour le comportement de la graine d'un backend à l'autre, lisez la reproductibilité de la graine de bruit. La référence complète des options se trouve dans le guide de déploiement du backend GPU Linux.

Sources publiques

• BotBrowser Linux GPU backend selection
• Documentation Mesa llvmpipe
• Dépôt SwiftShader
• README d'ANGLE

Conclusion pratique

Supprimez --disable-gpu et les quatre options d'échappement, installez les quatre paquets Mesa, puis démarrez avec --use-angle=gl --bot-gpu-emulation=false sur un hôte canari avant de toucher au parc. Rejouez ensuite la même charge d'environ 25 secondes dans le mode que vous livrez réellement, car une économie headed d'environ 49% ne dit rien du headless par défaut, et gardez la comparaison de graine sur deux sessions pour que les écarts de sortie entre rastériseurs restent visibles.