A computer system with a user agent at the front-end and GPU at the back-end has components working on different timelines in parallel:

Content timeline
Associated with the execution of the Web script. It includes calling all methods described by this specification.
Steps executed on the content timeline look like this.

Device timeline
Associated with the GPU device operations that are issued by the user agent. It includes creation of adapters, devices, and GPU resources and state objects, which are typically synchronous operations from the point of view of the user agent part that controls the GPU, but can live in a separate OS process.
Steps executed on the device timeline look like this.

Queue timeline
Associated with the execution of operations on the compute units of the GPU. It includes actual draw, copy, and compute jobs that run on the GPU.
Steps executed on the queue timeline look like this.

一个前端有用户代理,后端有GPU的计算机系统的组件在不同的时间线上并行工作:

内容时间轴
与Web脚本的执行关联。它包括调用本规范描述的所有方法。
在内容时间轴上执行的步骤如下所示。

设备时间轴
与用户代理发出的GPU设备操作关联。它包括创建适配器、设备、GPU资源和状态对象,从控制GPU的用户代理部分的角度来看,这些通常是同步操作,并且可以存在于单独的操作系统进程中。
在设备时间轴上执行的步骤如下所示。

队列时间轴
与在GPU的计算单元上执行操作有关。它包括在GPU上运行的实际绘制、复制和计算作业。
在队列时间轴上执行的步骤如下所示。

In this specification, asynchronous operations are used when the result value depends on work that happens on any timeline other than the Content timeline. They are represented by callbacks and promises in JavaScript.

在本规范中,当结果值取决于除内容时间线以外的任何时间线上发生的工作时,将使用异步操作。它们由JavaScript中的回调和promises表示。

EXAMPLE 1
GPUComputePassEncoder.dispatch():

  1. User encodes a dispatch command by calling a method of the GPUComputePassEncoder which happens on the Content timeline.
  2. User issues GPUQueue.submit() that hands over the GPUCommandBuffer to the user agent, which processes it on the Device timeline by calling the OS driver to do a low-level submission.
  3. The submit gets dispatched by the GPU invocation scheduler onto the actual compute units for execution, which happens on the Queue timeline.
  1. 用户通过调用发生在内容时间轴上的GPUComputePassEncoder方法对调度命令进行编码。
  2. 用户发出GPUQueue.submit(),将GPUCommandBuffer移交给用户代理,用户代理通过调用操作系统驱动程序进行低级提交,在设备时间轴上对其进行处理。
  3. 提交由GPU调用调度器调度到实际的计算单元上执行,这发生在队列时间线上。

EXAMPLE 2
GPUDevice.createBuffer():

  1. User fills out a GPUBufferDescriptor and creates a GPUBuffer with it, which happens on the Content timeline.
  2. User agent creates a low-level buffer on the Device timeline.
  1. 用户填写一个GPUBufferDescriptor并用它创建一个GPUBuffer,这发生在内容时间轴上。
  2. 用户代理在设备时间轴上创建低级缓冲区。

EXAMPLE 3
GPUBuffer.mapAsync():

  1. User requests to map a GPUBuffer on the Content timeline and gets a promise in return.
  2. User agent checks if the buffer is currently used by the GPU and makes a reminder to itself to check back when this usage is over.
  3. After the GPU operating on Queue timeline is done using the buffer, the user agent maps it to memory and resolves the promise.
  1. 用户请求将GPUBuffer映射到内容时间轴上,并得到一个promise作为返回值。
  2. 用户代理检查缓冲区当前是否由GPU使用,并提醒自己在使用结束时检查。
  3. 在GPU使用缓冲区对队列时间轴进行操作之后,用户代理将其映射到内存并resolves the promise。

  • Y-axis is up in normalized device coordinate (NDC): point(-1.0, -1.0) in NDC is located at the bottom-left corner of NDC. In addition, x and y in NDC should be between -1.0 and 1.0 inclusive, while z in NDC should be between 0.0 and 1.0 inclusive. Vertices out of this range in NDC will not introduce any errors, but they will be clipped.

  • Y-axis is down in framebuffer coordinate, viewport coordinate and fragment/pixel coordinate: origin(0, 0) is located at the top-left corner in these coordinate systems.

  • Window/present coordinate matches framebuffer coordinate.

  • UV of origin(0, 0) in texture coordinate represents the first texel (the lowest byte) in texture memory.

  • Y轴在归一化设备坐标(NDC)中向上:NDC中的点(-1.0,-1.0)位于NDC的左下角。此外,NDC中的x和y应介于-1.0和1.0之间,而NDC中的z应介于0.0和1.0之间。NDC中超出此范围的顶点不会引入任何错误,但它们将被剪裁。

  • Y轴在帧缓冲区坐标、视口坐标和片段/像素坐标中向下:原点(0,0)位于这些坐标系的左上角。

  • 窗口/当前坐标与帧缓冲区坐标匹配。

  • 纹理坐标中的UV原点(0,0)表示纹理内存中的第一个texel(最低字节)。

