计算机图形学：Compute Shader并行计算

可视化演示

展示GPU线程组Dispatch网格调度、共享内存同步波传播与CPU-GPU并行性能对比，切换模式观察计算管线。

GPU并行架构

普通工作日的餐厅只有主厨一人掌勺，菜要一道一道排队做，味道精细但速度有限。可一旦接下一场三百桌的婚宴，餐厅就会临时拉来一整支帮厨军团：每个帮厨只学几招固定手法，切葱的只切葱、颠勺的只颠勺，数量却高达几千人。这台“后厨”就是 GPU——它牺牲了单个核心的复杂能力，换来了海量简单执行单元同时开工的恐怖吞吐。

CPU 是那位全能主厨：核心少但单个核心极强，擅长处理带大量分支和依赖的串行任务；GPU 则相反，成千上万个简单核心组成“帮厨军团”，最适合把同一种运算施加到海量数据上。Compute Shader 就是主厨写给帮厨军团的工作单——它不是一门新语言，而是跑在 GPU 上的一段小程序（kernel）。主厨只需把工作单写好，然后一次性派发出去，接下来几万个线程同时开工。

每次派发叫一次 Dispatch。工作单上要写清两组数字：每个“灶台小组”有多少人，以及整个后厨分成多少排多少列小组。GPU 会根据这些参数批量生成线程，每个线程负责处理数据中的一小块。

主厨只写一张工作单，剩下的交给硬件调度器去排班。理解了这个“一纸派发、万人上工”的模型，你就抓住了 Compute Shader 的第一根主线——只要数据能被切成独立的小块，就能交给帮厨军团并行处理。

数据并行原理

婚宴的菜单只有一张，三百位帮厨却要同时照着这张菜单做三百份同款菜——每个人用同样的手法处理自己手里的食材。这就是“数据并行”：指令只有一份，数据却有千千万万份。Compute Shader 的核心思想正是如此，它不关心控制流的复杂度，只关心能否把同样的运算一口气铺到海量数据上。

GPU 执行指令的方式叫 SIMT（单指令多线程）：硬件把线程按 32 个一组编成“束”（warp / wavefront），同一束里的线程必须锁步前进——所有人同时执行同一条指令，只不过各自操作自己的数据。就像一队列队行进的帮厨，领队喊“翻勺”，32 个人同时翻自己面前的锅。

这带来两个关键推论。第一，调度单元是“束”而不是单个线程，一个束里的线程频繁出现分歧是要付出代价的（后面会细讲）。第二，为了让每个线程快速拿到数据，GPU 设计了鲜明的内存层级：寄存器像厨师口袋里的调料，速度最快；共享内存像灶台边的公共操作台，组内可见；全局显存则是后厨的大冷库，容量最大但往返一次要等几十上百个周期。一个线程束占用的执行周期数，取决于总线程数被束宽分成几波。

一张菜谱千人同做，靠的是把数据摊开、让每个线程各管一份。理解“锁步”和“波次”这两个词，你就明白了为什么 GPU 的并行和 CPU 的多线程有着本质区别——它更像是整齐划一的列队操练，而不是各自为战的自由发挥。

线程组与共享

后厨不是所有人围着一口锅转，而是按灶台分成小组：一组四到八人共享一张操作台，切好的葱姜蒜随手就能递过去。Compute Shader 里的“线程组”（thread group）就是这个灶台小组。组内的线程可以用一种极快的“共享内存”（shared memory）互相传数据，相当于公共操作台；而组与组之间没有操作台可用，只能通过慢得多的全局显存（大冷库）交流。

在 HLSL 中，线程组由 numthreads(x, y, z) 声明，一次 Dispatch 会生成若干个这样的组。为了帮程序员认清自己“站在哪里”，系统提供了一组语义变量：SV_GroupID 告诉你这是第几组，SV_GroupThreadID 告诉你组内是第几个线程，SV_DispatchThreadID 则是全局唯一的线程编号，SV_GroupIndex 是组内线性索引。它们就像工牌上的“组号 + 工位号”，帮你在海量线程中定位自己该处理哪份数据。

