← 返回所有文章
發佈於 · 作者 Renaud Deraison

Bromure 5 給了瀏覽器一顆 GPU

Bromure Web 在一台沒有 GPU 的 Linux VM 裡執行 Chromium，所以每一個 WebGL 影格和每一個合成圖層都由 CPU 來畫。在 macOS 27 上，Bromure 5 讓每台瀏覽器 VM 都有一顆由 Metal 支撐的 GPU。在三種 WebGL 工作負載上，批次時間的中位數從 170、965 和 3,555 ms 降到 21、32 和 68 ms：在同一台 Mac 上跑這些工作負載，完成一個批次的時間比原生 Chrome 多 7% 到 61%。

Web解讀

瀏覽器廠商用數字來賣速度。Apple 的 Safari 頁面稱 Safari 是「全世界最快的瀏覽器」， 並根據 Apple 在 2026 年 8 月的測試，宣稱在 macOS 上的 MotionMark 中渲染速度比 Chrome 快 5.3x；MotionMark 是一個「專注於圖形效能」的基準測試。 Google 回報在 Speedometer 上「自 2024 年 8 月以來提升了 22%」， 並估計這為每天瀏覽 10 分鐘的使用者省下了 1.16 億小時的等待時間。2026 年 6 月，它公布了 JetStream 469 分、Speedometer 61 分的紀錄成績。 Microsoft 說從 134 版起，「以 Speedometer 3.0 基準測試衡量，Microsoft Edge 最多快了 9%」。 Blink、Gecko 和 WebKit 背後的團隊一起打造了 Speedometer 3.0。

你會拿 Bromure Web 和這些瀏覽器比較，所以它必須跟得上它們。

一個沒有 GPU 的瀏覽器

Bromure Web 在你 Mac 上一台可拋棄的 Linux VM 裡執行 Chromium。在 Bromure 5 之前， 那台 VM 沒有 GPU。

Apple 的 ParavirtualizedGraphics 框架「為在虛擬機器中執行的 macOS 實作硬體加速圖形」， 這是 macOS 客體受支援的路徑。對於 Linux 客體，Virtualization 框架提供一個 Virtio 圖形裝置， 你只要設定顯示尺寸即可。在我們的 VM 裡，它給了 Chromium 一個螢幕，卻沒有 3D 加速， 所以 Chromium 退回使用 Mesa 的 llvmpipe，也就是在 CPU 上執行 OpenGL，並關閉了 GPU 合成。頁面畫出的像素是對的，但地圖、canvas 圖表、3D 檢視器和設計工具都慢得像在爬。

Bromure 5 如何加上 GPU

macOS 27 讓 app 可以用 VZCustomVirtioDeviceConfiguration 實作自己的 Virtio 裝置。 Bromure 5 用它呈現一個標準的 Virtio GPU（裝置類型 16），所以客體不需要自訂的核心驅動 程式。它使用 Ubuntu 24.04 和原版的 virtio_gpu 核心模組；相容的瀏覽器映像檔也包含 固定版本並打過修補的使用者空間 Mesa，以及瀏覽器的視訊整合。

一個 WebGL 影格現在走這條路徑：

  1. Chromium 透過 ANGLE 畫到 Mesa 的 VirGL 驅動程式上。
  2. VirGL 透過 Virtio GPU 佇列送出 OpenGL 指令。
  3. Mac 上的一個渲染器工作程序透過 ANGLE 在 Metal 上重播這些指令。
  4. 瀏覽器視窗以 IOSurface 的形式顯示完成的影格。
  • 每台 VM 一個渲染器。 每台瀏覽器 VM 都有自己的沙箱化渲染器程序。在測試中， 兩個工作程序重複使用了相同的識別碼，仍各自保有獨立的表面，而且第一個關閉後，第二個 仍持續執行。
  • 原生游標。 macOS 用客體送來的游標影像來畫指標。
  • 硬體 H.264。 Bromure 把客體的視訊解碼器橋接到 VideoToolbox。Chromium 仍以軟體 解碼 AV1。
  • 只有圖形。 這個裝置負責渲染和視訊解碼，不提供一般用途的 GPU 運算，所以 VM 裡的 程式碼無法在你的 GPU 上執行機器學習工作負載。

數字

我們在一台 Mac 上用三種方式執行同一個 WebGL 工作負載：在 Bromure VM 中搭配新渲染器的 Chrome、在同一台 VM 中使用 Apple 圖形裝置（因此走 llvmpipe）的 Chrome，以及 macOS 上的 Chrome。

工作負載Bromure VM，Metal 渲染器同一台 VM，Apple VZ 圖形（軟體）macOS 上的原生 Chrome
2,048 次繪製，64 × 6420.8 ms169.5 ms12.9 ms
64 次繪製，1,280 × 720，32 次著色器迭代32.2 ms965.2 ms22.8 ms
24 次繪製，1,920 × 1,080，128 次著色器迭代68.2 ms3,555.1 ms63.9 ms

