释放GPU潜力：AMD的异步着色白皮书

kirin77 · 发表于 2022-4-14 17:53

原文链接：
才疏学浅，欢迎指正！
太长不看版

渲染的不同阶段所使用的硬件资源是不同的，所以在进行3D渲染的同时，并行使用计算着色器进行2D处理可以更充分的利用硬件。
介绍

现代GPU虽然非常高效，但因为软件和硬件的限制导致它们的潜能没有充分发挥。
甚至在密集的渲染操作期间，GPU的大部分处理能力可能都处于空间状态。通过架构改进和异步着色技术我们可以利用这一部分空闲能力。
利用并行性

因为需要处理大量的多边形和像素来生成图像，图形处理被认为是一个并行问题。可以被处理的多边形和像素越多，最后生成的图像质量也就会越高。GPU做的就是使用专有硬件来尽可能多的并行处理多边形和像素。
但提交任务给GPU，然后高效调度可用硬件资源却是一个复杂问题。GPU的性能表现严重依赖于管线。管线通常包含了多个阶段的处理，比如指令处理(command processing)，几何处理(geometry processing)，光栅化(rasterization)，着色(shading)等等。每个阶段本身可以并行处理，但每个阶段处理的数据依赖于上一阶段，输出的数据也依赖于下一阶段的接收能力。
应用程序以指令缓冲(command buffer)或指令列表(command list)的形式向GPU提交任务。指令缓冲(command buffer)和指令列表(command list)包含了一系列在数据集上并行执行的指令。每个指令缓冲关联了一个特定的渲染任务(比如渲染阴影贴图，光照计算，物理模拟等等)。理想情况下，我们想让GPU尽可能同时处理这些任务，这样可以尽可能多得进行硬件资源共享，从而提升性能表现。但实际上，这样做需要克服非常多的问题。

图1：一个典型的管线处理图形渲染任务图示

图2：使用多个并行队列加速渲染管线的任务执行

异步计算

为了实现异步计算，对于图形管线里的许多任务，GPU需要知道它们的依赖关系，从而更好地进行任务调度。现代图形API，比如Mantle，DirectX 12和Vulkan提供了API来向GPU提交任务的依赖关系。
对于DirectX 12，应用程序可以通过多个不同类型的队列提交任务，包括：

用于主要渲染任务的图形队列
用于GPU计算任务(物理模拟，光照计算，后处理等等)的计算队列
用于数据传输的传输队列

给定一个队列的指令缓冲的执行是同步的，但不同队列的执行是异步的(类似于并发和并行的区别)。尽可能多得重叠多个不同队列的任务执行可以更充分得发挥GPU的潜力。
类似方法在主机游戏上已经被使用，所以主机游戏开发者可能对这种多队列提交GPU任务非常熟悉。这也是为什么相似的硬件主机游戏的图形表现更好的原因。而现在新的图形API，使得PC也可以使用同样的方法得到性能提升。

图3：使用多种不同类型的队列并行执行渲染任务

调度

为了实现异步着色，GPU需要有能力在多个不同类型队列间调度硬件资源。在过去，GPU通常一次只能处理一个指令流，硬件实现不复杂。但如果需要同时处理多个队列，就复杂很多。考虑现在有两个任务同时出现，需要使用一部分共享资源，那么这两个任务该先处理谁？
考虑下图的例子，两个任务流(也就是任务队列)需要使用同一个GPU处理资源，谁该先得到资源？一个最简单的方法就是使用信号灯，定期地切换，让两个任务流都有机会轮流得到处理。

图4：一个简单的任务切换架构图示

为了让GPU从一个任务切换到另一个任务，我们需要：

停止提交和当前任务流相关的新的任务
允许所有计算可以异步完成(in flight to complete)
替换当前任务相关联的上下文数据为下一任务的上下文数据
开始提交下一任务流中的任务

上下文(Context，也叫做state，状态)是一个表示和特定任务相关联的数据的术语。它包含了和任务相关联的常量，指向数据位置的指针，以及计算执行所需的缓冲区等信息。为了能让处理单元更快地访问上下文中的数据，上下文数据通常被存储在片上缓存中。对于片上缓存中的上下文数据的切换管理是GPU处理多个队列任务问题的核心。
另一个调度策略是为每一个队列赋予一个优先级，允许高优先级队列中的任务先被调度执行。这意味着当高优先级队列中有新任务，会挂起执行低优先级队列中剩下的任务。类比现实，相当于出现了突发事件，人们必须等待突发事件结束才能通过马路。

图5：优先处理高优先级任务

