WebGPURenderer: Optimize WebXR render path. #31134

cabanier · 2025-05-19T20:27:44Z

cc @Mugen87
This fixes some of the performance issues but since it reaches directly into the renderer, it seems brittle

github-actions · 2025-05-19T20:30:42Z

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	337.26 78.64	337.26 78.64	+0 B +0 B
WebGPU	550.64 152.68	551.75 152.93	+1.11 kB +245 B
WebGPU Nodes	549.99 152.53	551.1 152.77	+1.11 kB +245 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

	Before	After	Diff
WebGL	468.12 113.14	468.12 113.14	+0 B +0 B
WebGPU	625.95 169.45	627.06 169.69	+1.11 kB +238 B
WebGPU Nodes	580.8 158.77	581.91 159.01	+1.11 kB +243 B

cabanier · 2025-05-20T05:55:37Z

I traced the performance down to an issue in Quest browser. I'm investigating why I'm seeing this weird behavior.
I simplified the layers case to just the rollercoaster and am seeing these stage:

Surface 6 is the first render pass of the rollercoarst and 7 is the tone mapping
Surface 10 is the first pass of the eye buffer and 11 its tone mapping.

I don't know what is causing surface 4, 5, 8 and 9 to trigger but they're the root of the slow experience.

cabanier · 2025-05-21T22:04:05Z

@Mugen87 I was able to fix the slowdown. Setting the renderer size also changed the pixel backing store of the canvas and that made it very slow. I also added code to discard depth to gain some performance.

I also added a simple test file to validate webxr without using multiview. That path was broken.

cabanier · 2025-05-22T03:55:40Z

The windows failure also happens without my changes.See #31145

cabanier · 2025-05-22T04:04:27Z

src/renderers/common/Renderer.js

