Figuring out lifetime management

[Kangz]

Lifetime management is the only issue left before webgpu.h can be useful (that, and device creation, and swapchain but they can be in dawn/wgpu-rs private headers for some time).

Here's three options that I believe cover most of the design space and are all useful and reasonable:

1: Single call delete (no refcounting)

With this, there is a single function for each object type, that when called will make the WebGPU object handle invalid. (but won't implicitly call wgpuBufferDestroy or wgpuTextureDestroy).

WGPUDevice wgpuDeviceCreateBuffer(WGPUDevice device,
                                  const WGPUDeviceDescriptor* descriptor);
void wgpuBufferDelete(WGPUBuffer buffer);

2: Refcounting, "ComPtr" way.

Object lifetime is controlled by a refcount, which starts at 1 and can be increased or decreased by 1. When it reaches 0, the object handle becomes invalid (but there is no implicit call to wgpuBufferDestroy or wgpuTextureDestroy)

WGPUDevice wgpuDeviceCreateBuffer(WGPUDevice device,
                                  const WGPUDeviceDescriptor* descriptor);
void wgpuBufferReference(WGPUBuffer buffer);
void wgpuBufferRelease(WGPUBuffer buffer);

3: Refcounting, shallow-cloning way.

This one is more experimental, in particular objects that are shallow-clones of each other may have the same handle representation in some implementations and not others, which could break apps if they try to compare them.

Objects start with a refcount of 1. Refcount can be increased by returning a handle that represents that reference. Deleting a handle decreases the refcount by 1 and makes this handle invalid. Reaching refcount 0 there are no more valid handles (but there is no implicit call to wgpuBufferDestroy or wgpuTextureDestroy).

WGPUDevice wgpuDeviceCreateBuffer(WGPUDevice device,
                                  const WGPUDeviceDescriptor* descriptor);
WGPUBuffer wgpuBufferReference(WGPUBuffer buffer);
void wgpuBufferRelease(WGPUBuffer buffer);

Discussion

As described previously, I think we should have some form of refcounting because it is already present in all implementations, and helps when making large apps. You could wrap WebGPU objects in shared_ptr but that adds an extra unnecessary indirection and allocation.

I remember there was some concern due to the structure of wgpu-rs which I didn't fully understand or remember, but maybe option 3 helps with it?

[kvark]

Neither of the choices listed have an option to "destroy()", which could arguably be added to any of the 3 choices here, assuming the upstream WebGPU semantics is clarified (at the F2F, presumably).

Previous arguments

Now, let me try to recap the most important arguments of the previous discussions:

In JS, destroy() is needed because we have no control over the garbage collector. This doesn't apply to native headers, where there is no GC.

Counter argumet: There is still a question of whether destroy() is useful regardless of GC, just because we have other objects holding references to our buffer/texture.

Counter^2: this makes CIN to affect seemingly immutable objects after their creation, e.g. a bind group could become invalid out of a sudden, which is error prone and not obvious.

Counter^3: we already have cases in the API where this is the case:

• losing a device makes all objects, including immutable ones, invalid
• presenting a swapchain texture effectively destroys it from the user perspective: any object referencing such texture becomes invalid

Counter^4:

• for device lost, we don't have a choice, and there is no pretending that "everything is OK" - world needs to be rebuilt entirely. So it's not error prone.
• for swapchain texture, if Return TextureView by the SwapChain gpuweb/gpuweb#438 is accepted, the only objects that could keep a reference to it are command/renderpass buffer/encoder. Given the standard workflow of recording a command buffer rendering to a swapchain texture per frame, this is hardly error-prone either.
• for an arbitrary resource, if the user doesn't know which bind groups/texture views/command buffers reference it when it's being destroyed, that's already a recipe for disaster. If they do know those referencing objects, they might as well explicitly delete them, in which case deleting the original resource should be semantically equivalent to the proposed destroy().

Ref-counting

Going back to ref-counting discussion. If the user can decrease an internal ref-count that we use for tracking resources, that's a very bad situation for us to face. Having the internal ref-counting hidden allows us to reason about the system and its guarantees. We currently rely on that heavily, and exposing the ref-counting would just add too much risk.

We'd also want to keep the door open to have some other form of dependency tracking in our implementation that doesn't look exactly like ref-counting. Say, make the bind group to know about the set of command buffers where it's used, instead of a bare count. Keeping support for ref-counting in this case would be counter-productive.

Back to choices

Choices we have, specifically about ref-counting:
A) Expose it either as a standard feature of all objects, or as an extension.
B) Don't expose it. Optionally, instead, provide "user data" storage of, say, 2 bytes per object (recalling you were concerned about that size previously). The users would be able to use it to implement their own ref-counting on top.

I'm leaning towards B+user_data choice as the least risky and most flexible.

Finally, not sure how (3) is supposed to work for any implementation that doesn't want to expose ref-counting :)

[Kangz]

Neither of the choices listed have an option to "destroy()", which could arguably be added to any of the 3 choices here, assuming the upstream WebGPU semantics is clarified (at the F2F, presumably).

Indeed, the three choices above assume that void wgpuBufferDestroy(WGPUBuffer buffer); is present.

for swapchain texture, if gpuweb/gpuweb#438 is accepted

I've meant to answer this but it is invalidate by @kainino0x's unswapchainv2 proposal so I didn't spend time on it. But basically I don't think that PR is the correct direction for the API because it artificially restricts what users can do, for concerns that don't exist in the Web platform: there is a browser compositor, and at least in Chromium, fullscreen or layer promotion goes through OS-specific paths that allow sampling / reading back the texture.

