mrdoob
WebGPURenderer: Reduce overhead from excessive cache sharing for postprocessing nodes.
Related issue: #27447
An alternative approach to reducing the overhead from the cache sharing that results from multiple renderTargets that mapping to a single internal RenderContext. This adds a unique id and a boolean property 'isolate' - default false, to RenderTarget().
These are used to control renderContext sharing as required in the post processing nodes: GaussianBlurNode, BloomNode, AfterImageNode and PMREMGenerator.
I think this is a cleaner mechanism than creating and managing additional QuadMesh objects.
For the PMREMGenerator this PR combined with #29197 prevents all per frame WebGPU object creation in the webgpu_cubemap_dynamic example.
📦 Bundle size
Full ESM build, minified and gzipped.
Filesize dev |
Filesize PR | Diff |
|---|---|---|
| 685.4 kB (169.7 kB) | 685.5 kB (169.7 kB) | +71 B |
🌳 Bundle size after tree-shaking
Minimal build including a renderer, camera, empty scene, and dependencies.
Filesize dev |
Filesize PR | Diff |
|---|---|---|
| 462 kB (111.4 kB) | 462 kB (111.5 kB) | +71 B |
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
A lot of exciting performance improvements with https://github.com/mrdoob/three.js/pull/29197 and https://github.com/mrdoob/three.js/pull/29183. Nice!
The current workaround of creating an instance of QuadMesh per render target isn't ideal as well as having a separate render target property. Both approaches are not intuitive and I fear developers won't get this right. I do think we need a solution that requires no additional work on app level.
Couldn't we enhance the renderer instead so a render object for each QuadMesh + render target combination is created instead? If that isn't doable, we should have something similar to simply avoid the creation of BindGroups and BindGroupLayouts. Maybe we can use an additional caching mechanism to save BindGroups and BindGroupLayouts and then reuse them.
I cannot agree more on this. Even yesterday I stumbled upon this issue when swapping between 2 RTT without carefully re-binding in a custom Postprocessing Node, infinite amount of bingGroup were stacking. It's very common if you're not careful with RenderTarget and Postprocessing setups. I also agree that the real solution would be to fix it on the caching strategy level. /cc @sunag