@@ -1250,6 +1252,7 @@ class Renderer {
 		frameBufferTarget.scissor.multiplyScalar( this._pixelRatio );
 		frameBufferTarget.scissorTest = this._scissorTest;
 		frameBufferTarget.multiview = outputRenderTarget !== null ? outputRenderTarget.multiview : false;
+		frameBufferTarget.resolveDepthBuffer = outputRenderTarget !== null ? outputRenderTarget.resolveDepthBuffer : true;


this indicates if we need to resolve the depth buffer. I think this needs to be updated for devices that prefer to get depth (ie AVP) but I have no way to test this.

What does AVP stand for?

Apple Vision Pro.
It works without a depth buffer but it has better reprojection if one is provided.

cabanier · 2025-05-22T04:05:22Z

src/renderers/common/Renderer.js

@@ -1380,7 +1383,7 @@ class Renderer {
 		renderContext.viewportValue.height >>= activeMipmapLevel;
 		renderContext.viewportValue.minDepth = minDepth;
 		renderContext.viewportValue.maxDepth = maxDepth;
-		renderContext.viewport = renderContext.viewportValue.equals( _screen ) === false;
+		renderContext.viewport = renderContext.viewportValue.equals( _screen ) === false || this._forceViewPort;


the viewport and screen are both set by setSize so we need to catch the instance we want them to be set explicitly.

Do you really need _forceViewPort? Since you are not changing the drawing buffer when resizing the renderer during XRManager.renderLayers(), the configured viewport (which uses the layer's width and height) should be different than the drawing buffer size and thus set RenderContext.viewport to true.

RenderContext.viewport only indicates the viewport update should use the value from the render context (and not the drawing buffer size).

drawingBufferSize is calculated as follows:
return target.set( this._width * this._pixelRatio, this._height * this._pixelRatio ).floor();

so it also uses width and height. Maybe this is wrong? I was worried to change that it's a big change.

The implementation of getDrawingBufferSize() is correct, imo. I had to read the code multiple times to understand why you need _forceViewPort.

I think you can remove it when the following lines:

three.js/src/renderers/webgl-fallback/WebGLBackend.js

Line 455 in 2d978cb

state.viewport( 0, 0, gl.drawingBufferWidth, gl.drawingBufferHeight );

three.js/src/renderers/webgl-fallback/WebGLBackend.js

Line 611 in 2d978cb

state.viewport( 0, 0, gl.drawingBufferWidth, gl.drawingBufferHeight );

are refactored to:

const { width, height } = this.getDrawingBufferSize( _drawingBufferSize ); state.viewport( 0, 0, width, height );

If you don't update the DOM element when setting the size for layers, gl.drawingBufferWidth and gl.drawingBufferHeight are incorrect. Using getDrawingBufferSize() should report the correct values.

src/renderers/common/Renderer.js

cabanier · 2025-05-22T04:06:29Z

src/renderers/common/XRManager.js

-				this._renderer.setOutputRenderTarget( layer.renderTarget );
-				this._renderer.setRenderTarget( null );
+
+				renderer.setOutputRenderTarget( layer.renderTarget );


cabanier · 2025-05-22T04:07:10Z

src/renderers/common/XRManager.js

+				const { frameBufferTarget, quad } = this._frameBufferTargets.get( layer.renderTarget ) || { frameBufferTarget: null, quad: null };
+				if ( ! frameBufferTarget ) {
+
+					renderer._quad = new QuadMesh( new NodeMaterial() );


needed because otherwise there's confusion with multiview vr regular rendering.

cabanier · 2025-05-22T04:07:53Z

src/renderers/common/XRManager.js

@@ -904,7 +935,8 @@ class XRManager extends EventDispatcher {
 				const projectionlayerInit = {
 					colorFormat: gl.RGBA8,
 					depthFormat: glDepthFormat,
-					scaleFactor: this._framebufferScaleFactor
+					scaleFactor: this._framebufferScaleFactor,
+					clearOnAccess: false


clearOnAccess gives a small benefit because it skips the step where browser explicitly clear the buffer upon framebuffer attach.

cabanier · 2025-05-22T04:08:59Z

src/renderers/webgl-fallback/WebGLBackend.js

+
+				const fb = renderTargetContextData.framebuffers[ renderContext.getCacheKey() ];
+				state.bindFramebuffer( gl.DRAW_FRAMEBUFFER, fb );
+				gl.invalidateFramebuffer( gl.DRAW_FRAMEBUFFER, renderTargetContextData.depthInvalidationArray );


this discards the depth buffer before we do the tonemapping steps. With this, the depth is flushed to main memory which adds overhead

src/renderers/common/Renderer.js

Mugen87 · 2025-05-22T09:25:34Z

src/renderers/common/XRManager.js

 		for ( const layer of this._layers ) {

 			layer.renderTarget.isXRRenderTarget = this._session !== null;
 			layer.renderTarget.hasExternalTextures = layer.renderTarget.isXRRenderTarget;
+			renderer.setSize( layer.renderTarget.width, layer.renderTarget.height, false, false );


I think you can move this line in the below if block. setSize() only matters if rendering into the default framebuffer. When rendering into a render target defined via setRenderTarget(), the dimensions from the render target are used.

I wonder if we should change the renderer so setOutputRenderTarget() behaves like setRenderTarget(). Meaning, when an output render target is defined, the dimensions of the internal framebuffer target is derived from it. Right now, we only do this for depth:

three.js/src/renderers/common/Renderer.js

Line 1246 in 2d978cb

frameBufferTarget.setSize( width, height, outputRenderTarget !== null ? outputRenderTarget.depth : 1 );

However, keeping the dimensions of the internal framebuffer target in sync with the output render target could simplify things by making certain setSize() calls obsolete.

We use setOutputRenderTarget() only in context of XR right now (to define a different output target than the default framebuffer) so if you think that design would be helpful we maybe can give it a shot.

I think you can move this line in the below if block.

done

I wonder if we should change the renderer so setOutputRenderTarget() behaves like setRenderTarget(). Meaning, when an output render target is defined, the dimensions of the internal framebuffer target is derived from it.

Maybe we can try that in a follow up PR? I'm a bit worried that some code might look at the renderer's size so if we don't update it, they might make the wrong decisions.

cabanier force-pushed the frameBufferTarget branch from 3e64d3c to 77adfd8 Compare May 21, 2025 21:28

optimize WebXR render path

5e9e053

cabanier force-pushed the frameBufferTarget branch from 77adfd8 to 5e9e053 Compare May 21, 2025 22:02

cabanier marked this pull request as ready for review May 22, 2025 03:54

cabanier commented May 22, 2025

View reviewed changes

src/renderers/common/Renderer.js Outdated Show resolved Hide resolved

cabanier commented May 22, 2025

View reviewed changes

cabanier mentioned this pull request May 22, 2025

test #31145

Closed

Mugen87 reviewed May 22, 2025

View reviewed changes

src/renderers/common/Renderer.js Outdated Show resolved Hide resolved

Mugen87 changed the title ~~optimize WebXR render path~~ WebGPURenderer: Optimize WebXR render path. May 22, 2025

Mugen87 reviewed May 22, 2025

View reviewed changes

address review comments

415bbef

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WebGPURenderer: Optimize WebXR render path. #31134

WebGPURenderer: Optimize WebXR render path. #31134

cabanier commented May 19, 2025 •

edited

Loading

github-actions bot commented May 19, 2025 •

edited

Loading

cabanier commented May 20, 2025

cabanier commented May 21, 2025 •

edited

Loading

cabanier commented May 22, 2025

cabanier May 22, 2025

Mugen87 May 22, 2025

cabanier May 22, 2025

cabanier May 22, 2025

Mugen87 May 22, 2025

cabanier May 22, 2025

Mugen87 May 22, 2025 •

edited

Loading

cabanier May 22, 2025

cabanier May 22, 2025

cabanier May 22, 2025

cabanier May 22, 2025

Mugen87 May 22, 2025

Mugen87 May 22, 2025 •

edited

Loading

cabanier May 22, 2025

cabanier May 22, 2025

WebGPURenderer: Optimize WebXR render path. #31134

Are you sure you want to change the base?

WebGPURenderer: Optimize WebXR render path. #31134

Conversation

cabanier commented May 19, 2025 • edited Loading

github-actions bot commented May 19, 2025 • edited Loading

📦 Bundle size

🌳 Bundle size after tree-shaking

cabanier commented May 20, 2025

cabanier commented May 21, 2025 • edited Loading

cabanier commented May 22, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mugen87 May 22, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mugen87 May 22, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cabanier commented May 19, 2025 •

edited

Loading

github-actions bot commented May 19, 2025 •

edited

Loading

cabanier commented May 21, 2025 •

edited

Loading

Mugen87 May 22, 2025 •

edited

Loading

Mugen87 May 22, 2025 •

edited

Loading