Can you please demonstrate the issue with a fiddle? You can use the following one that holds the code of webgpu_lightprobe but with your modification. The only bit I have changed is to create the mesh for the second render just once.

https://jsfiddle.net/j8qk0us5/1/

Both backends render the same for me, tested on latest Chrome on macOS 15.3.1.

Oh that is strange, I can't reproduce it on Linux with AMD integrated graphics, or macOS.

Here's the fiddle: https://jsfiddle.net/zonkypop/jyuchq4p/2/

But it does look mangled with an RTX 3090 on Linux on Chrome (tested 131, 133). It needs: antialias: true for it to happen, and looks fine without antialiasing.

It looks fine on Firefox with the same machine.

I'll have a poke around today and see if I can find any clues.

I'm able to reproduce it in on Windows 11 with a RTX 3070 as well, but only Chrome, not Firefox. So might be Chrome+Nvidia related.

So the combination is WebGLBackend + MSAA + Nvidia card + Chrome, right? The OS does not seem to matter.

So the combination is WebGLBackend + MSAA + Nvidia card + Chrome, right? The OS does not seem to matter.

Yes seems to be, the bug's there for Linux and Windows

A workaround is adding useFrameBufferTarget to:

render( scene, camera, useFrameBufferTarget ) {

		if ( this._initialized === false ) {

			console.warn( 'THREE.Renderer: .render() called before the backend is initialized. Try using .renderAsync() instead.' );

			return this.renderAsync( scene, camera, useFrameBufferTarget );

		}

		this._renderScene( scene, camera, useFrameBufferTarget );

	}

and calling: renderer.render( scene, camera, false )

To disable the final quad pass, which fixes the issue. This introduces other problems like needing color conversion in the shader and no post processing though.

Can you please share a GPU report from one of the affected systems by typing chrome://gpu/ into the address bar and then hit Download Report to File?

Can you also test if this example works on the affected devices?

https://threejs.org/examples/webgl_multisampled_renderbuffers

Here's the report for the Linux machine:

about-gpu-2025-02-23T22-36-39-962Z.txt

https://threejs.org/examples/webgl_multisampled_renderbuffers seems to look fine

Can you try one thing and remove the following invalidate* calls from below section?

Can you try one thing and remove the following invalidate* calls from below section?

🥳 Wahay, that seems to have fixed it for both Linux and Windows!

I've remembered that the invalidate*() commands are problematic on certain devices. Hence, they are only done for Quest devices in WebGLRenderer.

Out of curiosity: Does the following WebGL conformance test pass on your affected devices?

https://registry.khronos.org/webgl/sdk/tests/conformance2/renderbuffers/invalidate-framebuffer.html?webglVersion=2&quiet=0&quick=1

All the tests are passing: TEST COMPLETE: 41 PASS, 0 FAIL

I've remembered that the invalidate*() commands are problematic on certain devices. Hence, they are only done for Quest devices in WebGLRenderer.

Ah that is interesting, hmm I can do a bit of testing on the Quest 3 to see the perf difference of removing/adding the gl.invalidateSubFramebuffer. I was wondering if the quad pass has much overhead? The Quest 3 seems to working fine with the new WebGLBackend / TSL though!

We need #30437 to restore foveation which does currently not work with the new renderer. That should further improve the performance on Quest devices.

Um, it would be good if the WebGL conformance test could actually catch the issue on your devices. If you could manage to reproduce the breakage by modifying the test and commiting the change that could be an welcome contribution to the WebGL conformance test suite.