WebGL 计算着色器调度优化：工作组大小调整

WebGL 的强大功能——计算着色器，允许开发者直接在网页浏览器中利用 GPU 的海量并行处理能力进行通用计算 (GPGPU)。这为加速各种任务提供了机会，从图像处理、物理模拟到数据分析和机器学习。然而，要想通过计算着色器获得最佳性能，关键在于理解并仔细调整 工作组大小，这是一个决定计算如何在 GPU 上划分和执行的关键参数。

理解计算着色器和工作组

在深入探讨优化技术之前，让我们先建立一个清晰的基础理解：

• 计算着色器 (Compute Shaders): 这些是用 GLSL (OpenGL 着色语言) 编写并在 GPU 上直接运行的程序。与传统的顶点或片元着色器不同，计算着色器不与渲染管线绑定，可以执行任意计算。
• 调度 (Dispatch): 启动计算着色器的过程称为调度。gl.dispatchCompute(x, y, z) 函数指定将执行该着色器的 工作组 的总数。这三个参数定义了调度网格的维度。
• 工作组 (Workgroup): 工作组是由在 GPU 的单个处理单元上并行执行的 工作项 (也称为线程) 组成的集合。工作组提供了一种在组内共享数据和同步操作的机制。
• 工作项 (Work Item): 工作组内计算着色器的单个执行实例。每个工作项在其工作组内都有一个唯一的 ID，可以通过内置 GLSL 变量 gl_LocalInvocationID 访问。
• 全局调用 ID (Global Invocation ID): 跨整个调度的每个工作项的唯一标识符。它是 gl_GlobalInvocationID (整体 ID) 和 gl_LocalInvocationID (工作组内 ID) 的组合。

这些概念之间的关系可以总结为：一次调度启动一个工作组网格，每个工作组包含多个工作项。计算着色器代码定义了每个工作项执行的操作，GPU 则并行执行这些操作，利用其多个处理核心的强大功能。

示例： 想象一下使用计算着色器对一张大图像应用滤镜。您可能会将图像划分为多个图块，每个图块对应一个工作组。在每个工作组内，单独的工作项可以处理图块内的单个像素。gl_LocalInvocationID 将代表像素在图块内的位置，而调度大小将决定处理的图块（工作组）数量。

工作组大小调整的重要性

工作组大小的选择对计算着色器的性能有着深远的影响。配置不当的工作组大小可能导致：

• GPU 利用率不佳： 如果工作组太小，GPU 的处理单元可能会被低估，导致整体性能下降。
• 开销增加： 极大的工作组可能由于资源争用和同步成本的增加而引入开销。
• 内存访问瓶颈： 工作组内低效的内存访问模式可能导致内存访问瓶颈，从而减慢计算速度。
• 性能波动： 如果工作组大小选择不当，不同 GPU 和驱动程序之间的性能差异会很大。

因此，找到最佳工作组大小对于最大化 WebGL 计算着色器的性能至关重要。此最佳大小依赖于硬件和工作负载，因此需要进行实验。

影响工作组大小的因素

有几个因素会影响给定计算着色器的最佳工作组大小：

• GPU 架构： 不同的 GPU 具有不同的架构，包括不同数量的处理单元、内存带宽和缓存大小。最佳工作组大小通常在不同 GPU 供应商（例如 AMD、NVIDIA、Intel）和型号之间有所不同。
• 着色器复杂性： 计算着色器代码本身的复杂性会影响最佳工作组大小。更复杂的着色器可能受益于更大的工作组，以更好地隐藏内存延迟。
• 内存访问模式： 计算着色器访问内存的方式起着重要作用。聚合内存访问模式（工作组内的工项访问连续内存位置）通常会带来更好的性能。
• 数据依赖性： 如果工作组内的工项需要共享数据或同步其操作，这可能会引入影响最佳工作组大小的开销。过度的同步可能使较小的工作组表现更好。
• WebGL 限制： WebGL 对最大工作组大小有限制。您可以使用 gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE)、gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_INVOCATIONS) 和 gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_COUNT) 查询这些限制。

工作组大小调整策略

考虑到这些因素的复杂性，采用系统化的工作组大小调整方法至关重要。以下是一些您可以采用的策略：

1. 从基准测试开始

任何优化工作的基石都是基准测试。您需要一种可靠的方法来衡量计算着色器在不同工作组大小下的性能。这需要创建一个测试环境，您可以在其中使用不同的工作组大小多次运行计算着色器并测量执行时间。一种简单的方法是使用 performance.now() 在 gl.dispatchCompute() 调用之前和之后测量时间。

示例：

const workgroupSizeX = 8;
const workgroupSizeY = 8;
const workgroupSizeZ = 1;

glt.useProgram(computeProgram);
// 设置 uniform 和纹理

