WebGPURenderer: Per "texture set" bindGroup caching.

[aardgoose]

Related issue: #29198, #27447

Alternative mechanism to avoid excessive bindGroup creation. Use a cache keyed by a value derived from the texture(s) used in a bindGroup to handle the situation where a material alternates between two or more textures. This caching only takes place for bindGroups that would be updated after the first pass.

BindGroups referencing defaultTextures or external textures are not cached.

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	339.22 79.04	339.22 79.04	+0 B +0 B
WebGPU	476.9 132.19	477.18 132.3	+282 B +107 B
WebGPU Nodes	476.2 132.01	476.48 132.12	+282 B +108 B

🌳 Bundle size after tree-shaking

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

	Before	After	Diff
WebGL	464.67 111.99	464.67 111.99	+0 B +0 B
WebGPU	545.93 147.86	546.22 147.96	+282 B +107 B
WebGPU Nodes	501.81 137.56	502.1 137.67	+282 B +114 B

[Mugen87]

What is the purpose of * 10?

[RenaudRohlinger]

Maybe some hash test that could use the NodeUtils hashArray() or hash()?

[aardgoose]

?10 just to stop obvious collisions as a proof of concept. I am trying to avoid more string creation on a fairly hot path. A cheap hash would be better.

[RenaudRohlinger]

Nice! I thought about something similar but the issue with this it that it's stackingbindGroup, Texture Views and Samplers.
Every resize event of a RenderTarget will dispose the RenderTarget and destroy all the FBO samplers associated resulting with this new logic that creates a new bindGroup, Texture Views and Samplers that never gets cleanup. On dev the issue is not there as the bindGroups never gets recreated since their textures aren't associated to them.

To complete your approach, a cleanup strategy for unused bindGroups which dispose of the associated texture views and samplers would likely resolve this. textureView = null and sampler = null should be enough to allow garbage collection in WebGPU as it doesn't provides an explicit .destroy() method for cleanup.

[aardgoose]

Re garbage collection on resize. yes, it is an obvious issue. I just wanted to get a basic working approach to start with. After a bind group has been created, the only way to destroy it is to drop references to it AFAICS, so maybe we need a two part cacheId so that the version changes would cause a cached bindGroup to be overwritten? It is something I considered earlier.

[RenaudRohlinger]

This new two part cacheId is an awesome solution and fixes the issue. Great PR!

[Mugen87]

@aardgoose Is this PR ready for review?