Bromure 5 donne un GPU au navigateur

Les éditeurs de navigateurs vendent la vitesse à coups de chiffres. La page Safari d'Apple présente Safari comme « le navigateur le plus rapide du monde » et, d'après les tests d'Apple d'août 2026, revendique un rendu 5,3x plus rapide que Chrome sous macOS dans MotionMark, un benchmark qui « se concentre sur les performances graphiques ». Google a annoncé « une amélioration de 22 % depuis août 2024 » sur Speedometer, et estimé que cela épargne 116 millions d'heures d'attente aux utilisateurs qui naviguent 10 minutes par jour. En juin 2026, il a publié des scores record de 469 sur JetStream et de 61 sur Speedometer. Microsoft affirme qu'à partir de la version 134, « Microsoft Edge est jusqu'à 9 % plus rapide selon le benchmark Speedometer 3.0 ». Les équipes derrière Blink, Gecko et WebKit ont conçu Speedometer 3.0 ensemble.

Vous comparez Bromure Web à ces navigateurs, il doit donc tenir la cadence.

Un navigateur sans GPU

Bromure Web exécute Chromium dans une VM Linux jetable sur votre Mac. Jusqu'à Bromure 5, cette VM n'avait pas de GPU.

Le framework ParavirtualizedGraphics d'Apple « implémente des graphismes accélérés par le matériel pour macOS exécuté dans une machine virtuelle », la voie prise en charge pour les invités macOS. Pour les invités Linux, le framework Virtualization propose un périphérique graphique Virtio que l'on configure avec une taille d'affichage. Dans notre VM, il donnait un écran à Chromium, sans accélération 3D : Chromium se rabattait donc sur llvmpipe de Mesa, qui exécute OpenGL sur le CPU, et désactivait la composition par le GPU. Les pages affichaient les bons pixels, et les cartes, les graphiques canvas, les visionneuses 3D et les outils de design se traînaient.

Comment Bromure 5 ajoute un GPU

macOS 27 permet à une application d'implémenter son propre périphérique Virtio avec VZCustomVirtioDeviceConfiguration. Bromure 5 s'en sert pour présenter un GPU Virtio standard (type de périphérique 16), si bien que l'invité n'a besoin d'aucun pilote noyau sur mesure. Il utilise Ubuntu 24.04 et le module noyau virtio_gpu d'origine ; l'image de navigateur compatible inclut aussi un Mesa en espace utilisateur figé à une version précise et patché, ainsi que l'intégration vidéo du navigateur.

Une image WebGL suit désormais ce chemin :

1. Chromium dessine via ANGLE sur le pilote VirGL de Mesa.
2. VirGL envoie les commandes OpenGL par les files du GPU Virtio.
3. Un processus de rendu sur le Mac les rejoue via ANGLE sur Metal.
4. La fenêtre du navigateur affiche les images terminées sous forme d'IOSurfaces.

• Un moteur de rendu par VM. Chaque VM de navigation reçoit son propre processus de rendu isolé dans un bac à sable. En test, deux processus ont réutilisé les mêmes identifiants en gardant des surfaces indépendantes, et le second a continué de tourner après la fermeture du premier.
• Curseur natif. macOS dessine le pointeur à partir des images de curseur envoyées par l'invité.
• H.264 en matériel. Bromure relie le décodeur vidéo de l'invité à VideoToolbox. Chromium décode toujours l'AV1 en logiciel.
• Graphismes uniquement. Le périphérique transporte le rendu et le décodage vidéo, sans calcul GPU généraliste : le code dans la VM ne peut pas faire tourner de charges d'apprentissage automatique sur votre GPU.

Les chiffres

Nous avons exécuté une même charge WebGL de trois façons sur un seul Mac : Chrome dans la VM Bromure avec le nouveau moteur de rendu, Chrome dans la même VM sur le périphérique graphique d'Apple (donc sur llvmpipe), et Chrome sous macOS.

Chaque valeur est la médiane de cinq essais, en temps réel écoulé pour terminer un lot de travail GPU. Plus c'est bas, mieux c'est.

