binding_model.rs |
|
38403 |
command |
|
|
conv.rs |
|
7202 |
device |
|
|
error.rs |
|
1650 |
global.rs |
|
2693 |
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 {
/* ... |
9583 |
id.rs |
|
7618 |
identity.rs |
|
4204 |
indirect_validation.rs |
|
15730 |
init_tracker |
|
|
instance.rs |
|
33605 |
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 |
6746 |
lock |
|
|
pipeline.rs |
|
24483 |
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.
! |
13058 |
registry.rs |
|
4703 |
resource.rs |
|
64336 |
snatch.rs |
|
4748 |
storage.rs |
|
3695 |
track |
|
|
validation.rs |
|
49290 |
weak_vec.rs |
Module containing the [`WeakVec`] API. |
2190 |