Architecture
This page gives an overview of wgpu's architecture.
Note that wgpu represents only one possible way to implement the WebGPU API; Google's Dawn and WebKit's WebGPU module are other WebGPU implementations used in production.
- Naga Shader translation and validation.
TODO (why/how)
Unlike Vulkan & DX12, WebGPU does not track resource barriers (more info). Therefore, wgpu needs to track and insert barriers.
ResourceTracker keeps track of the current usage of a single kind type of resource.
TrackerSet ("the" tracker) has ResourceTracker for every type.
Since every CommandBuffer is recorded independently, each of them has a TrackerSet. Each render pass has a separate TrackerSet, and so does each bind group. These tracker sets flow into the parent trackers:
- When a bind group is set in a render pass, it's tracked resources are merged into the pass resources.
- When a render pass is finished recording, it's tracker is merged into the command buffer's tracker, with needed barriers issued.
- Command buffer trackers are combined during
queue_submitinto the device's tracker. additional resource barriers are generated if necessary.
Tracks memory initialization state of Buffer resources, i.e. if they have been written to either by the user or by wgpu previously zero-initializing it (WebGPU requires all buffers to behave as-if they are zero inititialized). A MemoryInitTracker tracks a single buffer and allows to insert zero initialization lazily on use. Zero init is inserted if necessary at:
- memory mapping
-
queue_submit(for all bindings)
TODO (what/why)
What else is non-trivial?
Enabled via feature flag. Allows to record all usage (WebGPU api functions essentially) to a .ron file. Any additional data (uploaded data to buffer etc.) is stored in additional files.
A trace can be replayed with the Player compiled from the same wgpu revision.
Used for testing and bug reporting.