这一策略虽然可以减少主要任务的处理延迟，也不必然会提升性能表现，因为这一策略并没有做到多队列的同时执行。甚至在一些情况，这一策略造成的上下文切换还会降低性能表现。
一个更好的策略是在不挂起其它队列任务下，开始提交执行另一个队列的任务。这一策略需要进行更细粒度的任务调度，穿插执行多个队列上的任务。类似下图，不再需要信号灯，不会强制某个队列停止或等待执行。

图6：细粒度的异步计算

这一策略的最佳范例就是将轻量的计算(compute)/传输(copy)队列(它们需要相对少的处理资源)和重量的图形队列重叠执行。从而利用较大任务执行过程中的部分硬件资源空闲执行较轻量的任务，从而发挥GPU潜力。
硬件设计

为了充分利用异步着色的优势，我们需要改进GPU架构。理想情况下，我们希望图形处理是一个同步多线程(SMT)操作，任务可以被分配到多个共享硬件资源的线程上。我们的设计目标是在保持由管线处理和高度并行带来的性能表现的情况下，提升硬件资源利用率。
为此，AMD的GCN架构被设计成可以并行处理多个指令流(command stream)。具体来说，AMD的GCN架构通过多个异步计算引擎(Asynchronous Compute Engines，ACEs)对指令进行处理。每个ACE都可以独立分发任务给GPU的处理单元。目前来说，AMD的GCN架构支持每个GPU最大8个ACE，每个ACE最多可以管理8个独立的队列。
ACE可以和图形指令处理器，以及两个DMA引擎(用于数据传输)并行执行。图形指令处理器用于处理图形队列，ACE用于处理计算队列，DMA引擎用于处理传输队列。每个队列不用等待其它队列中的任务完成就可以分发任务，允许不同的指令流穿插使用GPU的着色引擎，实现不同队列同时执行。
这一架构设计通过利用管线处理过程中的硬件空闲来提高硬件利用率和性能表现。如果需要，这一架构也同样支持优先级抢占，但高优先级的任务通常都是相对轻量的计算，所以也不是很必要使用。在设计上，ACE就是为了减少上下文切换相关的代价，从而提升性能表现。

图7：GCN架构图示

使用异步着色器

许多图形应用程序可以从异步着色中收益。实践中，几乎所有现代游戏渲染引擎都会使用计算着色器异步计算一些图形渲染任务。随着渲染引擎越来越复杂，计算着色器使用得也越来越多。甚至很多人任务渲染引擎慢慢地会从现在的基于管线模型转到基于任务的多线程模型，在新的模型下，计算着色器的使用只会更多。下面是一些从异步着色器中受益的应用场景。
后处理特效

很多游戏会使用后处理特效还给玩家带来独特的视觉体验。通常后处理是在主图形渲染管线完成一帧渲染后，基于这一帧进行的，并且通常使用计算着色器完成后处理计算。常见的视觉效果，比如，模糊滤镜，反走样，景深，泛光以及颜色校正都是后处理实现的。这些后处理计算是使用异步着色进行加速的理想对象。
下图是使用异步着色实现的模糊滤镜，相比不使用异步着色，性能提升百分之45。

图9：使用异步着色加速模糊滤镜的后处理计算

光照计算

另一个可以应用的地方是延迟渲染，使用异步着色可以让延迟渲染的光照计算(lighting pre-pass)性能提升百分之10。

图10：使用Direct 12和异步着色技术实现延迟渲染

虚拟现实

虚拟现实(VR)是图形渲染的新领域。它需要更低的渲染延迟来避免引起设备佩戴者的不适。但即使是渲染开始时获取的佩戴者头部位置信息，在渲染结束后也变得和当前头部位置不匹配。
为了解决上面的问题，可以使用Time Warp技术。这一技术会获取每帧渲染结束后的头部位置信息，使用这一信息扭曲画面，让画面看起来是在新视角下渲染的。
这一Time Warp技术使用了计算着色器，为了减少延迟，它的计算执行也需要较高的优先级。如果使用异步着色技术，上下文切换和优先级抢占带来的延迟就可以被很大程度避免。

图11：使用异步Time Warp减少延迟

总结

目前，异步着色所需的软件和硬件支持已经可用，希望开发者们可以利用它们释放更多的GPU硬件潜力。

c0d3n4m · 发表于 2022-4-14 17:55

其实不是3D/2D的区别，关键是graphics queue涉及到很多pipeline state和fixed function组件，一般只有一个所以很难并行多个任务，而单个任务对计算或访存有偏好，不容易发挥满性能，甚至可能因为运算规模太小而更加浪费。
但是纯计算的话，涉及到的状态就少很多，就很容易做多个queue来充分利用硬件了。

mastertravels77 · 发表于 2022-4-14 18:02

是这样[赞同]

		自动登录	找回密码
密码			立即注册

释放GPU潜力：AMD的异步着色白皮书

本帖子中包含更多资源