WebGPURenderer: Fix texture view caching and dispose event stacking #30647
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related issue: #30560
Description
In the WebGPU backend before r172, there was a bug where
renderTarget.activeMipmapLevel
was incorrectly used instead ofrenderContext.activeMipmapLevel
. This was partially fixed in PR #30155:https://github.com/mrdoob/three.js/pull/30155/files#diff-dab3c57cef925d356099192da6cb6710336ac50052d2f6774897e1864d8c46a9L305-R331
However, my commit missed updating the cache invalidation condition:
renderTargetData.activeMipmapLevel !== renderTarget.activeMipmapLevel
renderTargetData.activeMipmapLevel !== renderContext.activeMipmapLevel
This oversight exposed two critical memory leaks:
The dispose event listener was being added repeatedly without proper cleanup, as cache invalidation was triggered incorrectly.
The caching strategy for texture views in
_getRenderPassDescriptor
was inefficient. It should separate the caching into two steps:Additionally, texture views in the
clear()
method were never cached at all, resulting in new views being created for every clear operation, accumulating indefinitely.I investigated this issue following memory leaks on a Windows project that ultimately crashed the GPU after running for a few hours. This suggests different platforms may handle GPU resource accumulation and cleanup differently, with Windows potentially being less forgiving.
Before this PR: Texture views infinitely accumulating, consuming GPU memory that may not be promptly released even after JavaScript references are no longer used.

(But you can test any WebGPU example and will see the texture views accumulating and
onDispose
event stacking.)After (Texture Views reduced and cached to 79):

This contribution is funded by Utsubo