WebGPURenderer: Material initialization is extremely slow compared to WebGLRenderer

[gkjohnson]

Description

Related to #33797

For the three-edge-projection I'm running a visibility culling pass to filter meshes that aren't visible. This means rendering every object with a unique id - with a CAD model this can be tens of thousands of meshes. I'm seeing that generally WebGLRenderer is significantly faster than WebGPURenderer for this initial render. As a result I'm having to use a WebGL context to perform the visibility culling while using a WebGPU context to do the actual edge projection.

I'm trying two different methods to render the Ids:

Method 1

Add every mesh to a scene with a dedicated material with "id" uniform and render everything together. I've created sample fiddles showing a basic representation with 10,000 meshes:

	WebGPURenderer	WebGLRenderer
fiddle	https://jsfiddle.net/bLsjfy8c/	https://jsfiddle.net/w1kmp5h4/2/
timing	~2100ms	~131ms

So here WebGPURenderer is ~16x slower to initialize and render the ids.

Method 2

Render each mesh individually and reuse a single material and modify the id uniform in place.

	WebGPURenderer	WebGLRenderer
fiddle	https://jsfiddle.net/pzcsu6jt/1/	https://jsfiddle.net/e0s7rzkq/1/
timing	~1029ms	~28ms

And here WebGPURenderer is ~36x slower to initialize and render the ids.

--

I'm not fully clear on how the internals of the node material building works but given how the materials are structured it seems like it's necessary to rebuild / analyze the full shader graph for every material given how uniform nodes are embedded in the node graph. I'm wondering if architecturally there would be value in decoupling the uniform values from the actual node graph with uniform "slots" used to define the shader?

In my mind, once the node graph is used to define a shader it should be able to reused independently of what uniforms are being defined by the user. There's be a lot to consider for a change like this but at a high level something like this comes to mind:

// define the node graph with *named* uniforms
const shader = new MeshBasicNodeShader();
shader.colorNode = uniform( 'vec4', '_id' );

// create a material constructor that references that
const IDMaterial = Material.fromShader( shader );

for ( let i = 0; i < 10000; i ++ ) {

  // named uniforms are exposed for easy modification, no need to re-traverse the node graph
  const material = new IDMaterial();
  material.uniforms._id = i;
  const mesh = new Mesh( geometry );

}

Reproduction steps

1. Render custom materials in WebGPURenderer and WebGLRenderer
2. See that WebGPURenderer is slower

Code

See fiddles

Live example

See main description

Screenshots

No response

Version

dev

Device

Macbook Pro M1 Pro
Windows 10 Intel i7-7700K, NVidia RTX 2070 Super

Browser

Chrome, Safari, Firefox (OSX)
Chrome (Windows)

OS

Tahoe 26.5
Windows 10

[mrdoob]

Device

No response

Browser

No response

OS

No response

Would be nice to know these.

[gkjohnson]

Would be nice to know these.

I've updated the details but the orders of magnitude for the timings are roughly the same on every platform I've tested on. I don't expect this is device-specific. The numbers I've provided are from the Macbook Pro.

[mrdoob]

Okay, thanks for the test links! 🙏

[Mugen87]

material.colorNode = TSL.uniform( new THREE.Vector4( i, 0, 0, 1 ) );

This line triggers as unique node builder state for each material because each node material has a unique node.

If you need per-mesh uniform color values, we currently recommend the pattern from webgpu_instance_uniform.

[Mugen87]

Here is the fiddle with the approach from the example: https://jsfiddle.net/3w4oxcat/

Performance-wise, it ends up in "Method 2" since it similar to directly updating the material.

[Mugen87]

@gkjohnson One issue is more of a usage problem. You must keep in mind WebGLRenderer performs inline sRGB decode while WebGPURenderer has a separate internal pass for that. If you render 10000 objects with separate render calls, you must disable color space output conversion so the plain renderer.render() call does not do it every time.

