El W3C unveiled Recently, the first drafts of the WebGPU and WebGPU Shading Language specifications (WGSL), which define APIs for performing GPU operations such as rendering and computation, and a shader language for writing GPU-side programs.
These specs are 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.
The goal of the GPU for the web workgroup is to provide an interface between the web platform and modern 3D graphics and computing capabilities found in native system platforms. Learn more about the goals, scope, and deliverables.
The GPU for Web Community Group developed the specifications adopted by this Working Group. The Community Group continues to push technical work on specifications and incubating new features. This Working Group works with the Community Group to shape the specifications for the Recommendation pathway.
Conceptually, WebGPU differs from WebGL in the same way that the graphics API Vulkan differs from OpenGL, but it is not based on a specific graphics API, rather it is a universal layer that uses the same low-level primitives found in Vulkan, Metal, and Direct3D.
WebGPU provides JavaScript applications with tools for low-level control sabout the organization, processing and transmitting commands to the GPU, managing associated resources, memory, buffers, texture objects, and compiled graphics shaders. This approach enables you to achieve higher performance for graphics applications by reducing overhead and increasing GPU efficiency.
WebGPU allows you to create complex 3D projects for the web that do not work in the same way as in standalone programs that directly access Vulkan, Metal, or Direct3D, but are not tied to specific platforms.
WebGPU also provides additional capabilities to port native graphics programs to a web-based form by compiling in WebAssembly. In addition to 3D graphics, WebGPU also covers the possibilities associated with outsourcing calculations to the GPU side and running shaders.
Key WebGPU Features:
- Separate resource management, preparatory work, and transfer 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 stamps; GPUCommandEncoder to encode individual commands, including the processing and calculation stages; GPUCommandBuffer to queue for execution on the GPU. The result can be rendered in an area associated with one or more canvases, or rendered without rendering (for example, when running computational tasks). Staging makes it easy to separate resource creation and preparatory operations on different controllers that can run on different threads.
- A different approach to handling statusyes WebGPU offers two objects, GPURenderPipeline and GPUComputePipeline, what allow combining different states predefined by the developer, which allows the browser not to waste resources on additional work such as recompiling shaders. Supported states include shaders, vertex buffers and attribute layouts, attached group layouts, merge, depth, and templates, and post-processing output formats.
- A binding model much like the Vulkan resource pool tools. To group resources into groups, the WebGPU provides a GPUBindGroup object that, while typing commands, can be linked to other objects of the same type for use in shaders. The creation of such groups allows the driver to take the necessary preparatory actions in advance, and the browser allows the browser to change resource bindings much faster between draw calls. The layout of resource links can be predefined using the GPUBindGroupLayout object.
Finally, if you are interested in knowing more about it about the note, you can check the detailsIt is in the following link.