WebGPURenderer: remove some debugging code

[aardgoose]

I think this can be safely removed, I have only see it trigger when working on a PR and breaking something.

[github-actions[bot]]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	692.21 171.45	692.21 171.45	+0 B +0 B
WebGPU	821.89 221.91	821.67 221.84	-219 B -72 B
WebGPU Nodes	821 221.7	820.79 221.63	-219 B -73 B

🌳 Bundle size after tree-shaking

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

	Before	After	Diff
WebGL	464.56 112.27	464.56 112.27	+0 B +0 B
WebGPU	542.09 146.75	541.87 146.68	-219 B -77 B
WebGPU Nodes	498.03 136.5	497.81 136.41	-219 B -88 B

[RenaudRohlinger]

I still have this issue when one of my app freezes (on resize event is triggered recreating multiples RTTs in runtime for example) while the bindGroup gets constantly recreated because of a binding issue similar to https://github.com/mrdoob/three.js/pull/29198#issuecomment-2457604202. I can fix it in my code but I believe that a potential solution might lie in improving the caching strategy for RTTs. Let's just keep this bit while #29198 is still unresolved. 🙏

[Mugen87]

@RenaudRohlinger With #29845 merged, is it now safe to merge this PR as well?

[RenaudRohlinger]

I can still reproduce the issue when the window is resized:

After examining the entire pipeline, I think it makes sense that this issue occurs. The WebGPURenderer lacks the safeguards present in the WebGLRenderer that prevent a texture reallocated at runtime from destroying a newly reallocated texture instead of the old one.

I'm referring to the deallocateTexture (and initTexture) function in the WebGLTextures class of the WebGLRenderer:

const webglTexture = webglTextures[ textureProperties.__cacheKey ];
webglTexture.usedTimes --;

// the WebGLTexture object is not used anymore, remove it

if ( webglTexture.usedTimes === 0 ) {

deleteTexture( texture );

}

// remove the weak map entry if no WebGLTexture uses the source anymore

if ( Object.keys( webglTextures ).length === 0 ) {

_sources.delete( source );

}

This code ensures that textures are only deleted when they are no longer in use by tracking the usedTimes property. It prevents the accidental deletion of textures that have been reallocated during runtime events like window resizing.

By adding a similar safeguard in the WebGPURenderer, we can probably prevent the GPU from deleting newly created textures that are still in use. Implementing reference counting and proper texture management, as done in the WebGLRenderer, should resolve the issue observed during window resizing. Also I'm not sure yet if this should be handled in the Textures Class or in each backend instead.

[RenaudRohlinger]

Which makes me think about this comment:

I also want to call it before display it the first time to init the renderTexture in the memory before drawing on it and avoid extra uploadtime, same for initTexture to avoid upload when it matters. https://github.com/mrdoob/three.js/issues/29898#issuecomment-2482611507

I don't think we really have yet a logic of ressource management with pre-allocation and dynamic re-allocation of the Textures. /cc @sunag

[sunag]

@RenaudRohlinger Maybe you have a small example so we can reproduce this issue?

[Makio64]

On a Dataviz project using a lot of RT and drawing into each others, I got the same Bindings._update: binding should be available on resize @RenaudRohlinger is mentioning.

I wanted to make a fiddle to reproduce it yesterday but currently the example is too simple and didnt trigger the issue.. Still it can be a good starting point to reproce the issue: https://jsfiddle.net/Makio64/3brnfyt7/

[ligaofeng0901]

I can fix it in my code but I believe that a potential solution might lie in improving the caching strategy for RTTs.

hello @RenaudRohlinger, Can you tell me how to avoid this issue in application code? I've met this warnings too many times in my app. some of them don't have any bad effect, others will make the context crash.

[Mugen87]

This code has been removed via #31497 so this PR can be closed.

An additional fix in r180 (#31755) has eventually fixed the root cause of the "Bindings._update: binding should be available" error.