| as_hal.rs |
|
12413 |
- |
| binding_model.rs |
|
50494 |
- |
| command |
|
|
- |
| conv.rs |
|
8627 |
- |
| device |
|
|
- |
| error.rs |
|
1692 |
- |
| global.rs |
|
2621 |
- |
| 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.
Eventually, we would like to remove numeric IDs from wgpu-core.
See <https://github.com/gfx-rs/wgpu/issues/5121>.
## 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 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 {
/* ... |
11038 |
- |
| id.rs |
|
9710 |
- |
| identity.rs |
|
4940 |
- |
| indirect_validation |
|
|
- |
| init_tracker |
|
|
- |
| instance.rs |
|
44009 |
- |
| 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 |
7500 |
- |
| limits.rs |
Functionality related to device and adapter limits.
# Limit Bucketing
Web browsers make various information about their operating environment
available to content to provide a better experience. For example, content is
able to detect whether the device has a touch-screen, in order to provide an
appropriate user interface.
[Browser fingerprinting][bfp] employs this information for the purpose of
constructing a unique "fingerprint" value that is unique to a single browser
or shared among a relatively small number of browsers. Fingerprinting can be
used for various purposes, including to identify and track users across
different websites.
Limit bucketing can reduce the ability to fingerprint users based on GPU
hardware characteristics when using `wgpu` in applications like a web
browser.
When limit bucketing is enabled, the adapter limits offered by `wgpu` do not
necessarily reflect the exact capabilities of the hardware. Instead, the
hardware capabilities are rounded down to one of several pre-defined buckets.
The goal of doing this is for there to be enough devices assigned to each
bucket that knowledge of which bucket applies is minimally useful for
fingerprinting.
Limit bucketing may be requested by setting `apply_limit_buckets` in
[`wgt::RequestAdapterOptions`] or by setting `apply_limit_buckets` to
true when calling [`enumerate_adapters`].
If your application does not expose `wgpu` to untrusted content, limit
bucketing is not necessary.
[bfp]: https://support.mozilla.org/en-US/kb/firefox-protection-against-fingerprinting
[`enumerate_adapters`]: `crate::instance::Instance::enumerate_adapters` |
22186 |
- |
| lock |
|
|
- |
| pipeline.rs |
|
32855 |
- |
| pipeline_cache.rs |
|
22948 |
- |
| 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.
! |
15065 |
- |
| ray_tracing.rs |
|
15795 |
- |
| registry.rs |
|
4482 |
- |
| resource.rs |
|
87211 |
- |
| scratch.rs |
|
1407 |
- |
| snatch.rs |
|
6270 |
- |
| storage.rs |
|
3931 |
- |
| timestamp_normalization |
|
|
- |
| track |
|
|
- |
| validation |
|
|
- |
| validation.rs |
|
81575 |
- |
| weak_vec.rs |
Module containing the [`WeakVec`] API. |
1855 |
- |