W3C unveils draft WebGPU standard

The W3C has released the first drafts of the WebGPU and WebGPU Shading Language (WGSL) specifications, which define APIs for performing GPU operations such as rendering and computation, and a shader language for writing GPU-side programs. conceptually similar to the Vulkan, Metal, and Direct3D 12 APIs. The specifications were prepared by a working group that included engineers from Mozilla, Google, Apple, and Microsoft.

Conceptually, WebGPU differs from WebGL in much the same way that the Vulkan graphics API differs from OpenGL, but is not based on a specific graphics API, but is a general-purpose layer that uses the same low-level primitives found in Vulkan, Metal, and Direct3D. WebGPU provides JavaScript applications with low-level control over the organization, processing and transmission of commands to the GPU, managing associated resources, memory, buffers, texture objects, and compiled graphics shaders. This approach allows you to achieve higher performance graphics applications by reducing overhead and increasing the efficiency of the GPU.

WebGPU makes it possible to create complex 3D projects for the Web that work as well as standalone programs that directly access Vulkan, Metal or Direct3D, but are not tied to specific platforms. The WebGPU also provides additional options for porting native graphics programs to a web-enabled form by compiling to WebAssembly. In addition to 3D graphics, WebGPU also covers the possibilities associated with offloading calculations to the GPU side and executing shaders.

Key Features of WebGPU:

  • Separate management of resources, preparatory work and transmission of commands to the GPU (in WebGL, one object was responsible for everything at once). Three separate contexts are provided: GPUDevice for creating resources such as textures and buffers; GPUCommandEncoder for encoding individual commands, including the rendering and calculation stages; GPUCommandBuffer to pass to the GPU run queue. The result can be rendered in an area associated with one or more canvas elements, or processed without output (for example, when running computational tasks). The separation of stages makes it easier to separate resource creation and provisioning operations into different handlers that can run on different threads.
  • A different approach to handling states. WebGPU provides two objects - GPURenderPipeline and GPUComputePipeline, which allow you to combine different states predefined by the developer, which makes it possible for the browser to not waste resources on additional work, such as recompiling shaders. Supported states include: shaders, vertex buffer and attribute layouts, sticky group layouts, blending, depth and patterns, post-render output formats.
  • A binding model, much like Vulkan's resource grouping tools. To group resources into groups, the WebGPU provides a GPUBindGroup object, which, at the time of writing commands, can be associated with other similar objects for use in shaders. Creating such groups allows the driver to perform the necessary preparatory actions in advance, and allows the browser to change resource bindings between draw calls much faster. The layout of resource bindings can be predefined using the GPUBindGroupLayout object.

Source: opennet.ru

Add a comment