每個數字都是五次試驗的中位數，單位是完成一批 GPU 工作所花的實際經過時間。越低越好。

長條圖，比較三種工作負載下 WebGL 批次時間的中位數：Apple VZ 搭配 llvmpipe、Bromure 搭配 VirGL 與 Metal，以及 macOS 上搭配 Metal 的原生 Chrome
各工作負載的批次時間中位數，採對數刻度。灰色：使用 llvmpipe 軟體光柵化器的 VM。紫色：同一台 VM 搭配 Bromure 的 Metal 渲染器。藍色：macOS 上搭配 Metal 的原生 Chrome。誤差線標出五次試驗中最快與最慢的一次。

與軟體渲染相比，新路徑快了 8.1x、30.0x 和 52.1x，而且像素工作越多，差距越大。與原生 Chrome 相比，VM 所花的時間是 1.61x、1.41x 和 1.07x。大量的小型繪製呼叫代價最高，而在 最重的著色器上，VM 與原生的差距在 7% 以內。

測試環境：Bromure 5.0.1，在一台有 18 個 CPU 核心和 64 GB 記憶體的 Apple M5 Pro 上， 執行 macOS 27.0.1。VM 執行 Ubuntu 24.04 ARM64，搭配 Mesa 25.2.8、9 個 vCPU 和 4 GB。 三條路徑都使用 Chrome 154.0.8037.57。每個樣本都先暖機，最後以一次單像素回讀強制 GPU 完成工作，所以時間涵蓋瀏覽器、驅動程式和回讀，不包含著色器編譯。

同一段全螢幕 1080p 影片在兩個 Bromure Web 視窗中播放，用手機拍攝。右邊是以軟體繪製的 Bromure 4。左邊是搭配 Metal 渲染器的 Bromure 5。鏡頭在兩個螢幕之間移動。

把影格送上螢幕

在 flush 時發布。 Virtio GPU 客體會先指定掃描輸出資源，等內容準備好後再 flush。我們 的第一個版本在指定掃描輸出時就發布，可能會顯示一個只畫了一半的表面。Bromure 現在在 flush 時才更新視窗。

調整大小時有上限的保留。 換到新尺寸時，在頁面重新繪製之前，第一個影格常常近乎全黑或 充滿破洞。在調整大小期間，只要新影格看起來還沒畫好，Bromure 就會在有限的時間內把上一個 已畫好的影格留在螢幕上，而主機和客體會一起控制調整大小的節奏。這項檢查寧可多保留一些， 所以深色頁面在調整大小時可能會短暫延遲。不在調整大小時，影格會立即顯示。

在一次有追蹤紀錄的執行中，用了四台 VM、24 個分頁、造訪 40 個網站，四段 200 秒的錄製中 沒有出現近乎全黑的影格。

游標 alpha。 Linux 以沒有 alpha 通道的格式配置游標影像，然後把那塊記憶體當成帶 alpha 的游標使用。渲染器保留客體寫入的 alpha 值，所以游標保持透明。

背壓。 客體送出 3D 指令的速度可能比主機重播的速度快。Bromure 把每次送出的上限設為 1 MiB，並重複使用同一個 Metal 指令佇列來擷取影格。

它是怎麼做出來的

整個實作由 Astra 6.1 完成，它以兩個代理程式的形式在 Bromure 中執行：一個在 Mac 上，一個 在 Linux 中。我們訂定需求並測試結果。

  • macOS 代理程式打造了渲染器、Virtio 裝置，以及呈現與輸入。
  • Linux 代理程式打造了 Mesa 和 VirGL 的封裝、先決條件檢查，以及 VM 裡的指標代理程式 和調整大小監看程式。
  • 獨立的回歸測試與原始碼審查在過程中檢查了這些工作。

兩個代理程式都在同一個共用的功能分支上工作。它們透過 Bromure 的代理程式訊息功能，在兩個 環境之間交換訊息、附件、請求和測試證據。主機負責轉送、篩檢並記錄訊息，並在機器之間複製 附加的檔案。即將推出的 Bromure Sidecar app 是這項更大工作的一部分；等它推出時我們會再 介紹。

開啟與關閉

在 Bromure 5 中，Metal 渲染器位於每個 Bromure Web 設定檔的效能底下。它預設為開啟， 現有的設定檔也一樣。

  • 它需要 macOS 27。在 macOS 26 及更早版本上，Bromure 繼續以軟體渲染。
  • 全域設定仍然是總開關，變更會套用到新視窗。
  • 關閉它的設定檔會有自己的 VM，走舊的圖形路徑。
  • VM 映像檔需要一個標記，表示我們已驗證它可用於新渲染器。沒有這個標記，Bromure 會退回 軟體渲染。

我們在 macOS 27 上驗證了舊的圖形路徑，也在一台執行 macOS 26 的 Mac 上測試過。新的程式碼 需要 macOS 27 或更新版本。