Note: WebGPU’s coordinate systems match DirectX and Metal’s coordinate systems in a graphics pipeline.

注:WebGPU的坐标系在图形管道中与DirectX和Metal的坐标系匹配。

If an object is successfully created, it is valid at that moment. An internal object may be invalid. It may become invalid during its lifetime, but it will never become valid again.

如果成功创建了一个对象,则该对象此时有效。内部对象可能无效。它可能在其生命周期内失效,并且永远不会再次生效。

Invalid objects result from a number of situations, including:
 If there is an error in the creation of an object, it is immediately invalid. This can happen, for example, if the object descriptor doesn’t describe a valid object, or if there is not enough memory to allocate a resource.
 If an object is explicitly destroyed (e.g. GPUBuffer.destroy()), it becomes invalid.
 If the device that owns an object is lost, the object becomes invalid.

无效对象由多种情况造成,包括:
 如果在创建对象时出错,则该对象立即无效。例如,如果对象描述符没有描述有效的对象,或者没有足够的内存来分配资源,就会发生这种情况。
 如果对象被显式销毁(例如GPUBuffer.destroy()),则该对象将无效。
 如果拥有对象的设备丢失,该对象将无效。

To determine if a given GPUObjectBase object is valid to use with a targetObject, run the following steps:
 1.If any of the following conditions are unsatisfied return false:
  object is valid
  object.[[device]] is valid.
  object.[[device]] is targetObject.[[device]].
 2.Return true.

要确定给定的GPUObjectBase对象是否可与targetObject一起使用,请运行以下步骤:
 1.如果以下任一条件不满足,则返回false:
  对象是有效的
  object.[[device]]是有效的
  object.[[device]]是targetObject.[[device]].
 2.返回true.

3.1.1. Dot Syntax

In this specification, the . (“dot”) syntax, common in programming languages, is used. The phrasing “Foo.Bar” means “the Bar member of the value (or interface) Foo.”

在本规范中,使用编程语言中常见的(“点”)语法。短语”Foo.Bar”表示”对象(或接口)Foo的Bar成员”

The ?. (“optional chaining”) syntax, adopted from JavaScript, is also used. The phrasing “Foo?.Bar” means “if Foo is null or undefined, Foo; otherwise, Foo.Bar”.

采纳自JavaScript的”?.”语法同样被使用。”Foo?.Bar”表示”如果Foo为null或undefined,则为undefined;否则,Foo.Bar”。

For example, where buffer is a GPUBuffer, buffer?.[[device]].[[adapter]] means “if buffer is null or undefined, then undefined, otherwise, the [[adapter]] internal slot of the [[device]] internal slot of buffer.

例如,buffer是一个GPUBuffer对象,buffer?.[[device]].[[adapter]]表示”如果buffer为null或undefined,则为undefined,否则buffer的内部插槽[[device]]的内部插槽[[adapter]]”

3.1.2. Internal Objects

An internal object is a conceptual, non-exposed WebGPU object. Internal objects track the state of an API object and hold any underlying implementation. If the state of a particular internal object can change in parallel from multiple agents, those changes are always atomic with respect to all agents.

内部对象是概念性的、未公开的WebGPU对象。内部对象跟踪API对象的状态并保存任何底层实现。如果特定内部对象的状态可以从多个代理并行更改,那么这些更改对于所有代理来说都是原子性的。

Note: An “agent” refers to a JavaScript “thread” (i.e. main thread, or Web Worker).

注:”agent”是指JavaScript”线程”(即主线程或Web工作线程)。

3.1.3. WebGPU Interfaces

A WebGPU interface is an exposed interface which encapsulates an internal object. It provides the interface through which the internal object’s state is changed.

WebGPU接口是封装内部对象的公开接口。它提供用于更改内部对象状态的接口。

As a matter of convention, if a WebGPU interface is referred to as invalid, it means that the internal object it encapsulates is invalid.

