WebGPU Node system extremely slow startup about three.js HOT 15 OPEN

@sunag Any way to reopen this issue?

Yes, I think it's worth analyzing all these points first.

from three.js.

Please test using the JavaScript, it will better represent the result.

Just remove any call to render(), and add just one call to measure the rendering time, consider that during this time the compilation of the shader will not be the only thing to be executed, but the creation of textures, geometry, etc… Even so, the result is very different from what is presented above.

const now = performance.now();

renderer.render( scene, camera );

console.log( performance.now() - now );

This cost me around ~0.15 milliseconds in my M1 computer, much lower than 16.66 (1000/60) which represent 60 FPS.

The second frame now - performance.now() returned 0 because the value was too small, since everything was initialized.

from three.js.

On my side, the screen stays black for about 2 seconds before displaying the first frame which is not the case when using webgl or even babylon webgpu. I have a solid pc with a nvidia 3090 and the I am having the exact same issue on my macbook (actually worse..).

The performance issue is happening inside the WGSLNodeBuilder when the materials are being created. I do not believe that this is related to webgpu api as I do not have such issue with babylon nor emscripten.

As for the benchmark, the load is spread out across multiple frames so it's easier to visualize in the profiler, here is a zoomed out version of the profiler on one of the material during startup (when the page is loaded or material created for the first time):

As you can see most of the compute is going toward this traverse method in the core/Node.js

	traverse( callback, replaceNode = null ) {

		callback( this, replaceNode );

		for ( const { childNode, replaceNode } of this.getChildren() ) {

			childNode.traverse( callback, replaceNode );

		}

	}

As for JS benchmark in the console sure:

4.399999976158142
0.4000000059604645
0.5999999940395355
0.5
0.4000000059604645
0.5999999940395355
0.5
0.4000000059604645
0.5
0.800000011920929
0.5
0.5999999940395355
0.5
0.6000000238418579
0.5999999940395355
0.5
0.5999999940395355
0.5
0.5999999940395355
0.5
0.7000000178813934
0.5999999940395355
0.5

from three.js.

If we can replace these VarNode.assign with stack.assign is better, it follows flow, and there is no need to traverse.

from three.js.

Maybe the shader compiler on Windows is super slow compared to the one in MacOS?

from three.js.

I had ~0.6 on my laptop with Windows and Ryzen 7 processor, less than 1 ms to render/compile the first frame.

from three.js.

In any case, there is a strange behavior, as the frame is taking a long time to appear. I will analyze this more carefully.

from three.js.

@sunag Any way to reopen this issue?

from three.js.

/ping @LeviPesin about Node.traverse()

from three.js.

What is suspicious is that these slow traverses all happen in VarNode.assign(). I think what we should do is fix it so that it works in runtime instead of compile-time (as I suggested in #26795 (comment), for a completely different reason). We can also remove replaceNode then.

I can file a PR for that.

The exact reason for the slowness is maybe that these VarNodes have a tremendous amount of subnodes -- and VarNode.assign() must (in the current implementation) check them all.

from three.js.