Try   HackMD

WebGPU Origin Trial Caveats

WebGPU API

Missing features

WebGPU features that are not supported (either the methods/enums don't exist, or produce a validation error when used):

  • In Progress Pipeline overridable constants (dawn:1041)
  • In ProgressGPUTextureDescriptor.viewFormats is not implemented (dawn:1276
  • GPUShaderModuleDescriptor.sourceMap (chromium:1177491)
  • GPUCanvasConfiguration.colorSpace is not implemented (chromium:1241375)
  • Postponed Pipeline statistics queries. (chromium:1177506)
  • Done in M96 Vertex only pipelines (dawn:136)
  • Done in M97 GPURenderEncoderBase.drawIndexedIndirect(dawn:809)
  • Done in M97 GPUComputePassEncoder.dispatchIndirect (dawn:1039)
  • Done in M97 Changing the limits when creating an adapter (dawn:685)
  • Done in M97 depth16unorm texture format (dawn:570)
  • Done in M97 ETC2 and ASTC optional features (dawn:955)
  • Done in M98 GPUCommandEncoder.clearBuffer (dawn:1170)
  • Done in M99 Dynamic storage buffers (dawn:429)
  • Done in M100 Readonly depth and stencil render pass attachments (GPURenderPassDepthStencilAttachment.stencilReadOnly and GPURenderPassDepthStencilAttachment.depthReadOnly) (dawn:485)
  • Done in M101 Support canvas context texture formats other than bgra8unorm (chromium:1241369)
  • Done in M101 1D textures (dawn:814)
  • Done in M101 Color space conversion for copyExternalImageToTexture (dawn:964)
  • Done in M101 depth24unorm-stencil8 and depth32float-stencil8 optional features (dawn:690)
  • Done in M102GPUCanvasConfiguration.compositingAlphaMode is not implemented (chromium:1241373)
  • Done in M102 stencil8 texture format (dawn:666)
  • Done in M102 GPUDevice.destroy() (dawn:628)

Missing optimizations

A number of important optimizations aren’t implemented yet, hence benchmarks results are very likely to change over time.

  • Results of shader module and pipeline compilation isn't cached, causing all page loads to be "cold" page loads for compilation.
  • Transfer to and from the GPU (GPUQueue.writeBuffer(), GPUBuffer.mapAsync() and GPUBufferDescriptor.mappedAtCreation) are performing more copies than necessary.
  • In Progress GPUDevice.importExternalTexture performs too many copies instead of being 0 copy as intended by the specification.
  • The implementation on the Vulkan API (ChromeOS, Linux) is very naive in some places.
  • The implementations on D3D12 (Windows) and Vulkan (ChromeOS, Linux) doesn't optimize barrier scheduling, leading to missed parallelism in some workloads.
  • Many other optimizations for CPU usage, GPU memory consumption, etc.
  • Done in M96 GPUDevice.createRenderPipelineAsync() isn't actually done asynchronously (leading to GPU process stalls like GPUDevice.createRenderPipeline()).

Missing integrations

  • Linux (can be enabled with --enable-features=Vulkan)
  • Android
  • WebXR
  • In Progress CPU fallback with Swiftshader (GPURequestAdapterOptions.forceFallbackAdapter can't be set to true)
  • DevTools

Important known issues

  • Incorrect [[vertex_index]] and [[instance_index]] in indirect draws in D3D12 (dawn:548)
  • In Progress GPUAdapter.name is always "default" instead of giving useful information (chromium:1231163)
  • GPURequestAdapterOptions.powerPreference doesn't have an effect on some OSes.
  • Done in M97 Error messages for validation errors don't provide sufficient details (dawn:563)
  • Done in M97 Object labels aren't used in error messages (dawn:840)

WebGPU Shading Language (WGSL)

Note: Differences are relative to the following version of the WGSL specification: https://www.w3.org/TR/2021/WD-WGSL-20210825/

Common

  • Inter-scope variable shadowing is not supported (tint:819)
  • Array indices must be signed integer literals (tint:1068, tint:1117)
  • The num_workgroups builtin is not supported (tint:752)
  • The quantizeToF16() builtin function is not supported (tint:991)
  • The atomicSub() builtin function is not supported (tint:1130)
  • No way currently in WGSL to declare a mat2x2 that is std140 compatible.
  • Construction of a matrix from scalars is not supported (tint:1123)

Windows

  • Compilation may fail when assigning to an array nested in a structure, using a dynamic index (tint:998)
  • Infinite loops will not compile (tint:1038)
  • Loops containing certain instructions will not compile (tint:1112)
  • Continue statements cannot be used in switch statements (tint:1080)
  • Use of discard may error with Not all control paths return a value (tint:1081)
  • Division by compile-time constant zero may fail to compile (tint:1083)

macOS

  • Compilation may fail when assigning to an array nested in a structure, using a dynamic index (tint:1094)
  • Matrices cannot be used in workgroup storage (tint:938)
Last changed by 
 
WebGPU
https://webgpu.dev
5
1
3988

Read more

WebGPU upload paths (MDN article draft)

writeBuffe

Jul 19, 2023
DRAFT SharedValueTable Proposal

[Serializable] interface SharedValueTable { undefined insert([EnforceRange] unsigned long long key, any value); // value must be serializable any get([EnforceRange] unsigned long long key); undefined remove([EnforceRange] unsigned long long key); }; TODO write more Keeping track of some use cases, and random thoughts

Nov 18, 2022
Multiple components cannot effectively share a GPUDevice because it is stateful

Issue: https://github.com/gpuweb/gpuweb/issues/3250 Proposal written and proposed by Kai, based on in-depth discussion with editors (Brandon/Myles/Kai) and more input from Brandon. Previous drafts Premises It should be possible for multiple "components" using the same device on the same thread to have different error scope state. It's okay if each component can't device.destroy() independently.

Nov 8, 2022
Order of error scope resolution

Proposed by editors (Myles/Brandon/Kai), and written by Brandon, with edits from Kai. An ongoing concern about use of error scopes is that they may require that operations within the scope finish in-order. At this time, it's unclear if that may prevent certain classes of optimization, such as moving pipeline creation to a separate thread. (See #2119 for prior conversation on that point.) After some discussion the editors feel that in-order resolution is not a requirement for error scopes. This document outline the reasons why, and how we feel error scopes should operate. Proposal The proposal is to remove all constraints on the ordering of the resolution of promises from popErrorScope(), relative to one another and to other promises in the API. This allows implementations use a strict ordering, resolve strictly as early as possible, or anything else. The general behavior that we would expect from an error scope is:

Jul 26, 2022
Read more from WebGPU
Published on HackMD