Draw Call Batch与乱序光栅化

MSDN / Direct3D 9 / Accurately Profiling Direct3D API Calls

https://docs.microsoft.com/en-us/windows/desktop/direct3d9/accurately-profiling-direct3d-api-calls

一般认为Draw Call Batch是为了解决CPU瓶颈，MSDN上的Direct3D9文档中对此进行了相关的讨论。

但实际上，Draw Call Batch还可以提高GPU绘制三角形时的并行度，还可以在某种程度上解决GPU瓶颈。

我们知道GPU在本质上是一个并行的系统，比如，“不同Fragment Shader之间不具有任何依赖”可以认为是GPU并行性的一个典型代表；但是由于应用层的某些逻辑的需要，导致了GPU在一定程度上具有串行性。

比如，经典的绘制透明物体的算法需要在应用层将物体从前到后或从后到前排序，并依次调用Draw Call，这意味着“在结果上”GPU绘制三角形的顺序应当与应用层调用Draw Call的顺序一致。

这意味着应用层按顺序调用Draw Call其实隐含着某种依赖关系。

我们之所以强调“在结果上”是因为：在实际实现中，GPU仍并行地绘制三角形，只不过在输出结果前进行了相关的处理来保证Draw Call靠后的三角形一定覆盖Draw Call靠前的三角形。

"Real Time Rendering Fourth Edition Chapter 23 Graphics Hardware Section 9 Architecture"中对GPU处理三角形时所进行的排序进行了详细的讨论。

显然同一个Draw Call中的三角形不需要排序（应用层的逻辑不关心它们的绘制顺序），因此Draw Call Batch可以提高GPU的并行度，从而可以在某种程度上解决GPU瓶颈。

Matthaeus Chajdas. "Unlock the Rasterizer with Out-of-Order Rasterization." AMD GPUOpen 2016.

https://gpuopen.com/unlock-the-rasterizer-with-out-of-order-rasterization/

AMD最近给出了一个乱序光栅化的Vulkan扩展，试图通过摒弃排序来提升GPU的并行度。

//PS：AMD的乱序光栅化扩展说明了OIT（顺序无关透明）算法的重要性，是时候启用一波OIT算法了（http://research.nvidia.com/publication/phenomenological-scattering-model-order-independent-transparency）233333333

但是，通过摒弃排序来提升GPU并行度的方式貌似只适用于Sort-Last Fragment架构的PC平台的GPU；Sort-Middle Tiled架构的Mobile平台的GPU在Fragment Shader之前进行排序，并通过FPK(Forward Pixel Kill)的方式对Fragment Shader的执行次数进行优化，想要摒弃排序貌似是不大可能的。

本文转载自异步社区

原文链接：https://www.epubit.com/articleDetails?id=N51c87a7e-3ce7-4009-846e-3c9803a71d08