同一个组的线程之间要协同时，还需要一道“屏障”：GroupMemoryBarrierWithSync() 会拦住所有线程，直到本组每个人都把数据写进共享内存后才放行。这好比帮厨们必须先放下手里的刀，确认所有人的配菜都上了操作台，才能开始下一道工序——否则有人还在切菜就开始炒，菜就乱了。全局线程编号与组内位置的关系，是写任何 kernel 都要用到的“坐标换算”。

组内协作靠操作台，跨组通信只能走冷库通道。所以写 Compute Shader 时要尽量把需要频繁交换数据的线程放在同一个组里——让帮厨们伸长手就能递到配料，而不是每次都要跑去大冷库拿一趟。

性能优化

灶台的数量是固定的，能不能让每个灶台都有人在炒菜，直接决定了整场宴会的上菜速度。GPU 里衡量这个指标的名词叫“占用率”（occupancy）：它表示一个流式多处理器（SM，相当于一块灶台区）上，当前真正在运行的线程束数量占硬件能容纳的最大线程束数量的比例。占用率越高，意味着越少的灶台在空烧。

但想让灶台全忙并不容易。每个线程组都会占用三类“灶台资源”：寄存器（每人手里的调料罐）、共享内存（组内操作台面积）、线程槽位。如果每个线程消耗的寄存器太多，或者共享内存申请得太大，硬件能同时驻留的线程组就会变少，占用率随之下降。这就好比给帮厨每人发了一百个调料罐，操作台全被罐子占满，后来的小组根本挤不进来。

此外还要注意负载均衡和指令优化：派发线程组数量最好能被数据量整除，避免最后一组只有几个人干活而大部分人排队闲着；在 shader 里多用乘加指令（FMA）代替除法、用移位代替整数乘除，也能减少每条指令的耗时。占用率不是越高越好，但要先算清楚它，才知道瓶颈在哪。

占用率像一张体检报告：灶台空得多，说明资源没喂饱；灶台全忙但速度仍慢，说明瓶颈可能在冷库带宽而不是灶台。学会算这笔账，你就从“会写 shader”进阶到了“会调 shader”。

分支与合并

请再想象那队列队进发的帮厨：领队喊“如果食材是鱼就蒸，否则就炸”。麻烦来了——同一个线程束里的 32 个人，有人拿到鱼、有人拿到鸡，但硬件只能让全束的人同时执行同一条指令。于是它只好让所有人都先走“蒸”这一路（拿鸡的人被暂时掩蔽、干等），再集体走“炸”这一路（拿鱼的人反过来干等）。两条分支串行执行，时间直接翻倍。这就是“分支发散”（branch divergence）。

缓解发散的办法是“索引重排”：在把数据交给 GPU 之前，先按分支条件把数据分类聚拢，让同一束线程尽量走同一条路径。这就像传菜员把鱼和鸡分篮装好，再分别交给两批厨师，而不是混在一起让每个厨师挑挑拣拣。除了分支，访存方式同样影响巨大。当线程束里的 32 个线程访问全局内存时，硬件按 32/64/128 字节的粒度整块拉取数据。如果 32 个线程访问的是连续地址——按门牌号顺序取货——一次拉取的数据全部用上；如果地址跳来跳去，拉回来的数据大半浪费，带宽利用率骤降。这要求我们设计“数据布局”时尽量让相邻线程访问相邻内存，例如把“结构体数组（AoS）”改成“数组结构体（SoA）”，让同一属性的数据连续存放。

帮厨的智慧在于排队：要么让同一队人走同一条路，要么让整队人按门牌号顺序取货。Compute Shader 的性能密码就藏在这两条排队纪律里——控制好分支和数据布局，带宽和计算单元才能各司其职、满载运转。

