Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Object lifetime management #26

Closed
kvark opened this issue Oct 31, 2018 · 0 comments · Fixed by #27
Closed

Object lifetime management #26

kvark opened this issue Oct 31, 2018 · 0 comments · Fixed by #27
Assignees
Labels
type: question Further information is requested

Comments

@kvark
Copy link
Member

kvark commented Oct 31, 2018

Automatic lifetime management is one of the main usability/safety gains of WebGPU API.

First problem to solve - figure out what layer is responsible for this. Since wgpu-native exposes simple IDs and it doesn't know if the user keeps any of those, it can't know when resources are destroyed, unless specifically told to do so. It can, however, track the resource usage in pending command buffers and executing on GPU. That is why I believe the lifetime should go through the following stages at wgpu-native level:

  1. resource is created by the user
  2. resource is used for other resources or in commands
  3. user explicitly destroys the resource
  4. all dependent objects and command buffers are destroyed
  5. GPU has finished execution of any relevant command buffers
  6. the implementation actually destroys the resource

At the same time, wgpu-rs needs to be able to avoid explicit destruction and just use RAII for that. The other clients, like Gecko, know when a resource is garbage collected and can send us appropriate message for destruction.

Second problem - how exactly to implement that tracking on wgpu-native level. I was initially thinking about have all objects to carry something like this:

pub(crate) struct LifeGuard {
    pub owned_by_user: AtomicBool,
    pub used_by_objects: AtomicUsize,
    pub used_by_commands: AtomicUsize,
    pub last_submission_index: AtomicUsize,
}

However, I later realized that we could instead enrich the Stored wrapper semantics to keep track of the usage. The sub-problem here is for Stored to not have Arc<Id> since it involves another indirection on access.

@kvark kvark added the type: question Further information is requested label Oct 31, 2018
@kvark kvark mentioned this issue Nov 2, 2018
4 tasks
@kvark kvark self-assigned this Nov 2, 2018
bors bot added a commit that referenced this issue Nov 4, 2018
27: Resource lifetime tracking r=grovesNL a=kvark

Fixes #26

This change ends up being much more serious and intrusive, but hopefully manage-able. The idea is that the native layer would have explicit deletion calls exposed, but would still guarantee that resources live for as long as they are used by either CPU or GPU. The device, in order to guarantee that, keeps track of resources associated with fences and walks through them for clean up.

Maintaining the actual ref-counts per object up-to-date is one of the most challenging tasks. I choose to use the existing `Stored` structure to host it, so that we are forced to clone the refcounts, and it's difficult to screw up. I still had to provide the "old" semantics under the new name of `WeaklyStored` though, and we should be careful about it.

TODO:
  - [ ] review and test
  - [x] fix transition API once more, so that command buffers are stitched properly and resources are tracked by the device
  - [ ] update the Rust layer, using RAII
  - [ ] update the examples

Co-authored-by: Dzmitry Malyshau <dmalyshau@mozilla.com>
@bors bors bot closed this as completed in #27 Nov 4, 2018
mitchmindtree pushed a commit to mitchmindtree/wgpu that referenced this issue Feb 23, 2020
26: Rename msaa-linelist to msaa-line r=kvark a=rukai

As requested on gitter by @kvark 

Co-authored-by: Rukai <rubickent@gmail.com>
kvark pushed a commit to kvark/wgpu that referenced this issue Jun 3, 2021
26: Rename msaa-linelist to msaa-line r=kvark a=rukai

As requested on gitter by @kvark 

Co-authored-by: Rukai <rubickent@gmail.com>
cwfitzgerald pushed a commit that referenced this issue Oct 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant