Name Description Size
binding_model.rs 38424
command
conv.rs 7202
device
error.rs 1650
global.rs 3019
hal_api.rs 586
hash_utils.rs Module for hashing utilities. Named hash_utils to prevent clashing with the std::hash module. 2652
hub.rs ! Allocating resource ids, and tracking the resources they refer to. The `wgpu_core` API uses identifiers of type [`Id<R>`] to refer to resources of type `R`. For example, [`id::DeviceId`] is an alias for `Id<markers::Device>`, and [`id::BufferId`] is an alias for `Id<markers::Buffer>`. `Id` implements `Copy`, `Hash`, `Eq`, `Ord`, and of course `Debug`. [`id::DeviceId`]: crate::id::DeviceId [`id::BufferId`]: crate::id::BufferId Each `Id` contains not only an index for the resource it denotes but also a Backend indicating which `wgpu` backend it belongs to. `Id`s also incorporate a generation number, for additional validation. The resources to which identifiers refer are freed explicitly. Attempting to use an identifier for a resource that has been freed elicits an error result. ## Assigning ids to resources The users of `wgpu_core` generally want resource ids to be assigned in one of two ways: - Users like `wgpu` want `wgpu_core` to assign ids to resources itself. For example, `wgpu` expects to call `Global::device_create_buffer` and have the return value indicate the newly created buffer's id. - Users like `player` and Firefox want to allocate ids themselves, and pass `Global::device_create_buffer` and friends the id to assign the new resource. To accommodate either pattern, `wgpu_core` methods that create resources all expect an `id_in` argument that the caller can use to specify the id, and they all return the id used. For example, the declaration of `Global::device_create_buffer` looks like this: ```ignore impl Global { /* ... 11129
id.rs 7618
identity.rs 4204
init_tracker
instance.rs 29502
lib.rs This library safely implements WebGPU on native platforms. It is designed for integration into browsers, as well as wrapping into other language-specific user-friendly libraries. ## Feature flags 6667
lock
pipeline.rs 24445
pipeline_cache.rs 22577
pool.rs 10782
present.rs ! Presentation. ## Lifecycle Whenever a submission detects the use of any surface texture, it adds it to the device tracker for the duration of the submission (temporarily, while recording). It's added with `UNINITIALIZED` state and transitioned into `empty()` state. When this texture is presented, we remove it from the device tracker as well as extract it from the hub. ! 13736
registry.rs 4703
resource.rs 63122
snatch.rs 4639
storage.rs 3765
track
validation.rs 49290