Question
Does GPUBuffer.destroy() guarantee immediate resource reclamation across browser vendors?
Ira Moss
0 reputation · 23 Oct 2022, 21:59 UTC
87.5K views
Loading…
0 reputation · 23 Oct 2022, 21:59 UTC
WebGPU employs an explicit memory model where GPUBuffer and GPUTexture objects are managed by the application. To prevent memory leaks, the destroy() method is provided to explicitly signal that the resource is no longer needed, bypassing the standard garbage collection cycle.
While the specification defines the intent of destroy(), the underlying implementation varies between browser vendors. There is uncertainty regarding whether this call triggers an immediate release of the GPU-side memory or if it merely marks the resource for deferred cleanup during the next command buffer submission.
When managing high-frequency resource turnover in complex scenes, this timing difference can impact memory pressure and allocation stability.
destroy() method ensure synchronous reclamation of GPU memory?29275 reputation · 24 Oct 2022, 03:00 UTC
No, GPUBuffer.destroy() does not guarantee the immediate, synchronous reclamation of GPU memory across browser vendors. While it explicitly marks the resource as unusable, the actual freeing of physical VRAM is managed by the browser's internal memory manager and the underlying graphics API (such as Vulkan, Metal, or DX12).
According to the WebGPU specification, destroy() signals that the resource is no longer needed, allowing the user agent to reclaim the memory at its own discretion. It does not mandate an immediate release. In practical implementations across Chrome, Firefox, and Safari, this call typically acts as a hint. Memory reclamation is often deferred until the GPU has finished executing all pending command buffers that reference that resource, or until a specific internal garbage collection threshold is met.
Because there is no direct API to query current VRAM usage in the browser, you can use a "pressure test" to verify reclamation timing in your specific environment:
webgpuGPUBuffer that consumes a significant portion of available memory.buffer.destroy().GPUBuffer of the same size.OperationError or fails, the memory from the first buffer has not yet been reclaimed.This analysis assumes the use of current stable desktop browser builds. Behavior may differ on mobile devices where aggressive OS-level memory management may force reclamation faster than on desktop. Additionally, because browser vendors frequently update their GPU process memory allocators, these observations should be verified per version release.
Diagnostic Detail: Are you experiencing OperationError during high-frequency allocations, or are you observing overall system memory growth in a debugger?
Use comments to ask for clarification. Post a solution as an answer.
29,275 reputation · 24 Oct 2022, 06:30 UTC
Calling GPUBuffer.destroy() only tells the WebGPU implementation that the application will no longer use the buffer; it does not automatically free the underlying GPU memory. The actual release can happen only after the GPU has finished executing all command buffers that reference that buffer, because the driver must keep the memory alive for any in‑flight work.
To observe when the memory becomes available, you can submit a trivial command buffer (e.g., an empty pass) after destroy(), await its completion with GPUCommandBuffer's await or GPUQueue.onSubmittedWorkDone(), then try to allocate a same‑sized buffer. If the second allocation succeeds without an OperationError, the prior buffer’s memory has been reclaimed.