glt.dispatchCompute(width / workgroupSizeX, height / workgroupSizeY, 1);
glt.memoryBarrier(gl.SHADER_STORAGE_BARRIER_BIT);
glt.finish(); // 在计时前确保完成

const startTime = performance.now();

for (let i = 0; i < numIterations; ++i) {
    gl.dispatchCompute(width / workgroupSizeX, height / workgroupSizeY, 1);
    gl.memoryBarrier(gl.SHADER_STORAGE_BARRIER_BIT); // 确保写入可见
    gl.finish();
}

const endTime = performance.now();
const elapsedTime = (endTime - startTime) / numIterations;
console.log(`Workgroup size (${workgroupSizeX}, ${workgroupSizeY}, ${workgroupSizeZ}): ${elapsedTime.toFixed(2)} ms`);

基准测试的关键注意事项：

• 预热 (Warm-up): 在开始测量之前将计算着色器运行几次，以允许 GPU 预热并避免初始性能波动。
• 多次迭代： 多次运行计算着色器并平均执行时间，以减少噪声和测量误差的影响。
• 同步： 使用 gl.memoryBarrier() 和 gl.finish() 来确保计算着色器已完成执行并且所有内存写入在测量执行时间之前可见。没有这些，报告的时间可能无法准确反映实际的计算时间。
• 可重现性： 确保基准测试环境在不同运行之间保持一致，以最大限度地减少结果的变异性。

2. 系统地探索工作组大小

一旦有了基准测试设置，您就可以开始探索不同的工作组大小。一个好的起点是尝试工作组每个维度的 2 的幂（例如，1、2、4、8、16、32、64……）。同样重要的是要考虑 WebGL 施加的限制。

示例：

const maxWidthgroupSize = gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE)[0];
const maxHeightgroupSize = gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE)[1];
const maxZWorkgroupSize = gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE)[2];

for (let x = 1; x <= maxWidthgroupSize; x *= 2) {
    for (let y = 1; y <= maxHeightgroupSize; y *= 2) {
        for (let z = 1; z <= maxZWorkgroupSize; z *= 2) {
            if (x * y * z <= gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_INVOCATIONS)) {
              //将 x, y, z 设置为您的工作组大小并进行基准测试。
            }
        }
    }
}

考虑这些要点：

• 本地内存使用： 如果您的计算着色器使用大量本地内存（工作组内的共享内存），您可能需要减小工作组大小以避免超出可用本地内存。
• 工作负载特征： 您的工作负载的性质也会影响最佳工作组大小。例如，如果您的工作负载涉及大量的分支或条件执行，较小的工作组可能更有效。
• 总工作项数： 确保总工作项数（gl.dispatchCompute(x, y, z) * workgroupSizeX * workgroupSizeY * workgroupSizeZ）足以充分利用 GPU。调度的工作项太少可能导致利用率不足。

3. 分析内存访问模式

如前所述，内存访问模式在性能中起着至关重要的作用。理想情况下，工作组内的工项应访问连续的内存位置，以最大限度地提高内存带宽。这被称为聚合内存访问。

示例：

考虑处理 2D 图像的场景。如果每个工项负责处理单个像素，那么以 2D 网格（例如 8x8）排列并且按行主序访问像素的工作组将表现出聚合内存访问。相比之下，按列主序访问像素将导致跨步内存访问，效率较低。

改进内存访问的技术：

• 重新排列数据结构： 重新组织您的数据结构以促进聚合内存访问。
• 使用本地内存： 将数据复制到本地内存（工作组内的共享内存）并在本地副本上执行计算。这可以显著减少全局内存访问次数。
• 优化跨步： 如果跨步内存访问不可避免，请尝试最小化跨步。

4. 最小化同步开销

同步机制，例如 barrier() 和原子操作，对于协调工作组内工项的操作是必需的。然而，过度的同步会引入显著的开销并降低性能。

减少同步开销的技术：

• 减少依赖性： 重构您的计算着色器代码以最小化工项之间的数据依赖性。
• 使用波形级操作： 某些 GPU 支持波形级操作（也称为子组操作），它允许波形（硬件定义的工项组）内的工项在没有显式同步的情况下共享数据。
• 谨慎使用原子操作： 原子操作提供了一种对共享内存执行原子更新的方法。然而，它们可能很昂贵，尤其是在争用同一内存位置时。考虑替代方法，例如使用本地内存累积结果，然后在工作组结束时执行一次原子更新。

5. 自适应工作组大小调整

最佳工作组大小可能因输入数据和当前 GPU 负载而异。在某些情况下，根据这些因素动态调整工作组大小可能是有益的。这被称为自适应工作组大小调整。

示例：

如果您正在处理不同大小的图像，您可以调整工作组大小以确保派发的工作组数量与图像大小成正比。或者，您可以监控 GPU 负载，并在 GPU 已重载时减小工作组大小。

实现考虑：