实战应用

婚宴的上菜流水线涵盖了后厨的所有工种：甜品摆盘、灯光滤镜、颠锅翻勺、为每桌客人预估口味偏好。游戏和 AI 领域的 Compute Shader 应用，正是同一套“大批帮厨并行干活”的打法在不同场景的复用。粒子系统是最典型的例子：上百万个粒子的位置、速度更新互不依赖，每个线程负责一个粒子，一次 Dispatch 就完成一帧的全部更新，CPU 那边只需要下发工作单。这比在 CPU 上写 for 循环快出几个数量级。

后处理特效同样受益：泛光（Bloom）、景深、动态模糊等全屏滤镜本质是逐像素运算，天然适合交给 Compute Shader 并行执行。物理模拟中的位置约束求解、布料和流体的 PBD 算法，以及 AI 推理里的大矩阵乘法、注意力机制，底层也全是 compute kernel——大模型推理时的 GEMM 和 FlashAttention 就是把“按块计算”和“共享内存复用”发挥到极致的典例。

不过，并行并非万能。Amdahl 定律告诉我们：一个程序里总有无法并行化的串行部分，比如数据拷贝、任务调度、依赖计算。哪怕并行部分被无限加速，整体提速也受制于串行部分这堵“墙”。这就像后厨再快，如果传菜员只有一个人一趟趟跑，上菜速度照样被拖住。

从粒子、后处理到 AI 推理，Compute Shader 是把“海量简单任务”推向硬件的通用引擎。但聪明的工程师从不算计局部增益，而是先找串行瓶颈再上并行方案——毕竟一座再快的后厨，也怕备菜环节拖后腿。

AI 应用场景

Python 演示

import timeimport numpy as np  def kernel_update(positions, velocities, dt, bounds):    # 模拟 Compute Shader 内核: 每个数组元素由一个线程处理    positions += velocities * dt    hit_low = positions < 0.0    hit_high = positions > bounds    velocities[hit_low] = np.abs(velocities[hit_low])    velocities[hit_high] = -np.abs(velocities[hit_high])    positions = np.clip(positions, 0.0, bounds)    return positions  def run_simulation(count, steps=300, dt=0.016, bounds=100.0):    pos = np.random.rand(count, 2).astype(np.float32) * bounds    vel = (np.random.rand(count, 2).astype(np.float32) - 0.5) * 40.0    group_size = 256    num_groups = (count + group_size - 1) // group_size    print("dispatch groups: %d, threads per group: %d" % (num_groups, group_size))    start = time.perf_counter()    for _ in range(steps):        pos = kernel_update(pos, vel, dt, bounds)    elapsed = time.perf_counter() - start    return pos, elapsed  if __name__ == "__main__":    n = 1 << 22  # 4,194,304 个粒子    positions, spent = run_simulation(n)    print("particles: %d" % n)    print("frame rate: %.1f FPS" % (300 / spent))

1. def kernel_update(positions, velocities, dt, bounds):对应一个 Compute Shader 内核函数，GPU 上每个线程都会执行这份“工作单”。
2. positions += velocities * dt每个线程对自己负责的粒子做半帧位置积分，相当于 GPU 上并行的向量加法。
3. velocities[hit_low] = np.abs(velocities[hit_low])边界反弹判断，模拟 GPU 内核里的条件分支处理。
4. group_size = 256线程组大小，等价于 Shader 里的 numthreads(256,1,1)。
5. num_groups = (count + group_size - 1) // group_size用上取整计算需要派发的线程组数量，等价于 CPU 端 Dispatch(groups,1,1)。
6. for _ in range(steps):每一帧执行一次派发，GPU 端一帧调用一次 Dispatch。
7. np.random.rand(count, 2).astype(np.float32)用 float32 模拟 GPU 上的数据精度与内存布局。

常见误区

面试题