With color space conversion per render (~900ms): https://jsfiddle.net/rfgw9zxa/2/
Without color space conversion (~500ms): https://jsfiddle.net/rfgw9zxa/1/
Without color space conversion and WebGL backend (~80ms): https://jsfiddle.net/yk03rvfg/

Apart from that, I've investigated the both fiddles more deeply and also let AI analyse performance traces.

One major overhead comes from the UBO usage in WebGPURenderer which is explained in #30560.

In the meanwhile, I think that the pure UBO usage in WebGPURenderer does not work out. We probably have to refactor the uniform system and use UBOs only for shared uniform data like camera matrices. Object-level uniforms must be managed with the gl.uniform*() API and Immediates in WebGPU, see #33576. At least we should implement a PoC and compare the performance with the current solution.

Any form of auto-instancing or auto-batching won't solve the performance issue in your fiddle because you render only one object per render call.

There is also a larger per-object overhead management overhead in WebGPURenderer. We have started to improve performance in that area but there are still some open issues.

I'm also not sure yet why the difference between WebGPU and WebGL backend is that high (500ms vs 80ms). The many native device.queue.submit() calls seems to be very costly since they take ~70% of the execution time.

[gkjohnson]

Thanks - it sounds like there are two separate issues:

1. Node materials are very slow to build and three.js provides no way to reuse a node graph between material definitions.
2. WebGPURenderer is generally slower to render compared to WebGLRenderer even in an ideal setup.

I'll respond to both, starting with the second point:

WebGPURenderer.render is slower

It sounds like this is already fairly well-understood between the UBO usage issues & device.queue.submit and between three.js improvements and possible WebGPU implementation improvements as the browser-level we will see this improve.

To a few of the other points you mentioned: the fiddles are a fairly reductive representation of the issue that added some overhead, but even once addressing the problems the performance is more or less unusable for this kind of use case. In my real-world use the objects are being rendered to a render target so no color conversion is needed and matrix updates are disabled. And since there are ~48,000 meshes in my test model creating new Mesh instances is something I try to avoid due the sheer memory overhead associated. Some of the CAD models I've worked with in the past are hundreds of thousands of individual meshes so it's just not feasible to create new Meshes for one.

All to say this method of calling "render" per mesh is significantly more ergonomic in some cases compared to creating a scene with all the meshes. I don't expect it's reasonable to get to zero added overhead compared to rendering a full scene but as a user I'd expect this to be as-fast as WebGLRenderer (understanding these things are in progress).

Without color space conversion (~500ms): https://jsfiddle.net/rfgw9zxa/1/

Interestingly I see that Firefox takes less than half the time compared to Chrome (~200ms vs ~600ms). I'm wondering if the WebGPU implementation somehow has less overhead than Chromes?

NodeMaterial graph builds are slow

If you need per-mesh uniform color values, we currently recommend the pattern from webgpu_instance_uniform.

I understand this is an option (and I think it's great that it's possible) but I don't think it's a replacement for performantly being able to initialize multiple materials that are using the same node graph structure. It's useful to create multiple material instances and share them among objects and expecting users to basically start storing all of their uniforms per-object just to avoid the node-build step isn't reasonable.

Internally three.js is able to do this! If you create a bunch of MeshBasicNodeMaterials without custom nodes the performance is much faster, implying the build step isn't done per material in this case, even when a custom color is set per material (implying the same uniform across all material instances). So three.js can do this for it's materials but users have no way of writing a material that shares a graph in the same way.

This line triggers as unique node builder state for each material because each node material has a unique node.

This I understand but it's a design decision that three.js has made. I know you're aware but the graphics API level the defines uniform values and shader program separately. The fact that NodeMaterials require coupling what should be reusable uniform slots with the user-specified values is the problem, which is why I suggested an API that more closely mirrors the "shader program" and "uniform values" separation.

---

Coming up with a hacky solution for this - it would be possible to create a Proxy object that wraps the material to get similar functionality; effectively treating a "NodeMaterial" instance as a "shader": see fiddle here. This is an improvement over creating a modified MeshBasicNodeMaterial instance per mesh but it seems that there is still some introduced overhead from using the JS Proxy object. This is just a proof of concept, though, and I expect a version that could be built into three.js could do away with the proxy to keep the performance high.

