| global |
|
|
- |
| 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
[`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 panic.
## Assigning ids to resources
Firefox and Servo allocate ids themselves in the content process using [`IdentityHub`],
then pass then via IPC to GPU process where it's passed down to
`Global::device_create_buffer` and friends the id to assign the new
resource.
Methods that create resources all expect an `id_in` argument
that the caller uses to specify the id. For example, the
declaration of `Global::device_create_buffer` looks like this:
```ignore
impl Global {
/* ... |
6613 |
- |
| id.rs |
|
676 |
- |
| lib.rs |
!
This crate is a remoting version of [`wgpu_core`] for browser implementing WebGPU.
Modern browsers have content processes that are untrusted and cannot directly access the GPU.
Instead, they communicate with a trusted GPU process that has access to the GPU.
wgpu-core-remote provides a remoting wrapper around [`wgpu_core`] named [`Global`](crate::global::Global),
that is used in the GPU process to execute commands from the content process.
All stuff that is needed in the content process is provided in the [`wgpu_core_remote_types`] crate.
The key part of remoting are [`Id`](crate::id::Id) which are described in [`crate::hub`].
|
1211 |
- |
| registry.rs |
|
1336 |
- |
| storage.rs |
|
6594 |
- |