• 开销： 自适应工作组大小调整会引入开销，因为需要测量性能并动态调整工作组大小。必须权衡此开销与潜在的性能提升。
• 启发式方法： 用于调整工作组大小的启发式方法的选择会显着影响性能。需要仔细的实验才能为您的特定工作负载找到最佳的启发式方法。

实践示例和案例研究

让我们通过一些实际示例，看看工作组大小调整如何在现实场景中影响性能：

示例 1：图像过滤

考虑一个对图像应用模糊滤镜的计算着色器。朴素的方法可能涉及使用小工作组大小（例如 1x1），并让每个工项处理单个像素。然而，由于缺乏聚合内存访问，这种方法效率非常低下。

通过将工作组大小增加到 8x8 或 16x16，并将工作组排列在与图像像素对齐的 2D 网格中，我们可以实现聚合内存访问并显著提高性能。此外，将相关像素邻域复制到共享本地内存可以加快过滤操作，减少冗余的全局内存访问。

示例 2：粒子模拟

在粒子模拟中，计算着色器通常用于更新每个粒子的位置和速度。最佳工作组大小将取决于粒子数量和更新逻辑的复杂性。如果更新逻辑相对简单，则可以使用较大的工作组大小来并行处理更多粒子。但是，如果更新逻辑涉及大量分支或条件执行，则较小的工作组可能更有效。

此外，如果粒子之间发生交互（例如，通过碰撞检测或力场），则可能需要同步机制来确保粒子更新正确执行。在选择工作组大小时，必须考虑这些同步机制的开销。

案例研究：优化 WebGL 光线追踪器

柏林的一个团队一直在开发一个基于 WebGL 的光线追踪器，起初性能不佳。他们渲染管线核心严重依赖于一个计算着色器，该着色器根据光线相交计算每个像素的颜色。在剖析后，他们发现工作组大小是一个重大的瓶颈。他们从 (4, 4, 1) 的工作组大小开始，这导致了许多小工作组和 GPU 资源利用不足。

然后，他们系统地尝试了不同的工作组大小。他们发现在 NVIDIA GPU 上，(8, 8, 1) 的工作组大小显著提高了性能，但在某些 AMD GPU 上却因超出本地内存限制而导致问题。为了解决这个问题，他们实施了基于检测到的 GPU 供应商的工作组大小选择。最终的实现对 NVIDIA 使用 (8, 8, 1)，对 AMD 使用 (4, 4, 1)。他们还优化了光线-对象相交测试以及工作组中的共享内存使用，这有助于使光线追踪器在浏览器中可用。这极大地缩短了渲染时间，并使不同 GPU 型号之间的渲染时间更加一致。

最佳实践和建议

以下是 WebGL 计算着色器工作组大小调整的一些最佳实践和建议：

• 从基准测试开始： 始终从创建基准测试设置开始，以衡量计算着色器在不同工作组大小下的性能。
• 了解 WebGL 限制： 注意 WebGL 对最大工作组大小以及可以调度的总工作项数的限制。
• 考虑 GPU 架构： 在选择工作组大小时，请考虑目标 GPU 的架构。
• 分析内存访问模式： 争取实现聚合内存访问模式，以最大限度地提高内存带宽。
• 最小化同步开销： 减少工项之间的数据依赖性，以尽量减少同步的需要。
• 明智地使用本地内存： 使用本地内存来减少全局内存访问次数。
• 系统地进行实验： 系统地探索不同的工作组大小，并衡量它们对性能的影响。
• 剖析您的代码： 使用剖析工具来识别性能瓶颈并优化您的计算着色器代码。
• 在多种设备上进行测试： 在各种设备上测试您的计算着色器，以确保它在不同 GPU 和驱动程序上都能获得良好性能。
• 考虑自适应调整： 探索根据输入数据和 GPU 负载动态调整工作组大小的可能性。
• 记录您的发现： 记录您测试过的工作组大小以及您获得的性能结果。这将帮助您在未来就工作组大小调整做出明智的决策。

结论

工作组大小调整是优化 WebGL 计算着色器以获得高性能的关键方面。通过理解影响最佳工作组大小的因素并采用系统的调整方法，您可以释放 GPU 的全部潜力，并为您的计算密集型 Web 应用程序实现显著的性能提升。

请记住，最佳工作组大小高度依赖于具体的工作负载、目标 GPU 架构以及计算着色器的内存访问模式。因此，仔细的实验和剖析对于找到应用程序的最佳工作组大小至关重要。遵循本文概述的最佳实践和建议，您可以最大限度地提高 WebGL 计算着色器的性能，并提供更流畅、响应更快的用户体验。

当您继续探索 WebGL 计算着色器的世界时，请记住此处讨论的技术不仅仅是理论概念。它们是您可以用来解决实际问题并创建创新 Web 应用程序的实用工具。所以，深入研究，进行实验，发现优化计算着色器的强大功能！