WebGPURenderer: Reduce overhead from excessive cache sharing for postprocessing nodes.

[aardgoose]

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.

[github-actions]

📦 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

[RenaudRohlinger]

A lot of exciting performance improvements with #29197 and #29183. Nice!

[Mugen87]

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.

[RenaudRohlinger]

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

[sunag]

I also think the cache management should take care of this.