| binding_model.rs |
|
38791 |
| command |
|
|
| conv.rs |
|
7481 |
| device |
|
|
| error.rs |
|
1650 |
| global.rs |
|
2585 |
| hal_api.rs |
|
586 |
| hash_utils.rs |
Module for hashing utilities.
Named hash_utils to prevent clashing with the std::hash module. |
634 |
| 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 {
/* ... |
9782 |
| id.rs |
|
7712 |
| identity.rs |
|
4204 |
| indirect_validation.rs |
|
15730 |
| init_tracker |
|
|
| instance.rs |
|
33699 |
| 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 |
6780 |
| lock |
|
|
| pipeline.rs |
|
24319 |
| pipeline_cache.rs |
|
22577 |
| pool.rs |
|
10473 |
| 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.
! |
12867 |
| ray_tracing.rs |
|
9040 |
| registry.rs |
|
4703 |
| resource.rs |
|
74052 |
| scratch.rs |
|
1341 |
| snatch.rs |
|
4748 |
| storage.rs |
|
3695 |
| track |
|
|
| validation.rs |
|
49688 |
| weak_vec.rs |
Module containing the [`WeakVec`] API. |
2212 |