按照惯例,如果WebGPU接口被援引为无效,则意味着它封装的内部对象无效。

Any interface which includes GPUObjectBase is a WebGPU interface.

任何包含GPUObjectBase的接口都是WebGPU接口。

1
2
3
interface mixin GPUObjectBase {
attribute USVString? label;
};

GPUObjectBase has the following attributes:

GPUObjectBase具有以下属性:

label, of type USVString, nullable
A label which can be used by development tools (such as error/warning messages, browser developer tools, or platform debugging utilities) to identify the underlying internal object to the developer. It has no specified format, and therefore cannot be reliably machine-parsed.

In any given situation, the user agent may or may not choose to use this label.

label, USVString类型,可为空
开发工具(如错误/警告消息、浏览器开发工具或平台调试实用程序)可以使用的标签,用于向开发人员标识底层内部对象。它没有指定的格式,因此无法可靠地进行机器分析。

在任何给定的情况下,用户代理都可能或可能不选择使用此标签。

GPUObjectBase has the following internal slots:

[[device]], of type device, readonly
An internal slot holding the device which owns the internal object.

[[device]], 类型device, 只读
一个内部插槽持有拥有内部对象的设备

3.1.4. Object Descriptors

An object descriptor holds the information needed to create an object, which is typically done via one of the create* methods of GPUDevice.

对象描述符保存创建对象所需的信息,这通常通过GPUDevice的create*方法之一完成。

1
2
3
dictionary GPUObjectDescriptorBase {
USVString label;
};

GPUObjectDescriptorBase has the following members:

label, of type USVString
The initial value of GPUObjectBase.label.

GPUObjectDescriptorBase有如下成员:

label, USVString类型
GPUObjectBase.label的初始值。

2.8.1. Machine-specific limits

WebGPU can expose a lot of detail on the underlying GPU architecture and the device geometry. This includes available physical adapters, many limits on the GPU and CPU resources that could be used (such as the maximum texture size), and any optional hardware-specific capabilities that are available.

WebGPU可以公开很多关于底层GPU架构和设备几何结构的细节。这包括可用的物理适配器、对可使用的GPU和CPU资源的许多限制(如最大纹理大小)以及任何可选的硬件特定功能。

User agents are not obligated to expose the real hardware limits, they are in full contol of how much the machine specifics are exposed. One strategy to reduce fingeprinting is binning all the target platforms into a few number of bins. In general, the privacy impact of exposing the hardware limits matches the one of WebGL.

用户代理没有义务公开真正的硬件限制,他们完全控制机器细节的公开程度。减少fingeprinting的一个策略是将所有目标平台放入几个箱子中。一般来说,公开硬件限制对隐私的影响与WebGL的影响相匹配。

The default limits are also deliberately high enough to allow most application to work without requesting higher limits. All the usage of the API is validated according to the requested limits, so the actual hardware capabilities are not exposed to the users by accident.

默认限制也有意设置得足够高,以允许大多数应用程序在不请求更高限制的情况下工作。API的所有使用都是根据请求的限制进行验证的,因此实际的硬件功能不会意外地暴露给用户。

2.8.2. Machine-specific artifacts

There are some machine-specific rasterization/precision artifacts and performance differences that can be observed roughly in the same way as in WebGL. This applies to rasterization coverage and patterns, interpolation precision of the varyings between shader stages, compute unit scheduling, and more aspects of execution.

存在一些特定于机器的光栅化/精度瑕疵和性能差异,其观察方式与WebGL大致相同。这适用于光栅化覆盖率和模式、着色器阶段之间变量的插值精度、计算单元调度以及执行的更多方面。

Generally, rasterization and precision fingerprints are identical across most or all of the devices of each vendor. Performance differences are relatively intractable, but also relatively low-signal (as with JS execution performance).

通常,每个供应商的大部分或所有设备上的光栅化和精确指纹都是相同的。性能差异比较棘手,但信号也相对较低(与JS执行性能一样)。

Privacy-critical applications and user agents should utilize software implementations to eliminate such artifacts.

隐私关键型应用程序和用户代理应利用软件实现消除此类组件。

2.8.3. Machine-specific performance

Another factor for differentiating users is measuring the performance of specific operations on the GPU. Even with low precision timing, repeated execution of an operation can show if the user’s machine is fast at specific workloads. This is a fairly common vector (present in both WebGL and Javascript), but it’s also low-signal and relatively intractable to truly normalize.