Here's some timing with the different strategies on my machine based on the above fiddle.

material	timing
case 1: MeshNodeBasicMaterial per instance	~300ms
case 2: MeshNodeBasicMaterial per instance w/ uniform	~2000ms
case 3: Shared node graph w/ Proxy	~600ms

[Mugen87]

@greggman We are investigating performance issues with WebGPURenderer and have noticed something interesting in Chrome. Below fiddles render a single mesh 10000 times.

WebGPURenderer with WebGPU backend: https://jsfiddle.net/0p8xf1kd/
WebGPURenderer with WebGL backend: https://jsfiddle.net/6tya19x0/1/

The first thing you will notice is that the WebGL backend performs far better than WebGPU. On my M2 Pro with latest Chrome, it is ~500ms vs ~80ms.

In Firefox, the gap is much smaller. It's around ~180ms vs ~80ms. Safair shows a similar behavior as Chromee: ~450ms vs 80ms.

To sum up: In this specific test case, Chrome's WebGPU performs worse comparing to all three browsers. According to Chrome performance analysis, the by far most expensive API call is device.queue.submit() which takes almost 70% of the execution time. Is that something we should report at the Chromium bug tracker?

I'll attach a GPU report and a Performance Trace from Chrome.

about-gpu-2026-06-18T07-51-06-999Z.txt.zip
Trace-20260618T095407.json.gz

[greggman]

WebGPU is generally significantly faster then WebGL in nearly every case that I've tested. But, you have to use it the way modern GPU APIs require you to use them. Calling submit 10000 times is an anti-pattern. You should be aiming for as few calls to submit per frame as possible with as few command buffers as possible and as few render passes as possible.

If you file a bug, I think all you're going to be told is "don't do that". It'd be like comparing drawing 1000 triangles 1 at a time vs 1000 triangles all at the same time. The first is going to slow and the solution is to make it fast is not to optimize the 1 triangle per draw call path. It's to tell the user, stop trying to draw 1 triangle per draw call and instead draw them all in one call.

I've pointed this out before, but if you were to dig through the ANGLE code, it's effectively doing all the things you need to do if you want perf on a native API. I'm not saying you need to copy ANGLE. But, if you're going to try to use WebGPU with WebGL patterns then you're going to need to do all the of optimizing behind the scenes that ANGLE does, and that included coelesing draws into command buffers.

WebGL doesn't have a submit. But, ANGLE is having to call the native equivalent of submit on the native APIs. It holds this off for as along as it can. In your test case, ANGLE would likely only do one submit for your WebGL app. Each time you call gl.draw it's just adding more commands to a command buffer for the native API. WebGPU though is lower-level than WebGL so if you want to continue to pretend it's WebGL then you'll have to do your own coalescing of command buffers to lower the submit count.

My recommendation would be to stop trying to use WebGPU like it's WebGL and start trying to use it like it's WebGPU/D3D/Metal/Vulkan.

[greggman]

I don't know if this is helpful because I don't want you to draw the wrong conclusion, but, it's more of an example. Looking the calls in your sample, these are the calls for 1 renderer.render. In other words, these commands are executed 10000 times.

GPUCanvasContext.getCurrentTexture
GPUTexture.createView
GPUDevice.createCommandEncoder
GPUCommandEncoder.beginRenderPass
GPUQueue.writeBuffer
GPURenderPassEncoder.setPipeline
GPURenderPassEncoder.setBindGroup
GPURenderPassEncoder.setBindGroup
GPURenderPassEncoder.setIndexBuffer
GPURenderPassEncoder.setVertexBuffer
GPURenderPassEncoder.drawIndexed
GPURenderPassEncoder.end
GPUCommandEncoder.finish
GPUQueue.submit

If you were to go look at what ANGLE does on native APIS for the WebGL equivalent