Face au rendu logiciel, le nouveau chemin a été 8,1x, 30,0x et 52,1x plus rapide, et l'écart s'est creusé avec la quantité de travail par pixel. Face à Chrome natif, la VM a mis 1,61x, 1,41x et 1,07x plus de temps. Ce sont les nombreux petits appels de tracé qui coûtent le plus, et sur le shader le plus lourd, la VM est arrivée à 7 % du natif.

Configuration : Bromure 5.0.1 sur un Apple M5 Pro à 18 cœurs CPU et 64 Go, sous macOS 27.0.1. La VM tournait sous Ubuntu 24.04 ARM64 avec Mesa 25.2.8, 9 vCPU et 4 Go. Les trois chemins utilisaient Chrome 154.0.8037.57. Chaque mesure commence par une phase de chauffe et se termine par la relecture d'un pixel qui force le GPU à terminer : les temps couvrent donc le navigateur, le pilote et la relecture, et excluent la compilation des shaders.

Amener les images jusqu'à l'écran

Publier au flush. Un invité GPU Virtio désigne d'abord la ressource de scanout, puis effectue un flush une fois le contenu prêt. Notre première version publiait au moment du scanout et pouvait montrer une surface à moitié peinte. Bromure met désormais à jour la fenêtre au moment du flush.

Un maintien borné pendant le redimensionnement. À une nouvelle taille, la première image sort souvent presque noire ou pleine de trous, avant que la page ne se redessine. Pendant un redimensionnement, Bromure garde à l'écran la dernière image peinte pendant une durée bornée tant que la nouvelle semble non peinte, et l'hôte et l'invité cadencent le redimensionnement ensemble. La vérification penche du côté du maintien : une page sombre peut donc avoir un instant de retard pendant un redimensionnement. Hors redimensionnement, les images s'affichent immédiatement.

Lors d'une exécution tracée avec quatre VM, 24 onglets et 40 visites de sites, quatre enregistrements de 200 secondes n'ont présenté aucune image presque noire.

L'alpha du curseur. Linux alloue les images de curseur dans un format sans canal alpha, puis utilise cette mémoire comme un curseur avec alpha. Le moteur de rendu conserve les valeurs alpha écrites par l'invité, si bien que les curseurs restent transparents.

La contre-pression. L'invité peut soumettre des commandes 3D plus vite que l'hôte ne les rejoue. Bromure plafonne chaque soumission à 1 Mio et réutilise une seule file de commandes Metal pour capturer les images.

Comment il a été construit

Astra 6.1 a réalisé toute l'implémentation, sous la forme de deux agents dans Bromure : l'un sur le Mac et l'autre sous Linux. Nous avons fixé les exigences et testé les résultats.

• L'agent macOS a construit le moteur de rendu, le périphérique Virtio, ainsi que l'affichage et les entrées.
• L'agent Linux a construit l'empaquetage de Mesa et de VirGL, les vérifications de prérequis, ainsi que l'agent de pointeur et le surveillant de redimensionnement dans la VM.
• Des tests de non-régression et une revue du code source indépendants ont vérifié le travail en cours de route.

Les deux agents ont travaillé sur la même branche de fonctionnalité partagée. Ils ont échangé messages, pièces jointes, requêtes et preuves de test entre les deux environnements grâce à la messagerie entre agents de Bromure. L'hôte relaie, filtre et journalise les messages, et copie les fichiers joints d'une machine à l'autre. La future application Bromure Sidecar fait partie de cet effort plus large ; nous la présenterons à sa sortie.

L'activer et le désactiver

Dans Bromure 5, le moteur de rendu Metal se trouve sous Performance dans chaque profil Bromure Web. Il est activé par défaut, profils existants compris.

• Il nécessite macOS 27. Sous macOS 26 et versions antérieures, Bromure continue de dessiner en logiciel.
• Le réglage global reste l'interrupteur principal, et les changements s'appliquent aux nouvelles fenêtres.
• Un profil où il est désactivé reçoit sa propre VM sur l'ancien chemin graphique.
• Une image de VM doit porter un marqueur indiquant que nous l'avons validée pour le nouveau moteur de rendu. Sans ce marqueur, Bromure se rabat sur le logiciel.

Nous avons vérifié l'ancien chemin graphique sous macOS 27 et l'avons testé sur un Mac sous macOS 26. Le nouveau code nécessite macOS 27 ou une version ultérieure.