区分用户的另一个因素是衡量GPU上特定操作的性能。即使使用低精度计时,重复执行操作也可以显示用户的机器在特定工作负载下是否快速。这是一个相当常见的向量(存在于WebGL和Javascript中),但它也是一个低信号,要真正规范化它相对困难。

WebGPU compute pipelines expose access to GPU unobstructed by the fixed-function hardware. This poses an additional risk for unique device fingerprinting. User agents can take steps to dissociate logical GPU invocations with actual compute units to reduce this risk.

WebGPU计算管道公开对GPU的访问,不受固定功能硬件的阻碍。这给独特的设备指纹识别带来了额外的风险。用户代理可以采取步骤将逻辑GPU调用与实际计算单元分离,以降低这种风险。

2.8.4. User Agent State

This specification doesn’t define any additional user-agent state for an origin. However it is expected that user agents will have compilation caches for the result of expensive compilation like GPUShaderModule, GPURenderPipeline and GPUComputePipeline. These caches are important to improve the loading time of WebGPU applications after the first visit.

此规范没有为源定义任何其他用户代理状态。但是,预计用户代理将为昂贵的编译结果(如GPUShaderModule、GPURenderPipeline和GPUComputePipeline)提供编译缓存。这些缓存对于提高首次访问后WebGPU应用程序的加载时间非常重要。

For the specification, these caches are indifferentiable from incredibly fast compilation, but for applications it would be easy to measure how long createComputePipelineAsync() takes to resolve. This can leak information across origins (like “did the user access a site with this specific shader”) so user agents should follow the best practices in storage partitioning.

对于规范来说,这些缓存与异常快速的编译是不可区分的,但是对于应用程序来说,很容易测量createComputePipelineAsync()解析所需的时间。这可能会跨源泄漏信息(如“用户是否使用此特定着色器访问了站点”),因此用户代理应遵循存储分区中的最佳做法。

The system’s GPU driver may also have its own cache of compiled shaders and pipelines. User agents may want to disable these when at all possible, or add per-partition data to shaders in ways that will make the GPU driver consider them different.

系统的GPU驱动程序也可能有自己的编译着色器和管道缓存。用户代理可能想在所有可能的情况下禁用这些,或者将每个分区数据添加到着色器中,这将使GPU驱动程序认为它们是不同的。

WebGPU provides access to constrained global resources shared between different programs (and web pages) running on the same machine. An application can try to indirectly probe how constrained these global resources are, in order to reason about workloads performed by other open web pages, based on the patterns of usage of these shared resources. These issues are generally analogous to issues with Javascript, such as system memory and CPU execution throughput. WebGPU does not provide any additional mitigations for this.

WebGPU提供对在同一台计算机上运行的不同程序(和网页)之间共享的受限全局资源的访问。应用程序可以尝试间接探测这些全局资源的约束程度,以便根据这些共享资源的使用模式推断其他开放网页执行的工作负载。这些问题通常类似于Javascript的问题,例如系统内存和CPU执行吞吐量。WebGPU不为此提供任何其他缓解措施。

2.7.1. Memory resources

WebGPU exposes fallible allocations from machine-global memory heaps, such as VRAM. This allows for probing the size of the system’s remaining available memory (for a given heap type) by attempting to allocate and watching for allocation failures.

WebGPU暴露了来自硬件的全局内存堆(如VRAM)的易出错的分配。这允许通过尝试分配和观察分配失败来探测系统剩余可用内存的大小(对于给定堆类型)。

GPUs internally have one or more (typically only two) heaps of memory shared by all running applications. When a heap is depleted, WebGPU would fail to create a resource. This is observable, which may allow a malicious application to guess what heaps are used by other applications, and how much they allocate from them.

GPU内部有一个或多个(通常只有两个)由所有运行的应用程序共享的内存堆。当堆耗尽时,WebGPU将无法创建资源。这是可以观察到的,这可能允许恶意应用程序猜测其他应用程序使用了哪些堆,以及它们从中分配了多少。

2.7.2. Computation resources

If one site uses WebGPU at the same time as another, it may observe the increase in time it takes to process some work. For example, if a site constantly submits compute workloads and tracks completion of work on the queue, it may observe that something else also started using the GPU.

如果一个站点与其他页面同时使用WebGPU,它可能会观察到处理某些工作所需的时间增加。例如,如果站点不断提交计算工作负载并跟踪队列上的工作完成情况,那么它可能会发现其他东西也开始使用GPU。

