| binding_model.rs |
|
42535 |
| command |
|
|
| conv.rs |
|
8267 |
| device |
|
|
| error.rs |
|
1784 |
| global.rs |
|
2785 |
| hal_api.rs |
|
584 |
| hash_utils.rs |
Module for hashing utilities.
Named hash_utils to prevent clashing with the core::hash module. |
624 |
| 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 {
/* ... |
9793 |
| id.rs |
|
7667 |
| identity.rs |
|
4227 |
| indirect_validation.rs |
|
15808 |
| init_tracker |
|
|
| instance.rs |
|
34444 |
| 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 |
7417 |
| lock |
|
|
| pipeline.rs |
|
21821 |
| pipeline_cache.rs |
|
22624 |
| pool.rs |
|
10484 |
| 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.
! |
13167 |
| ray_tracing.rs |
|
8711 |
| registry.rs |
|
4714 |
| resource.rs |
|
68526 |
| scratch.rs |
|
1360 |
| snatch.rs |
|
4719 |
| storage.rs |
|
3715 |
| track |
|
|
| validation.rs |
|
52857 |
| weak_vec.rs |
Module containing the [`WeakVec`] API. |
1855 |