WebGPURenderer: Increase performance

[sunag]

Description

I started a work to increase the performance in WebGPURenderer and it will work for both Backends, it's about a better management of Bindings and Cache.

Solution

• Check Material Cache Key only after the version difference -- material.needsUpdate=true -- Reuse NodeBuilder #26729
• Reuse NodeBuilder based from Cache Key, currently the cache uses Material/Geometry as reference. For example, this means that two Materials of the same type with only a different color will be compiled twice instead of reuse the NodeBuilder, this sharing already happens for the GPU Program, but as the code is dynamically generated this optimization process should be API oriented for the Nodes. -- Reuse NodeBuilder #26729
  • Create a NodeBuilderState to reduce memory usage when reuse NodeBuilder -- Reuse NodeBuilder #26729
• Separate bindings groups for FRAME, RENDER, OBJECT groups. Node System already offers this support, we would have to take it to the level of optimization for the Bindings.
• Node System allows Auto-Instancing with a certain flexibility, this has already been adopted in other engines like Unreal and we may be implementing it soon as well. -- Renderer: Auto-Instancing [WIP] #26640

[danrossi]

I was about to comment. I just made new builds to figure out the iife bundle issue. And super low resources with video textures.

https://danrossi.github.io/three-webgpu-renderer/tests/webgpu_video_panorama_equirectangular.html

and using video frame callback

https://danrossi.github.io/three-webgpu-renderer/tests/webgpu_video_panorama_equirectangular_30fps.html

[PhilCrowther]

There is apparently still an issue with WebGPUrenderer and shadows. On a program with a single DirectionalLight that has shadow definitions, and that uses non-emissive materials (e.g. Lambert and Phong), switching to WebGPUrenderer will cause a massive slowdown. Oddly, if I remove the light, WebGPUrender will cause all the materials to become emissive - with the result that shadows are no longer an issue and the program operates at normal speed. (This has nothing to do with the use of NodeMaterials as I first thought since the same thing happens with regular Materials.) If it helps, I also had to add a bias definition to fix the appearance of some materials.

[sunag]

@PhilCrowther Could it be related to this ?

[PhilCrowther]

@sunag Not sure. I have created a small demo on CodePen.
To show the difference in performance and results, disable the DirectionalLight (line 82: scene.add(DirLight);).
But, let me know if this is just a matter of adding a few lines to my program.

[sunag]

Hmm... thanks for the example. It looks like there is a conflict in frameId.
Try to remove any requestAnimationFrame(rendAll); and add a single renderer.setAnimationLoop(rendAll);

Related: #24755

Anyway, I'll be checking for a fix for this.

[PhilCrowther]

Yes, that appears to have fixed the problems I was having with various versions of the program. I had to disable a smoke emitter, but I plan to update that anyways using the WebGPU Particles example. Thanks for the quick response!

[greggman]

I don't know if any of this is useful to three.js but this article has some ideas for WebGPU performance.

There are also some hopefully equivalent WebGL examples linked at the bottom of this page for comparison

Certainly, WebGPU implementaitions should find ways to increase perf more but at a glance it seems like it should be possible to go as fast or faster then WebGL.