Chrome writeBuffer Performance
-
A simple data performance test between
WebGL.bufferSubData
andWebGPU.writeBuffer
, try to simulate 1million transform matrix submit to GPU:
For my platform:
CPU: Intel i7 8700k
Mem: 16gb
GPU: Intel UHD 630
OS: Mac os 12.01
Chrome: 100.0.4862.3
Firefox: 99.0a1
for > 500k, take 1000k for heavy test
Chrome 100 FireFox 99 WebGL ~13 ms 26-30 ms writeBuffer 50~70 ms 26-30 ms mapAsync/unmap 40-50 ms 70-100 ms It is obviously that
writeBuffer
on Chrome is not ready for big dataset, basically 5-10x times slower thanbufferSubData
. WheremapAsync
slightly faster thanwriteBuffer
But for <150k,
writeBuffer
is fasterChrome 100 FireFox 99 WebGL 2 - 4 ms 5 - 6 ms writeBuffer 1 - 2 ms ~2 ms mapAsync/unmap 5 -10 ms 60 - 100 ms For small dataset, the
mapAsync
is slower …
When it comes to real application, WebGPU could get up to 20x slower then WebGL in Chrome, the device queue will be blocked while writing multi textrure/matrix/index/vertex ..
In our contrast test:
https://contrast.orillusion.comEvent though Orillusion gets much better overall FPS than Three instance draw, Orillusion actually takes 10x longer time than Three.js in sending data to gpu. When it comes to 300k boxes, Orillusion takes over 50-70ms on
writeBuffer
where Three only takes 3-4ms onbufferSubData
.This performance issue has been discussed for a long time, e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1266727&q=writeBuffer&can=2
But it is still not addressed up to Chrome Canary v101For now, the best practice in Chrome, try
mapAsync
if you are working on very big dataset, but may not get much helpful in real application. UsewriteBuffer
for simple relatively small data is always a good choice. But overall, they are not fast as WebGL so far
By the way, in our real practice,
mapAsync
may not a good choice for heavy rendering interactive Application.
The async callback/promise can be delayed from 4ms up to 20ms, such as mouse/keyboard/ajax/networking events, or othermapAsync
jobs.If you are working on a computing job, the delay is acceptable. But for real-time rendering, it can trigger a wired fps sometime, unstable frame change, hard to control from JS side.
mapAsync
vswriteBuffer
is likerelatively fast but unstable fps
vsrelatively slow but stable fps
.
Welcome anyone try the test, and post your result.
-
We also opened an issue on chromium official forum
https://bugs.chromium.org/p/chromium/issues/detail?id=1298309&q=writeBuffer&can=2
Welcome to submit your tests or ideas anytime to Chrome
-
For my platform:
CPU: 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz 2.30 GHz
GPU: Inter(R) UHD Graphics / NVIDIA GeForce RTX 3050 Ti Laptop GPU
Mem: 16gb
OS: Win11
Chrome: 98.0.4758.102(正式版本) (64位)Battery Only Charging WebGL 27~30 ms 14~20 ms writeBuffer 110~120 ms 49~53 ms mapAsync/unmap 80~100 ms 50~57 ms But only Inter(R) UHD Graphics works for the test, cannot change to RTX device
-
For my platform:
CPU: Intel i5 7200U
Mem: 8gb
GPU: Intel UHD 620
OS: Win10
Chrome: 100.0.4896.60(正式版本) (64 位)Chrome
WebGL 20~ 70ms
writeBuffer 120~130 ms
mapAsync/unmap 70~90 ms截图:
我的平台运行WebGL绘制速度不稳定,也可能是我的电脑配置低影响的,不过通过对比,WebGPU确实比GL慢许多,兴许底层优化不够好么? 看来WebGPU的性能值得优化提升!