A GPU has many parts that can be tested independently, such as the arithmetic units, texture sampling units, atomic units, etc. A malicious application may sense when some of these units are stressed, and attempt to guess the workload of another application by analyzing the stress patterns. This is analogous to the realities of CPU execution of Javascript.

GPU有许多可以独立测试的部分,如算术单元、纹理采样单元、原子单元等。恶意应用程序可能会感知其中一些单元何时受到压力,并试图通过分析压力模式来猜测另一个应用程序的工作负载。这类似于Javascript的CPU执行。

WebGPU applications have access to GPU memory and compute units. A WebGPU implementation may limit the available GPU memory to an application, in order to keep other applications responsive. For GPU processing time, a WebGPU implementation may set up “watchdog” timer that makes sure an application doesn’t cause GPU unresponsiveness for more than a few seconds. These measures are similar to those used in WebGL.

WebGPU应用程序可以访问显存和GPU计算单元。WebGPU实现可能会将可用GPU内存限制在应用程序上,以保持其他应用程序的响应性。对于GPU处理时间,WebGPU实现可能会设置”看门狗”计时器,以确保应用程序不会导致GPU不响应超过几秒钟。这些措施与WebGL中使用的措施类似。

When uploading floating-point data from CPU to GPU, or generating it on the GPU, we may end up with a binary representation that doesn’t correspond to a valid number, such as infinity or NaN (not-a-number). The GPU behavior in this case is subject to the accuracy of the GPU hardware implementation of the IEEE-754 standard. WebGPU guarantees that introducing invalid floating-point numbers would only affect the results of arithmetic computations and will not have other side effects.

当从CPU上传浮点数据到GPU,或在GPU上生成浮点数据时,我们可能会得到一个与有效数字不对应的二进制表示,例如无穷大或NaN(非数字)。这种情况下的GPU行为取决于GPU硬件实现的IEEE-754标准的准确性。WebGPU保证引入无效浮点数只会影响算术计算的结果,不会产生其他副作用。

2.5.1. Driver bugs

GPU drivers are subject to bugs like any other software. If a bug occurs, an attacker could possibly exploit the incorrect behavior of the driver to get access to unprivileged data. In order to reduce the risk, the WebGPU working group will coordinate with GPU vendors to integrate the WebGPU Conformance Test Suite (CTS) as part of their driver testing process, like it was done for WebGL. WebGPU implementations are expected to have workarounds for some of the discovered bugs, and disable WebGPU on drivers with known bugs that can’t be worked around.

GPU驱动程序和其他软件一样容易出现bug。如果出现bug,攻击者可能会利用驱动程序的错误行为来访问未经授权的数据。为了降低风险,WebGPU工作组将与GPU供应商协调,将WebGPU一致性测试套件(CTS)集成为其驱动程序测试过程的一部分,就像为WebGL所做的那样。WebGPU实现有望为一些发现的bug提供解决方案,并在存在无法解决的已知bug的驱动程序上禁用WebGPU。

2.5.2. Timing attacks

WebGPU is designed for multi-threaded use via Web Workers. As such, it is designed not to open the users to modern high-precision timing attacks. Some of the objects, like GPUBuffer or GPUQueue, have shared state which can be simultaneously accessed. This allows race conditions to occur, similar to those of accessing a SharedArrayBuffer from multiple Web Workers, which makes the thread scheduling observable.

WebGPU设计用于通过Web Workers进行多线程使用。因此,它的设计不会让用户受到现代高精度定时攻击。一些对象(如GPUBuffer或GPUQueue)具有可同时访问的共享状态。这允许出现竞争条件,类似于从多个Web Workers访问SharedArrayBuffer的情况,这使得线程调度可以观察到。

WebGPU addresses this by limiting the ability to deserialize (or share) objects only to the agents inside the agent cluster, and only if the cross-origin isolated policies are in place. This restriction matches the mitigations against the malicious SharedArrayBuffer use. Similarly, the user agent may also serialize the agents sharing any handles to prevent any concurrency entirely.

WebGPU通过将对象反序列化(或共享)的能力仅限于代理集群内的代理,并且仅当跨源隔离策略已就位时,解决此问题。此限制与针对恶意SharedArrayBuffer使用的缓解措施相匹配。类似地,用户代理还可以序列化共享任何句柄的代理,以完全防止任何并发。

In the end, the attack surface for races on shared state in WebGPU will be a small subset of the SharedArrayBuffer attacks.