We can discuss the swapchain API for webgpu-native separately but I would likely push for an API very similar to WebGPU in JS that hands out WGPUTextures.

Having the internal ref-counting hidden allows us to reason about the system and its guarantees. We currently rely on that heavily, and exposing the ref-counting would just add too much risk.

In languages with RAII (basically everything but C) that would never be a problem because the wrappers for WebGPU would correctly reference and release objects. In C people can shoot themselves in the foot by using objects after they are freed anyway so /shrug.

We'd also want to keep the door open to have some other form of dependency tracking in our implementation that doesn't look exactly like ref-counting. Say, make the bind group to know about the set of command buffers where it's used, instead of a bare count. Keeping support for ref-counting in this case would be counter-productive.

You're putting some hashmaps in bindgroups and are worried about the cost of a refcount?

A) Expose it either as a standard feature of all objects, or as an extension.

An extension would be very unfortunate because our goal pushing for webgpu.h is for folks using Dawn to be able to swap it for wgpu-rs easily. The alternative being that you can only use Dawn in C++ and only use wgpu-rs in Rust :/.

B) Don't expose it. Optionally, instead, provide "user data" storage of, say, 2 bytes per object (recalling you were concerned about that size previously).

WebGPU implementations need an internal 64bit refcount to avoid JS causing overflows on 32bit refcounts. The user data storage could work but it would require you to add 2 bytes that can barely be used for anything else than refcounting, so why not just do A)?

Finally, not sure how (3) is supposed to work for any implementation that doesn't want to expose ref-counting :)

Yeah, I was thinking maaaaybe it could help for your implementation but I'm happy to trash that idea.

[austinEng]

A related topic on this rather old issue:

is the WGPUDevice kept alive by child objects?

WGPUDevice device = ...;
WGPUBufferDescriptor bufferDesc = ...;
WGPUBuffer buffer = wgpuDeviceCreateBuffer(device, &bufferDesc);
wgpuDeviceRelease(device);

Some of our native users run into issues where they drop the reference to the C++ wgpu::Device and don't understand why their app breaks.

I was thinking it would be nice to internally add refcounting, but it does add some complexity for Dawn since we'd like to reuse our frontend to implement internal pipelines, etc. resulting in cyclical refs. I also realized that internal refs may not be compatible with wgpu-rs but @kvark it looks like there are internal refs?

I think it would be nice to have these refs, and eventually have a device.Destroy() if users need to ensure all device resources are promptly destroyed.

[kvark]

@austinEng the device needs to be held alive, just like any other resource dependencies are held alive (i.e. texture view holds the parent texture). But this doesn't mean anything for refcounting - there doesn't have to be a public refcounting API for the dependencies to be alive.

[austinEng]

needs to be held alive

Well, it needs to be alive but not necessarily held alive by the implementation.

Right I didn't mean to say there must be public refcounting - but some notion of internal ownership to keep stuff alive. We do as well have texture view keep the texture alive. Currently in Dawn, however, the device is not kept alive by its child objects and @Kangz (last we talked at least) doesn't think we should keep it alive.

[Kangz]

There's many possible semantics for lifetime, this is discussing assuming ref/release lifetime management:

1. Child objects MUST be deleted before the device.

WGPUDevice device = ...;
WGPUQueue queue = wgpuDeviceGetQueue(device);

// Error! Queue must be deleted before the device otherwise a segfault might
// happen when you try to delete the queue!
wgpuReleaseDevice(device);

2. Child objects keep the device alive. Note that this semantic matches JS the closest.

WGPUDevice device = ...;
WGPUQueue queue = wgpuDeviceGetQueue(device);

wgpuReleaseDevice(device);
// This is valid, and you could send real work to the device.
wgpuQueueSubmit(queue, 0, nullptr);

// This release order is valid because the queue keeps a ref to the device.
wgpuDeviceRelease(device);
wgpuQueueRelease(queue);

2bis) device gains a .destroy() method that make all further operations invalid. Something we probably want in Javascript at some point, if only to "lose for testing" the device, but also to make it easy to reclaim resources before the GC makes a pass.

WGPUDevice device = ...;
WGPUQueue queue = wgpuDeviceGetQueue(device);

wgpuDestroyDevice(device);
// This is invalid because the device was destroyed
wgpuQueueSubmit(queue, 0, nullptr);

3. Somehow we know when the "external refcount" of the device reaches 0 (or the device is deleted if we use the "deleted" variant) and internally null all WebGPU objects when it happens. Then the deletion order can be arbitrary.

WGPUDevice device = ...;
WGPUQueue queue = wgpuDeviceGetQueue(device);

wgpuReleaseDevice(device);
// This is invalid, all child objects are now internally null.
wgpuQueueSubmit(queue, 0, nullptr);

wgpuQueueRelease(queue);

IMHO 2) and 2bis) are the better solutions because they have the least footguns but allow controlling exactly when a device is stopped and mostly deallocated.

[austinEng]

For some reason I thought we disagreed here, but yes I agree that 2 or 2b would be my preferred option. It seems like 2 is what's already implemented in wgpu-core, so we can do the same in Dawn and consider 2b as an improvement.

[Kangz]

Talking with @austinEng today I think I meant 3) + 2bis).

[kainino0x]

I had planned to add a device.destroy() at the JS level (as part of the init blitz I'm currently doing), though I don't know if it'll be approved. I guess I'll open that sooner rather than later for the benefit of this issue.

[kainino0x]

gpuweb/gpuweb#1316

[kainino0x]

For the record, conversations have continued on: #15 #94 #100 and possibly others

[litherum]

It sure would be useful to have a resolution here.