The W3C Consortium has released the first draft specifications for WebGPU and WebGPU Shading Language (WGSL), defining an API for executing operations on the GPU, such as rendering and computations, as well as a shading language for writing programs that run on the GPU. Conceptually similar to Vulkan, Metal, and Direct3D 12, the specifications were prepared by a working group that includes engineers from Mozilla, Google, Apple, and Microsoft.
Conceptually, WebGPU differs from WebGL much like the Vulkan graphics API differs from OpenGL, but it does not rely on any specific graphics API. Instead, it serves as a universal layer that utilizes the same low-level primitives found in Vulkan, Metal, and Direct3D. WebGPU provides JavaScript applications with means for 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 enables higher performance for graphics applications by reducing overhead and improving efficiency when working with the GPU.
WebGPU enables the creation of complex 3D projects for the web that perform as well as standalone applications that directly interact with Vulkan, Metal, or Direct3D, without being tied to specific platforms. WebGPU also provides additional capabilities when porting native graphics applications into a form that can work with web technologies, thanks to compilation to WebAssembly. In addition to 3D graphics, WebGPU covers capabilities related to offloading computations to the GPU and executing shaders.
Key features of WebGPU:
- Separate management of resources, setup operations, and command submission to the GPU (in WebGL, a single object was responsible for everything at once). Three separate contexts are provided: GPUDevice for creating resources like textures and buffers; GPUCommandEncoder for encoding individual commands, including rendering and compute stages; and GPUCommandBuffer for queuing for execution in the GPU. The result can be rendered in an area associated with one or more canvas elements or processed without output (for example, when executing compute tasks). This separation of stages simplifies the distribution of resource creation and setup operations into different handlers that can run in different threads.
- A different approach to state management. WebGPU proposes two objects — GPURenderPipeline and GPUComputePipeline, which allow for the combination of various states predefined by the developer, enabling the browser to avoid expending resources on additional tasks like recompiling shaders. Among the supported states are: shaders, vertex buffer layouts and attributes, attached group layouts, blending, depth and templates, output formats after rendering.
- The binding model is largely reminiscent of the grouping resources found in Vulkan. To group resources in WebGPU, a GPUBindGroup object is provided, which can be linked with other similar objects during command recording for use in shaders. Creating such groups allows the driver to perform necessary preparatory actions in advance and enables the browser to switch resource bindings between rendering calls much faster. The layout of resource bindings can be defined in advance using a GPUBindGroupLayout object.
Source: opennet.ru
