WebGL and WebGPU

Graphics card needs to be installedGraphics driverProgram, through the API exposed by the graphics card driver, we can operate the GPU to complete the operation of the graphics processor. The problem is that the graphics card driver is the same as the assembly in the ordinary programming world. It is difficult to write at the bottom, so major manufacturers have packaged it. thenOpenGLIt came into being, responsible for the upper interface packaging and dealing with the lower graphics card driver, but as we all know, its design style can no longer keep up with the characteristics of modern GPUs.

OpenGL technology was proposed in the 1990s, and WebGL was made based on OpenGL ES. OpenGL played its due value in that era of weak graphics cards.

Microsoft has created the latest graphics API for this purpose. It is Direct3D. Apple has created the latest graphics API for this purpose. It is Metal. There is a famous organization, Khronos, and Vulkan. These are the three modern graphics APIs.

OpenGL was left to Khronos in 2006, and now all operating systems have basically not installed this very old graphics driver. So, why can WebGL based on OpenGL ES run in browsers of various operating systems? Because WebGL is no longer OpenGL ES,WindowsThe above is now translated to graphics driver through D3D, and on macOS it is Metal, but the closer the time is, the more difficult it is to implement this non-son-style. Apple's Safari browser has only supported WebGL 2.0 in recent years, and has abandoned the GPGPU feature in OpenGL ES. Perhaps the GPGPU of WebGL 2.0 may not be implemented on Safari.

The next generation of Web graphics interfaces are no longer GL, not called WebGL 3.0, but are closerhardwareNamed WebGPU. WebGPU is not of the same era as WebGL in terms of roots, both in terms of coding style and performance.

WebGL's coding style

WebGL's programming style continues the OpenGL's style. Students who have studied WebGL interface should have used it:glvariable, i.e.WebGLRenderingContextObject, WebGL 2.0 isWebGLRenderingContext2。

Here is a sample code for creating vertex and fragment shaders:

The order of creating shaders, assigning shader codes, and compiling these is relatively fixed.

Every callgl methodWhen the CPU to the GPU is transmitted, the status of the GPU will be changed. Therefore, the efficiency of this process is below.

The three modern graphics APIs tend to prepare things first, and finally submit them to the GPU is a complete design drawing and buffered data. The GPU only needs to hold it to focus on doing things.

Prefabricated coding style of WebGPU

Although WebGPU also has an object like the general manager - device, the type isGPUDevice, represents a high-level abstraction that can operate GPU devices. It is responsible for creating various objects that operate graphical operations, and finally assemble into an object called "CommandBuffer (GPUCommandBuffer)" and submitting it toqueue, this is how the CPU labor is completed.

Therefore, when creating objects in the process, the GPU will not immediately notify the GPU to complete the state change like WebGL. Instead, the code written on the CPU side ensures that the things passed to the GPU later are accurate in terms of logic and type, and lets them stand in their own pit and wait for submission to the GPU at any time.

Here, the instruction buffer object has complete data (geometry, texture, shaders, pipeline scheduling logic, etc.), and the GPU knows what to do as soon as it gets it.

WebGL's gl variables rely on the HTML's Canvas element and can only schedule the GPU on the main thread. WebWorker in WebGL can only process data and cannot operate the GPU.

In WebGPUadapterRelying onObjects can also be accessed in WebWorker, so devices can be created and instruction buffers can be assembled in Worker, thereby realizing multi-threaded instruction buffering and realizing the ability of multi-threaded GPUs on the CPU side.

const adapter = await ();
if (!adapter) {
  return
}
const device = await ()
// Get a GPU buffer in a mapped state and an arrayBuffer for writing
const buffer = ({
  mappedAtCreation: true,
  size: 4,
  usage: GPUBufferUsage.MAP_WRITE
})
const arrayBuffer = ();
// Write bytes to buffer.
new Uint8Array(arrayBuffer).set([0, 1, 2, 3]);
 
const texture = ({
  /* Assembly texture and sampling information*/
})
 
const pipelineLayout = ({
  /* Create pipeline layout, pass the binding group layout object */
})
 
/* Create shader module */
const vertexShaderModule = ({ /* ... */ })
const fragmentShaderModule = ({ /* ... */ })
 
/*
 Calculate the shader modules that may be used in shaders
 const computeShaderModule = ({ /* ... * / })
 */
 
const bindGroupLayout = ({
  /* Create a layout object for the binding group */
})
 
