sokol_gfx.h wgpu: fix up bindgroups cache when destroying associated resource objects #1097
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.
Fixes #1066: Whenever a sokol-gfx image, sampler, storage buffer or pipeline object is destroyed, the wgpu backend bindgroups cache will be scanned for entries which use that sokol-gfx resource. On a hit, the bindgroups cache item will be invalidated and the associated WebGPU BindGroups object released. The explicit calls to
wgpuTextureDestroy
andwgpuBufferDestroy
have been removed since WebGPU's internal garbage collection takes care of destroying any in-flight objects when it is safe to do so.A new entry has been added to
sg_frame_stats
which counts such bindgroups-cache slot invalidates, and sokol_gfx_imgui.h has been updated so that the new counter shows up in the debug UI.NOTE: even with the above changes, there's still the case where a sokol resource might be destroyed while its bind group is in flight. This is a tricky problem to solve - one solution would be a delayed-release-queue like in the Metal backend, but the 'inglight-pipeline depth' in WGPU is unpredictable (could use a very conservative value though).