0357dd80af
712: RODS part 2 r=cwfitzgerald a=kvark **Connections** Unblocks https://github.com/gfx-rs/wgpu-rs/issues/359 Is a follow-up to RODS part 1 - #685 **Description** There is a few things in here. Thing 1: Stronger assertions on the load/store ops of the depth & stencil. ### Thing 2: rewritten tracking of render attachments Background: from the usage tracker point of view, each subresource can be in either "extend" mode, where it accumulates a single combined usage, or in the "replace" mode, where it goes from one usage to another, producing the relevant transitions on the way. The problem turned out to come from the fact that the render pass attachments were always tracked in "replace" mode. This is needed because their track don't have a single state: render pass itself encodes a transition of attachments. However, it also means that there was no way to "extend" the usage in RODS scenarios... So I could see two ways to address this: - re-achitecture the tracking a bit more in general, representing it as a sequence of merges. - introduce the "prepend()" tracking operator that's *only* used for render pass attachments I opted for the latter as it seems much less intrusive. The render pass attachments accumulate their usage like everything else in the "extend mode". But right before we are inserting the transitions (between the active command buffer and the pass), we turn the tracking of the attachments from "extend" into "replace" mode by installing the "first" usage according to what we expect it to be. ### Thing 3: missing API for RODS bind groups The original RODS design missed a problem with Vulkan image layouts. When creating a bind group, one has to specify what layout the image will be in. We always used `ShaderReadOnlyOptimal` until now for texture views. However, in RODS scenarios this has to be `DepthStencilReadOnlyOptimal`. Luckily, it's compatible with sampling from the shader, but we still need to know about this when creating the bind group. **Testing** Tested on the modified water example provided in https://github.com/gfx-rs/wgpu-rs/issues/359#issuecomment-642167269 Added a few tests to the buffer implementation of the new `prepend()` operator. Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
This is an active GitHub mirror of the WebGPU implementation in Rust, which now lives in "gfx/wgpu" of Mozilla-central. Issues and pull requests are accepted, but some bidirectional synchronization may be involved.
WebGPU
This is the core logic of an experimental WebGPU implementation. It's written in Rust and is based on gfx-hal with help of gfx-extras. See the upstream WebGPU specification (work in progress).
The implementation consists of the following parts:
- internal Rust API for WebGPU implementations to use
- Rust types shared between wgpu-core,wgpu-native, andwgpu-rsplayer- standalone application for replaying the API traces, useswinit
This repository contains the core of wgpu, and is not usable directly by applications.
If you are looking for the user-facing Rust API, you need wgpu-rs.
If you are looking for the native implementation or bindings to the API in other languages, you need wgpu-native.
Supported Platforms
| API | Windows 7/10 | Linux & Android | macOS & iOS |
|---|---|---|---|
| DX11 | ✅ | ||
| DX12 | ✔️ | ||
| Vulkan | ✔️ | ✔️ | |
| Metal | ✔️ | ||
| OpenGL | 🚧 | 🚧 | 🚧 |
✔️ = Primary support — ✅ = Secondary support — 🚧 = Unsupported, but support in progress