sysgpu: supersede WebGPU with new sysgpu graphics API #1055

New issue

Open

opened 2023-10-05 03:28:42 +00:00 by emidoots · 6 comments

emidoots commented

2023-10-05 03:28:42 +00:00

(Migrated from github.com)

Proposals / decisions made:

WebGPU API divergences
- ✅ Native render graph support
- ✅ Remove next_in_chain
- ✅ All Mach and Dawn extensions become non-extensions (just become part of the API) if desirable
- ✅ D3D StructuredBuffers
- ✅ Streaming Uniforms
Shading language divergences
- ✅ Remove WGSL support in favor of Zig-inspired shading language
- ✅ Explicit adapter enumeration/selection
Goals
- ✅ First-class C API support
- ✅ Ability to intercept API calls / wrap implementation in Zig (like gpu.Interface)
- ✅ Backends:
  - Direct3D 12
  - Vulkan (1.0?)
  - Metal
  - WebGPU (Dawn native fallback, browser)

Things worth considering if we can improve:

The auto layout footgun discord
bufferGetMappedRange returning null with no error string / explanation of why
Removing arrayLength
Binding model / default pipeline layout
Remove mapAsync entirely if we can cover the same use-cases other ways
- We've talked through upload cases that I think are good enough to remove it. Readback will need some way for the application to know its done.
Introduce fences / application level synchronization? e.g. this
- Replace getCurrentTextureView with something that allows for e.g. 2 frames in flight/3 swap chain buffers.
- Having to write code like this is a bit painful/ugly
Enable waitable swap chains with different frame count than buffer count (Intel article for details)

This is a tracking issue for ongoing development of Dusk. Dusk started as a WGPU implementation (and is one today) but is being developed beyond that, into a new graphics API called DGPU. We are making some key changes to the WGPU API, for specific reasons, and this issue is for tracking those changes / decisions. Proposals / decisions made: * WebGPU API divergences * ✅ Native render graph support * ✅ Remove `next_in_chain` * ✅ All Mach and Dawn extensions become non-extensions (just become part of the API) if desirable * ✅ [D3D StructuredBuffers](https://github.com/hexops/mach/issues/1055#issuecomment-1751568797) * ✅ [Streaming Uniforms](https://github.com/hexops/mach/issues/1055#issuecomment-1751568797) * Shading language divergences * ✅ Remove WGSL support in favor of Zig-inspired shading language * ✅ Explicit adapter enumeration/selection * Goals * ✅ First-class C API support * ✅ Ability to intercept API calls / wrap implementation in Zig (like `gpu.Interface`) * ✅ Backends: * Direct3D 12 * Vulkan (1.0?) * Metal * WebGPU (Dawn native fallback, browser) Things worth considering if we can improve: * The [`auto` layout footgun](https://toji.dev/webgpu-best-practices/bind-groups.html#hard-to-predict) [discord](https://discord.com/channels/996677443681267802/1160571051747590265/1160571051747590265) * [`bufferGetMappedRange` returning `null` with no error string / explanation of why](https://discord.com/channels/996677443681267802/1160305655844978749/1160307981217431623) * Removing `arrayLength` * Binding model / default pipeline layout * Remove mapAsync entirely if we can cover the same use-cases other ways * We've talked through upload cases that I think are good enough to remove it. Readback will need some way for the application to know its done. * Introduce fences / application level synchronization? [e.g. this](https://discord.com/channels/996677443681267802/1153411442813448254/1160668470086746122) * Replace `getCurrentTextureView` with something that allows for e.g. 2 frames in flight/3 swap chain buffers. * Having to write code [like this](https://github.com/hexops/mach-core/blob/90c927e20d045035152d9b0b421ea45db7e5569c/examples/sysgpu/map-async/main.zig#L81-L88) is a bit painful/ugly * Enable waitable swap chains with different frame count than buffer count ([Intel article for details](https://www.intel.com/content/www/us/en/developer/articles/code-sample/sample-application-for-direct3d-12-flip-model-swap-chains.html))

mateli commented

2023-10-05 07:53:46 +00:00

(Migrated from github.com)

Will Mach still run in browsers that only support native WGPU?

emidoots commented

2023-10-05 15:11:53 +00:00

(Migrated from github.com)

Yes, DGPU will have a WebGPU backend

pdoane commented

2023-10-07 02:32:40 +00:00

(Migrated from github.com)

Two changes I would like to add to the list:

D3D StructuredBuffers

WebGPU implementation requires use of ByteAddressBuffer
StructuredBuffer is faster on many GPUs (see https://github.com/sebbbi/perftest) but requires stride be specified in the binding layout

Streaming Uniforms

WebGPU cannot make use of Push/Root Constants or Metal set buffer bytes (although this is being discussed as an explicit feature for later versions)
We can expose a higher-level API for updating uniforms on the encoder
This simplifies application use (no need to manage dynamic offsets on bind groups) and enables use of these features in the backend

Two changes I would like to add to the list: **D3D StructuredBuffers** - WebGPU implementation requires use of ByteAddressBuffer - StructuredBuffer is faster on many GPUs (see https://github.com/sebbbi/perftest) but requires stride be specified in the binding layout **Streaming Uniforms** - WebGPU cannot make use of Push/Root Constants or Metal set buffer bytes (although this is being discussed as an explicit feature for later versions) - We can expose a higher-level API for updating uniforms on the encoder - This simplifies application use (no need to manage dynamic offsets on bind groups) and enables use of these features in the backend

👍 2

pdoane commented

2023-10-11 00:44:05 +00:00

(Migrated from github.com)

Vertex/Fragment linkage

HLSL vertex-fragment linkage requires stage variables to be in the same order, and all variables in the later stage must be present in the earlier stage. When HLSL is generated at pipeline generation time, input/output structs can be sorted and unused vertex outputs eliminated. Offline compilation will require the shaders to match.

**Vertex/Fragment linkage** HLSL vertex-fragment linkage requires stage variables to be in the same order, and all variables in the later stage must be present in the earlier stage. When HLSL is generated at pipeline generation time, input/output structs can be sorted and unused vertex outputs eliminated. Offline compilation will require the shaders to match.

pdoane commented

2023-10-11 00:45:01 +00:00

(Migrated from github.com)

Optional Input Assembler

D3D12_ROOT_SIGNATURE_FLAG_ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT should not be passed for root signatures unless needed. Add a flag to PipelineLayout to indicate that vertex buffers are used by the pipeline.

**Optional Input Assembler** `D3D12_ROOT_SIGNATURE_FLAG_ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT ` should not be passed for root signatures unless needed. Add a flag to PipelineLayout to indicate that vertex buffers are used by the pipeline.

pdoane commented

2023-10-11 00:46:07 +00:00

(Migrated from github.com)

MSAA Depth Resolve

Add support for MSAA depth targets in render passes

**MSAA Depth Resolve** Add support for MSAA depth targets in render passes