WebGPURenderer Performance Significantly Lower Than WebGLRenderer

[tenkkov]

Description

Summary

When switching from WebGLRenderer to WebGPURenderer, I experience a significant drop in performance. The same scene, containing thousands of non-instanced meshes, runs smoothly at 60 FPS on WebGL but drops to 15 FPS on WebGPU, a 4x decrease in performance.

Expected Behavior

WebGPURenderer should provide comparable or better performance than WebGLRenderer, given its modern API and intended improvements over WebGL.

Current Behavior

Rendering 20,000 non-instanced basic cube meshes:

WebGLRenderer: ~60 FPS on Mac (Apple Silicon M1 Pro)

WebGPURenderer: ~15 FPS (4x slower)

No errors or warnings appear in the Chrome console.

Reproduction steps

1. Create a Three.js scene with 20,000 Mesh instances.
2. Use WebGLRenderer and observe smooth 60 FPS performance.
3. Switch to WebGPURenderer by uncommenting the renderer swap.
4. Observe FPS dropping significantly (down to 15 FPS).

Code

see live example below

Live example

https://jsfiddle.net/15zfestk/1/

Screenshots

No response

Version

r.0.173.0

Device

Desktop

Browser

Chrome

OS

MacOS

[Mugen87]

Some more context: https://discourse.threejs.org/t/why-webgpurenderer-performance-significantly-lower-than-webglrenderer/77629/9

[Mugen87]

The live example uses more or less the worst case setup for the renderer. Many objects which update their transformation every frame. Since the example uses no instancing or batching, existing performance issues in WebGPURenderer are exhibited.

Because every object has its own UBO for managing their object scope uniforms, each frame all UBOs must be bound and updated which seems to cause a considerable amount of overhead. The WebGL backend spends most time for the bindBufferBase(), bindBuffer() and bufferData() calls.

[Mugen87]

To further explain the major performance gap: This is how WebGLRenderer renders the scene when four cubes are configured:

There are no major state changes between the draw calls (except for some single uniform updates which are not displayed in the list). Compared to that, WebGPURenderer does the following:

As you can see, there is a considerable amount of state changes between each drawElements() command. Many scenes won't have an issue with this because the number of render objects is low. But the more render objects you have in a scene, the sooner WebGPURenderer gets CPU limited.

#30562 fixes the VAO related issues but they are unfortunately negligible compared to the UBO related overhead. I guess we need a different approach in the renderer to minimize these state changes.

@sunag @RenaudRohlinger @aardgoose Would be a single UBO for all object scope uniforms a potential solution?

[RenaudRohlinger]

Nice catch with the VAO!

Related (I like the CommonUniformBuffer interface):
#27388

Unless we implement a pool system I don't think we can use a single UBO for all object-scope uniforms as a potential solution since we'd be very limited by the number of meshes. With a typical 16KB max block size and each mat4 taking 64 bytes in std140, that limits us to about 256 meshes.

[Mugen87]

Good to know that. I hope we can revisit #27388 soon.

[CodyJasonBennett]

With a typical 16KB max block size

This is the limitation per draw call as guaranteed by the WebGL 2 specification. You can have a larger buffer bound and adjust the offset dynamically. I've shared many words of this and scheduling in general, but I'm not sure they've been heard, reading this.

[aardgoose]

Can this issue be clarified, is it performance with the webGL fallback backend that the OP has an issue with or the WebGPU backend or both?

Re #27388, I'll revisit it in a few weeks time, I recall looking at applying a similar mechanism to the WebGL fallback, but found that more complicated because of the different api styles rather than a buffer size issue, although I'd have to check.

[Mugen87]

Can this issue be clarified, is it performance with the webGL fallback backend that the OP has an issue with or the WebGPU backend or both?

Both backends have the performance issue.