[Question] How to release memory after use?

[maxxnino]

I'm using wgpu-native in zig. and I noticed only some resource have destroyed function (Buffer, Texture, Device...). And many thing don't have destroy such as CommandBuffer, RenderpassEncoder, CommandEncoder. But they have Drop function instead, Texture and Buffer both have Destroy and Drop function. What should I use?

[kvark]

The drop is the "normal" way of communicating that you don't need something. For resource-based objects (textures and buffers) we also have "Destroy" to force the resource de-allocation. If you use destroy, you aren't able to use any other objects that depend on this one. If you just "Drop", the object allocation will internally be kept alive until all the dependents are gone.

[maxxnino]

Thank for the clarify. After messing around, I found three drop function can be used:

• TextureView for current SwapChain can be Drop after SwapChainPresent is called. Without this the memory steady increase about 100kb every 10 seconds in triangle example.
• The same for ShaderModule after DeviceCreateRenderPipeline is called.
• And PipelineLayout after DeviceCreateRenderPipeline is called.

But CommandBuffer and CommandEncoder can't use Drop function anywhere. This is why I'm really confuse

[kvark]

Generally, you shouldn't need to drop command encoders/buffers. You create a command encoder, then you turn it into a command buffer, then you submit it. That's it. Dropping them would be needed if you decide to no submit the work. So it's still needed (we might be missing these methods?) but generally useful only in rare scenarios.

[almarklein]

Shouldn't it be possible to submit recorded commands multiple times? E.g. if you know that nothing has changed (for a particular part of the rendering). Or e.g. if only the uniforms have changed.

[cwfitzgerald]

wgpu doesn't support re-using command buffers like that, in general the situations where reusing command buffers is useful is minimal and ONE_TIME_SUBMIT or whatever it's called is a useful flag to have on cmdbuffers. That being said, renderbundles are how you are supposed to do save streams of draws to be replayed later.

[almarklein]

Thanks for the clarification!

[20kdc]

This is a useful issue to keep around, but I feel like this should be specified more directly, in documentation or something. It's worth noting that https://gpuweb.github.io/gpuweb/ doesn't appear to say anything about single-submission, and even if it did, it's intended for JavaScript, so says nothing about dropping. Where things get interesting is the relation between this and https://github.com/gfx-rs/wgpu-native/issues/6 - https://source.chromium.org/chromium/chromium/src/+/master:out/Debug/gen/third_party/dawn/src/include/dawn/webgpu.h does provide a specification for what appears to be "drop"-style functions.

[kryptan]

It looks like some methods are consuming their arguments. wgpuCommandEncoderFinish and wgpuRenderBundleEncoderFinish consume encoder while wgpuQueueSubmit consumes buffers. Are these the only such methods or are there others? Is there a list of them?

Calling drop after resource was consumed by one of those methods leads to a panic, so it means it is necessary to keep track of whether resource was consumed or not. This requires knowing which methods are consuming what but it seems to not be specified anywhere.

[rajveermalviya]

#272 migrates from *Drop functions to webgpu.h *Reference/*Release.

It fixes the problem of End/Finish/Submit functions dropping the related objects, now the library guarantees that they will only be dropped when calling wgpu{*}Release on an object with refcount of 1. (Library will always return objects with refcount of 1, wgpu{*}Reference function can be used to increment the refcount.)