大家好,本文對WebGPU進行效能測試和分析,目的是為了對比WebGL和WebGPU在“渲染”和“計算”兩個維度的效能差異,具體表現為CPU效能和FPS效能兩個方面的效能資料差異。
我們會分別在蘋果筆記本和配備RTX顯示卡的桌上型電腦上,對WebGL和WebGPU分別進行效能測試。
本文對於WebGPU使用了“reuse render command buffer”和“dynamic uniform buffer offset”兩種優化,相關介紹可以參考WebGPU學習(十一):學習兩個優化:“reuse render command buffer”和“dynamic uniform buffer offset”。
本文只使用了WebGPU的基礎能力,還沒有使用更高階的特性(如draw indirect、多執行緒渲染等),所以理論上WebGPU相比WebGL的效能優勢還可以進一步地擴大。
測試的程式碼
測試的程式碼在Github上
測試結論
這裡先給出最後的測試結論:
- 在“渲染”效能上,WebGPU比WebGL快3倍以上
- 在“計算”效能上,WebGPU比WebGL快50倍以上
測試環境
裝置一:13“MacBook M1 Pro
作業系統:Mac OS Big Sur
裝置二:配備RTX顯示卡的桌上型電腦(i7-4790+ RTX 2060 Super)
作業系統:Win10 64位
WebGL執行的瀏覽器:Chrome(版本 91.0.4472.114(正式版本))
WebGPU執行的瀏覽器:Chrome Canary(v93.0)
測試“渲染”的效能
場景描述
該場景的設計思路為:
在固定解析度的螢幕當中,用WebGL和WebGPU去渲染相同個數的固定大小的三角形,三角形個數從小到大進行遞增,三角形顏色都為隨機的灰度顏色;
每一幀提交對應三角形個數的DrawCall進行重繪(一個三角形對應一次DrawCall)(這裡的每個三角形可看為場景中的一個物體。實際場景中的物體通常由幾百上千個三角形組成,但是此處為了簡化和突出效能測試的重點,所以一個物體只由一個三角形組成)。
為了能更好的體現重繪的效果,我們在距離+Z軸方向(指向螢幕的方向)的最近的1000個三角形中,隨機選取了100個,進行Z軸方向的移動,表現效果為三角形的閃爍。這也符合實際的渲染場景中的情況:大部分物體並不是在每一幀都進行資料改變,只有部分會發生資料變化(這個場景中體現為三角形在Z軸方向的位置移動)。
具體的場景效果如下圖:
結果分析
1)硬體環境為13”MacBook M1:
- 影響CPU效能的因素: CPU傳遞DrawCall時間
- WebGL:5000個DrawCall命令以內時,CPU在10ms以內可以將其全部傳送給GPU進行繪製。可以看出CPU並沒有進行等待,原因是GPU在繪製5000個DrawCall命令以內時,完成速度很高,並不需要CPU等待。但是超過5000個DrawCall命令時,CPU的耗時明顯增加,而且成線性增長。原因是,在WebGL下,每一個DrawCall命令都必須由CPU傳遞給GPU進行繪製執行,一旦GPU繪製無法在相應時間內完成,就會要求CPU等待。GPU完成繪製所需時間越長,CPU等待時間就越長,所以造成超過5000個DrawCall命令時,CPU的耗時等待時間線性增加。
- WebGPU:在測試範圍內,CPU耗時幾乎保持不變。原因是WebGPU標準定義了繪製快取機制(GPURenderBundle),只需在初始化時提交一次進行快取,後面就不需要再由CPU傳送DrawCall繪製命令給GPU,而是GPU直接在快取中讀取繪製命令並進行繪製。因此可以看出WebGPU通過繪製快取機制,巨大地釋放了CPU執行緒的運算負擔,極大地提高了效能。
- 影響FPS效能的因素:CPU傳遞DrawCall時間+GPU時間
-
WebGL:5000個DrawCall命令以內,可以保持在60FPS的狀態。但是當DrawCall超過5000時,效能成反比例函式曲線下降。因為當CPU傳送DrawCall給GPU,時間成線性升高時,FPS的時間被此線性時間影響且成倒數關係。當超過一定的DrawCal數量時,甚至出現了測試崩潰(大於72000個DrawCall)。
-
WebGPU:由於快取機制,極大的減少了影響FPS最大的權重時間,即“CPU傳遞DrawCall時間”。因此可以在相對大量的DrawCall傳送測試下,保持在較高的60FPS狀態。但是當測試達到74000個DrawCall時,也會出現FPS下降,這是因為硬體的GPU已經無法滿足運算繪製的要求。
-
2)硬體環境為桌上型電腦i7-4790 + RTX 2060 Super
- 影響CPU效能的因素 CPU傳遞DrawCall時間
- WebGL:1000個DrawCall命令以內,CPU全部傳送給GPU進行繪製時,可以看出CPU並沒有進行等待,耗時都控制在10ms以內。然後超過1000個以後, CPU的耗時明顯增加,而且成線性增長。其整體趨勢和M1環境下對比分析相同。但是由於M1環境的CPU效能更好,所以M1在5000以後才表現出CPU耗時線性增加,而桌上型電腦在1000的時候已經開始表現出CPU耗時線性增加了。
- WebGPU:在測試範圍內,CPU耗時幾乎保持不變。原因與M1環境下的原因相同。因此無論是在M1環境還是在桌上型電腦環境,由於快取機制,可以看出WebGPU,都可以大量的釋放了CPU執行緒的運算負擔,進而提高效能。
- 影響FPS效能的因素:CPU傳遞DrawCall時間+GPU時間
- WebGL:30000個DrawCall命令以內,可以保持在60FPS的狀態,而M1只能在5000以內,才可以維持60FPS狀態,可以看出桌上型電腦的RTX顯示卡明顯好於M1的顯示卡。但是當DrawCall超過30000時,效能成反比例函式曲線下降。原因與M1環境下的原因相同
- WebGPU:其整體趨勢和M1環境下對比分析相同。當測試達到82000個DrawCall時,也會出現FPS下降,這是因為硬體的RTX顯示卡也已經無法滿足運算繪製的要求。
測試結論
在當前渲染場景的測試中得出如下結論:
- 由於WebGPU採用了快取機制,可以避免CPU傳送DrawCall指令所帶來的等待時間消耗,顯著提升CPU的工作效率。相比較WebGL,WebGPU在M1配置下渲染效能提升3倍,桌上型電腦i7-4790 + RTX 2060 Super配置下渲染效能提升15倍。
- 如果不使用WebGPU的快取機制,那麼WebGPU的渲染效能只比WebGL快3%左右,兩者相差不大。這是為什麼呢?這是因為對於WebGPU和WebGL,在GPU端都是通過光柵化管線來渲染,所以兩者在GPU時間上都是一樣的,不一樣的點就在於CPU傳遞DrawCall時間。然而如果WebGPU不使用快取機制,那麼WebGPU與WebGL一樣,每幀都需要在CPU端傳送每個DrawCall指令,所以導致兩者在CPU傳遞DrawCall時間上也幾乎一樣。
- CPU效能對比中,WebGL下,M1配置的CPU耗時引數優於桌上型電腦的CPU耗時引數,因此桌上型電腦CPU(i7-4790)效能表現不如M1晶片效能。但是在FPS效能對比中,WebGL下桌上型電腦的RTX顯示卡效能明顯優與M1晶片。但是不論硬體配置如何,CPU效能的表現和FPS效能的表現,在WebGL下和WebGPU下,整體變化趨勢一致。WebGPU效能整體明顯優與WebGL效能。
分析Babylonjs關於WebGPU和WebGL的渲染效能對比的Demo
從From WebGL to WebGPU: A perspective from Babylon js by David Catuhe視訊的12:51開始,演示了WebGPU和WebGL的渲染效能對比的Demo(WebGPU應該也採用了快取機制),下面我們來詳細分析下差異的原理:
如上圖所示,我們看到在當前場景中,兩者的FPS差不多,這是為什麼呢?
我們已經知道,影響FPS效能的因素為:CPU傳遞DrawCall時間+GPU時間
目前在螢幕上繪製的物體較少,所以DrawCall次數很少,所以CPU傳遞DrawCall時間很少;
所以一幀的時間主要花費在GPU時間上。然而對於WebGPU和WebGL,在GPU端都是通過光柵化管線來渲染,所以兩者在GPU時間上都是一樣的。
所以綜上所述,兩者的FPS應該是差不多的。
下面看另外的一個場景:
現在因為相機拉的非常遠,所以在螢幕上繪製的物體非常多,所以DrawCall次數很多,所以CPU傳遞DrawCall時間很大,所以使用快取機制的WebGPU的效能優勢就體現出來了。
WebGPU比WebGL快了3倍左右,這與我們的測試結果差不多。
測試“計算”的效能
場景描述
該場景的設計思路為:
在固定解析度的螢幕當中,用WebGL和WebGPU計算和渲染相同個數的固定大小三角形,三角形個數從小到大進行遞增;
所有的三角形首先通過計算演算法計算出每個三角形在場景中的位置,然後通過一次DrawCall(Instancing)渲染到螢幕中。
此演算法的思路是:每一個三角形的位置的獲得都需要遍歷場景中其他所有三角形的位置,最終演算法會收斂成為三角形群聚現象,模擬類似於鳥群的飛行狀態。這裡需要特殊說明,演算法本身只是為了體現測試場景的計算量,不同的演算法並不會對測試結果的整體趨勢產生任何影響。
具體的場景效果如下圖:
結果分析
1)硬體環境為13”MacBook M1:
- 影響CPU效能的因素:CPU計算時間(因為只有一次DrawCall,所以“CPU傳遞DrawCall時間”幾乎為0,故該項忽略不計)
- WebGL:物體數量低於500時,在計算每一個物體的位置和運動軌跡時,雖然需要遍歷其他所有三角形的狀態(測試演算法的效果),但是由於物體數量較少,CPU的計算任務仍然可以在16ms以內完成。但是超過500個物體後,CPU的耗時明顯增加。原因是,CPU的主要運算時間都在計算物體在下一時刻的位置,隨著物體數量的增加,需要遍歷的次數也隨之線性增加。
- WebGPU:在測試範圍內,CPU耗時幾乎為0。原因是WebGPU標準定義了計算著色器(Compute Shader),使得WebGPU可以將所有的計算任務全部交給GPU的Compute Shader來完成,而不需要CPU參與計算任務。因此可以看出WebGPU,在計算場景中,同樣釋放了CPU的運算負擔,極大得提高了效能。
- 影響FPS效能的因素:CPU計算時間 + GPU時間
- WebGL:物體數量低於500時,幾乎可以保持在60FPS的狀態。但是當物體數量超過500時,FPS表現迅速下降。因為CPU大量的時間都消耗在了計算每個物體的位置上,隨著物體數量的增加,需要遍歷的物體越多,因此計算耗時越多,幀率下降明顯。而且當超過一定物體數量時,由於計算量過大,出現了測試崩潰(大於3000個物體)。
- WebGPU:由於有了計算著色器(Compute Shader),所以所有的計算都交給了GPU去完成。由於GPU的Compute Shader具有平行計算的特徵,可以非常快地完成這種複雜的計算任務,因此FPS可以大部分時間都保持在60FPS的狀態。但是當測試達到15000個物體時,也達到了M1的GPU運算能力上限,因此也會出現FPS下降。
2)硬體環境為桌上型電腦i7-4790 + RTX 2060 Super:
- 影響CPU效能的因素:CPU計算時間(因為只有一次DrawCall,所以CPU傳遞DrawCall時間的幾乎為0,故該項忽略不計)
- WebGL:物體數量低於500時,由於物體數量較少,桌上型電腦CPU的計算任務和M1配置一樣,也可以在16ms以內完成。但是超過500個物體後,CPU的耗時明顯增加。原因與M1環境下的原因相同。
- WebGPU:其整體趨勢和M1環境下對比分析相同
- 影響FPS效能的因素:CPU時間 + GPU時間
- WebGL:物體數量低於500時,幾乎可以保持在60FPS的狀態。但是當物體數量超過500時,FPS表現迅速下降。原因同M1場景分析一致。計算量過大時,測試場景出現崩潰(大於3000個物體)。
- WebGPU:其整體趨勢和M1環境下對比分析相同。當測試達到35000個物體時, FPS開始下降,因為達到了RTX顯示卡的運算能力上限。
測試結論
在當前計算場景的測試中得出如下結論:
- WebGPU採用了計算著色器,可以直接呼叫GPU能力,通過平行計算完成複雜的計算場景。而WebGL只能把計算任務交給CPU來處理,效率較低。相比較WebGL,WebGPU在M1配置下計算效能提升50倍,桌上型電腦i7-4790 + RTX 2060 Super配置下,計算效能提升100倍。
- CPU效能對比中,WebGL下,M1配置的CPU耗時引數優與桌上型電腦的CPU耗時引數,因此桌上型電腦CPU(i7-4790)效能表現不如M1晶片效能。同樣在FPS效能對比中,WebGL下,桌上型電腦的計算還是體現在CPU方面,即使擁有RTX顯示卡也無法利用其計算能力。但是不論硬體配置如何,CPU效能的表現和FPS效能的表現,在WebGL下和WebGPU下,整體變化趨勢一致。WebGPU效能整體明顯優與WebGL效能。