最后,WebGPU中共享状态上的竞争攻击面将是SharedArrayBuffer攻击的一小部分。

WebGPU also specifies the “timestamp-query” feature, which provides high precision timing of GPU operations. The feature is optional, and a WebGPU implementation may limit its exposure only to those scenarios that are trusted. Alternatively, the timing query results could be processed by a compute shader and aligned to a lower precision.

WebGPU还指定”timestamp-query”功能,该功能提供GPU操作的高精度计时。该功能是可选的,WebGPU实现可能仅将其暴露限制在那些受信任的场景中。或者,计时查询结果可以由计算着色器处理,并以较低的精度对齐。

2.5.3. Row hammer attacks

Row hammer is a class of attacks that exploit the leaking of states in DRAM cells. It could be used on GPU. WebGPU does not have any specific mitigations in place, and relies on platform-level solutions, such as reduced memory refresh intervals.

Row-hammer是一类利用DRAM单元中状态泄漏的攻击。它可以在GPU上使用。WebGPU没有任何具体的缓解措施,依赖于平台级解决方案,如缩短内存刷新间隔。

Shaders can access physical resources either directly (for example, as a “uniform” GPUBufferBinding), or via texture units, which are fixed-function hardware blocks that handle texture coordinate conversions. Validation on the API side can only guarantee that all the inputs to the shader are provided and they have the correct usage and types. The host API side can not guarantee that the data is accessed within bounds if the texture units are not involved.

着色器可以直接访问物理资源(例如,作为”uniform”GPUBufferBinding),也可以通过纹理单元访问物理资源,纹理单元是处理纹理坐标转换的固定功能硬件块。API端的验证只能保证提供了着色器的所有输入,并且它们具有正确的用法和类型。如果涉及纹理单元,则宿主API端无法保证在边界内访问数据。

In order to prevent the shaders from accessing GPU memory an application doesn’t own, the WebGPU implementation may enable a special mode (called “robust buffer access”) in the driver that guarantees that the access is limited to buffer bounds.

为了防止着色器访问应用程序不拥有的GPU内存,WebGPU实现可以在驱动程序中启用一种特殊模式(称为”robust buffer access”),以确保访问仅限于缓冲区边界内。

Alternatively, an implementation may transform the shader code by inserting manual bounds checks. When this path is taken, the out-of-bound checks only apply to array indexing. They aren’t needed for plain field access of shader structures due to the minBindingSize validation on the host side.

或者,WebGPU实现可以通过手动插入边界检查来变换着色器代码。采用此方法时,越界检查仅适用于数组索引。由于主机端的minBindingSize验证,访问着色器结构的普通字段不需要它们。

If the shader attempts to load data outside of physical resource bounds, the implementation is allowed to:
1.return a value at a different location within the resource bounds
2.return a value vector of “(0, 0, 0, X)” with any “X”
3.partially discard the draw or dispatch call

如果着色器尝试加载物理资源边界之外的数据,则允许WebGPU实现:
1.在资源范围内的不同位置返回值
2.返回带有任意”X”的(0,0,0,X)向量
3.部分放弃the draw or dispatch call

If the shader attempts to write data outside of physical resource bounds, the implementation is allowed to:
1.write the value to a different location within the resource bounds
2.discard the write operation
3.partially discard the draw or dispatch call

如果着色器尝试写入物理资源边界之外的数据,则允许WebGPU实现:
1.将值写入资源边界内的其他位置
2.放弃写入操作
3.部分放弃the draw or dispatch call

Generally, allocating new memory may expose the leftover data of other applications running on the system. In order to address that, WebGPU conceptually initializes all the resources to zero, although in practice an implementation may skip this step if it sees the developer initializing the contents manually. This includes variables and shared workgroup memory inside shaders.

通常,分配新内存可能会暴露系统上运行的其他应用程序的剩余数据。为了解决这一问题,WebGPU在概念上将所有资源初始化为零,尽管在实践中,如果看到开发人员手动初始化内容,则实现可能会跳过此步骤。这包括着色器中的变量和共享工作组内存。

The precise mechanism of clearing the workgroup memory can differ between platforms. If the native API does not provide facilities to clear it, the WebGPU implementation transforms the compute shader to first do a clear across all invocations, synchronize them, and continue executing developer’s code.

精确清除工作组内存的机制可能因平台而异。如果本机API不提供清除功能,WebGPU实现会将计算着色器转换为首先在所有调用中执行清除,同步它们,然后继续执行开发人员的代码。