// these four commands are implicit in the WebGL API. ANGLE, behind the scenes only needs
// to do them once for your example, not 10000 times
GPUCanvasContext.getCurrentTexture
GPUTexture.createView 
GPUDevice.createCommandEncoder
GPUCommandEncoder.beginRenderPass

// ANGLE virtualizes buffers so in WebGL you call `gl.createBuffer` but behind the scenes
// ANGLE may use multiple native GPU buffers. In particular, if the buffer is currently
// in use then when you call `gl.bufferData` or `gl.bufferSubData`, if it can see that
// the buffer is currently in use (which it is in your example after the first draw),
// then, it will allocate a new buffer, copy your new data it in, copy any other data
// from the old buffer. It does this because if it didn't it would have to block, waiting
// for the GPU to be done with the buffer (from the first of 10000 draw calls).
// WebGPU though is lower level, so it's up to you to do that yourself (or something else) (1)
GPUQueue.writeBuffer

// This is equivalent to `gl.useProgram` except, because ANGLE is manging the native commmand
// buffer it's building internally, it can ignore this after the first render. WebGPU on the
// other hand is more lower-level so it can't do that. It's not building the command buffers,
// you are. You submit, it has to execute. So it's up to you to coalesce that stuff.
GPURenderPassEncoder.setPipeline

// Similarly here, it's possible ANGLE can see these are the same resources, no need to
// re-add them to the native command buffer it's building internally. WebGPU though, you're
// building that buffer so its up to you not to repeat yourself.
GPURenderPassEncoder.setBindGroup
GPURenderPassEncoder.setBindGroup
GPURenderPassEncoder.setIndexBuffer
GPURenderPassEncoder.setVertexBuffer

GPURenderPassEncoder.drawIndexed

// Here, ending a render pass is implicit in WebGL so ANGLE will not have ended the pass yet.
GPURenderPassEncoder.end

// Similarly, ending the encoder is implicit in WebGL so ANGLE will not finish the command buffer.
GPUCommandEncoder.finish

// This is also implicit in WebGL so ANGLE will not submit. It submits when you exit the event
// loop or when you do something that requires it to submit (like use the WebGL canvas in canvas2d.drawImage)
GPUQueue.submit

Again, I'm not suggesting you do what ANGLE is doing. Rather, I'm pointing out, your example is not using the WebGPU API the way it was meant to be used and I'm pointing out the things ANGLE (or other browsers) have to do to get speed when you try to use a native GPU API but treat it as WebGL/OpenGL. This is exactly why Vulkan replaced OpenGL. Because all of the implicitness made things unpredictable. It was up to each implemenation how many tricks it would implement to try to get perf to be better, to try to submit as few command buffers as possible with as few passes as possible with as few stalls/barriers waiting for buffers/textures to be ready. Metal/Vulkan/D3D12/WebGPU though, remove all of those tricks and leave it to you.

(1) I also want to make it clear, I wasn't suggesting you virtualize your WebGPU buffers. Rather, because your example is calling renderer.render 10000 times on the same scene, it's using the same buffer for every iteration through the loop. In a normal WebGPU app, everything you want to draw would either have its own buffer(s) or or its own space in some larger shared buffer(s). So all the stuff ANGLE is doing behind the scenes to increase perf, when you're writing to and drawing from the same buffer 10000 times, is not something that would happen in a normal WebGPU program.

[gkjohnson]

Thanks @greggman -

It's worth noting that the WebGPURenderer.compute functions both also call "submit" every call, both of which can commonly be called dozens of times per frame. With the pathtracer I've noticed some delays especially on mobile when moving the camera and I'm wondering if calling "submit" so many times has something to do with it.

It's certainly less ergonomic but I'm wondering if something like allowing the user to optionally call WebGPURenderer.finish when their calls to "render" and "compute" are done would be a solution.

[greggman]

I though I'd post a couple of conversations about this with LLMs. Maybe they'll provide some ideas.

• Here's Gemini
• Here's Claude