I’ve been using WebGPU and TSL for the current (commercial) project I’m currently working on.
From what I read WebGPU should outperform, or at least match WebGL performance, however from my initial benchmarking I’ve found that on the same scene I could get 2-4x more FPS with WebGL than WebGPU. I’ve also tried using WebGPURenderer and setting forceWebGL flag to true, which for some reason made the FPS 5-10x worse than just the WebGLRenderer.
The project will be quite big and heavy - using lot of custom shader and special effects, and I will need every bit of performance, especially for the mobile users. I would be quite sad to go back to writing GLSL, but seeing this I feel I don’t have any other options.
Is there reason why in this demo WebGPURenderer, and especially when forced to use WebGL fallback, is so much slower? (three.js r181)
The demo I’ve used is just spawning MeshBasicMaterial cubes in small area.
My benchmark result:
5k cubes:
WebGPURenderer with forceWebGL: true - 50 fps
WebGPU - 140 fps
WebGL - 350 fps
I think that WebGPU is possibly still experimental. I am basing this on the assumption that it’s not even enabled in all the browsers.
Furthermore, threes own WebGPU renderer may be in fact experimental as well. At least somewhat more experimental than the WebGL one, since that one has been used for almost 15 years or so?
A somewhat controversial example may be that even the WebGL renderer is not 100% stable, it to is modified every month and may introduce bugs that slow things down.
So, it could be khronos group and the browser vendors. Could be three itself, maybe the next version will be faster (bugs are constantly being fixed), it may also be you, are you sure that you are doing everything right.
The classic example of not doing things right is trying to draw two thousand meshes of a sphere. That is slow. When you use instancing, all of a sudden you can draw 2 million. Maybe there is something like this with webGPU.
Which particular WebGPU features are you using so that you can’t just use WebGL and keep it simple? I imagine it’s compute shaders, but this can kind of be emulated with webgl. I do feel your pain though lol, once you write wgsl or tsl it hurts going back to glsl.
To get a good comparison, you will probably have to do a little more programming to take full advantage of WebGPU features. One example is utilizing compute shaders, which are available in WebGPU, not WebGL. You should be able to use TSL to help with this process.
Although WebGPU has been around a long time, the implementation in three.js is still in development and, now that they have added most of the basic features, their current emphasis is on increasing performance.
So, as you learn more about the features and as the implementation of WebGPU improves, you should see better numbers from WebGPU.
There is an distinct performance issue in WebGPURenderer which affects applications with many draw calls.
The workaround right now is to use instancing and batching whenever possible. We are still trying to find ways to improve the performance without giving up the usage of UBOs for object-scope uniforms. UBOs are in general a neat feature but organizing them on object level turned out to be a challenging task.