const pipelineLayout = ({
  /* Passing the binding group layout object*/
})
 
/*
 The above two layout objects can actually be lazy and not created. Although the binding group needs to be bound to the group layout,
 Notify the corresponding pipeline stage of the binding group's resources look like, but the binding group layout can be
 The pipeline object is deduced by itself through the code in the programmable stage.
 This sample code saves the complete process
 */
 
const pipeline = ({
  /*
 Create a pipeline
   Specify the materials required for each stage of the pipeline
 There are three stages in which shaders can be passed to achieve programmability, namely vertices, fragments, and calculations
 Each stage can also specify the data and information it needs, such as buffer, etc.
   
 In addition, the pipeline also needs a pipeline layout object, and its built-in binding group layout object can
 Let the shader know what the binding group resource will look like in the channel afterwards
 */
})
 
const bindGroup_0 = ({
  /*
 Group resources, group buffer and texture into logical groups.
 Convenient to call each process, the process is pipeline.
 Here, the binding group layout object must be passed, which can be inferred from the pipeline, or it can be directly passed on the binding group layout object itself.
 */
})
 
const commandEncoder = () // Create an instruction buffer encoder objectconst renderPassEncoder = () // Start a rendering channel encoder// A computing channel can also be started// const computePassEncoder = ({ /* ... */ })
 
/*
 Taking the rendering channel as an example, use renderPassEncoder to complete the order setting of what to do in this channel, for example
 */
 
// The first drawing is set, pipeline 0, binding group 0, binding group 1, vbo, and trigger drawing(renderPipeline_0)
(0, bindGroup_0)
(1, bindGroup_1)
(0, vbo, 0, size)
(vertexCount)
 
// The second drawing, set pipeline 1, another binding group and trigger drawing(renderPipeline_1)
(1, another_bindGroup)
(vertexCount)
 
// End channel encoding()
 
// Finally submit to queue, that is, commandEncoder calls finish to complete the encoding, returning a command buffer ([  ()
])
and

Summary of WebGPU Advantages

WebGPU is a new web standard designed to provide web developers with more efficient, flexible and modern graphics programming interfaces. WebGPU has the following advantages:

1. More efficient: WebGPU uses GPU to accelerate graphics processing, thus providing a higher level of experience than traditional Web graphics APIsperformance。

2. More flexible: WebGPUs provide a more flexible programming model that allows developers to more easily control GPU operations and better take advantage of GPU parallelism.

3. More modern: WebGPUs take advantage of the capabilities of modern GPUs, including features such as asynchronous computing, texture compression and shader modularity, making it an ideal choice for developing more modern web applications.

4. Cross-platform: WebGPU is a cross-platform standard that can run on any device that supports WebGPU, including desktop browsers, mobile devices, and VR/AR head-mounted displays.

5. Integration with the web: WebGPU is designed for web development, so it can seamlessly integrate with other web technologies including WebGL, WebVR, and WebXR.

What are the advantages of WebGPU over WebGL

WebGPU and WebGL are two different Web graphics APIs that have the following advantages:

• Performance: WebGPUs can better utilize hardware acceleration and therefore provide higher graphics performance, especially when processing large amounts of data. By contrast, WebGL has lower performance.

• Features: WebGPU provides more features and flexibility, such as support for advanced rendering technologies such as computing shaders and anti-aliasing. WebGL has relatively few features and is limited by the old OpenGL ES standard.

• Design: WebGPU is designed based on modern graphics APIs, which is more scalable and maintainable, while WebGL is designed based on the earlier OpenGL ES standard.

Overall, WebGPU is more suitable for scenarios that require high performance and advanced rendering technology, while WebGL is more suitable for some simple 2D or 3D rendering needs.

What are the differences between WebGPU and WebAssembly

WebGPU and WebAssembly are two different technologies, with the main differences as follows:

1. WebGPU is a new API for high-performance graphics rendering in a web browser, and WebAssembly is a bytecode format for running high-performance computing-intensive applications in a web browser.

2. WebGPUs are designed to provide better performance and efficiency than existing Web graphics APIs, while WebAssembly is designed to provide better performance and efficiency thanJavaScriptFaster execution speeds and better portability and security.

3. WebGPU requires hardware support and can only be used in browsers that support WebGPUs, while WebAssembly can be used in any web browser that supports it.

4. Although both WebGPU and WebAssembly offer some new features and advantages, they are not mutually exclusive and in fact, they can be used together to enable more efficient and flexible web applications.