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

Remove IDs and Registries #5121

Open
3 of 8 tasks
nical opened this issue Jan 22, 2024 · 3 comments
Open
3 of 8 tasks

Remove IDs and Registries #5121

nical opened this issue Jan 22, 2024 · 3 comments
Assignees
Labels
kind: refactor Making existing function faster or nicer type: enhancement New feature or request type: tracking

Comments

@nical
Copy link
Contributor

nical commented Jan 22, 2024

This is a meta issue to describe the long-ish term vision for wgpu-core's resource management and track the steps towards it.

Registries and IDs

Internally, all wgpu-core resources are stored behind Arcs. Externally, they are exposed as non-clonable structs containing an ID which conceptually corresponds to a single reference to the Arc of a resource.

The goal

Instead of having wgpu public types wrap a non-clonabe ID, we would like them to wrap the Arc to the internal resource directly (and be clonable).

TODO

@sagudev
Copy link
Contributor

sagudev commented May 25, 2024

(Firefox): Stop providing the IDs during resource creation and do ID mapping in the gecko-side bindings.

How exactly would that look like? Would that be something like hashmap that would map id to Arc of wgpu object that would live in WebGPU thread?

I'm mostly asking for servo, as it would be nice to share ID mapping stuff.

@nical
Copy link
Contributor Author

nical commented May 28, 2024

(Firefox): Stop providing the IDs during resource creation and do ID mapping in the gecko-side bindings.

How exactly would that look like? Would that be something like hashmap that would map id to Arc of wgpu object that would live in WebGPU thread?

Yes, that's the general idea. Depending on how you generate the IDs you could get away with arrays instead of hash maps (like wgpu-core currently does).

@teoxoy teoxoy self-assigned this Jul 15, 2024
@sagudev
Copy link
Contributor

sagudev commented Jan 31, 2025

There are some cases where this would also be useful in servo, for example when doing swapchain present we always need to send new encoder id from content process so we can create new encoder in wgpu_thread, but removing registries would allow us to have concept of wgc types that are not owned by JS (content process).

I think making descriptors generic over IDs/Arced Resources would be beneficial as that would allow servo to still reuse such types for IPC. Something like this is already done in some parts using Arc* variants descriptors:

pub struct PassTimestampWrites {
/// The query set to write the timestamps to.
pub query_set: id::QuerySetId,
/// The index of the query set at which a start timestamp of this pass is written, if any.
pub beginning_of_pass_write_index: Option<u32>,
/// The index of the query set at which an end timestamp of this pass is written, if any.
pub end_of_pass_write_index: Option<u32>,
}
/// Describes the writing of timestamp values in a render or compute pass with the query set resolved.
pub struct ArcPassTimestampWrites {
/// The query set to write the timestamps to.
pub query_set: Arc<crate::resource::QuerySet>,
/// The index of the query set at which a start timestamp of this pass is written, if any.
pub beginning_of_pass_write_index: Option<u32>,
/// The index of the query set at which an end timestamp of this pass is written, if any.
pub end_of_pass_write_index: Option<u32>,
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: refactor Making existing function faster or nicer type: enhancement New feature or request type: tracking
Projects
Status: Todo
Development

No branches or pull requests

4 participants