为什么对于图形API，线程安全如此重要？

#1 楼

主要的好处是，将CPU任务划分为多个线程将更加容易，而不必解决访问图形API的所有难题。通常，您要么必须使上下文成为当前上下文（这可能会对性能造成不良影响），要么要提供一个队列并在单个线程中调用图形api。我不认为以这种方式可以获得任何性能，因为GPU确实确实可以按顺序处理它们，但是这使开发人员的工作容易得多。这是因为Directx和opengl是在多线程并不十分明显的时代创建的。同样，Khronos委员会在更改API方面非常保守。他们对Vulkan的看法也是，它会与OpenGL并存，因为两者都有不同的用途。直到最近，Paralism才变得如此重要，因为消费者可以访问越来越多的处理器。将调用分成多个线程以更快地创建纹理/着色器没有用。相反，由于有更多的处理器忙碌并使gpu忙于要执行的事情而获得了性能。

#2 楼

要为GPU设置框架，CPU需要做很多工作，并且其中很大一部分工作在图形驱动程序内部。在DX12 / Vulkan之前，该图形驱动程序的工作实际上是通过API的设计被强制为单线程的。在一帧内的多个CPU线程上并行运行。这将使多核CPU的使用效率更高，从而使游戏引擎可以推送更复杂的场景而不会受到CPU的限制。这是希望-在未来几年中是否需要在实践中实现这一点，我们将拭目以待。

详细说明一下：游戏引擎渲染器的输出是流DX / GL API调用描述了渲染帧的操作顺序。但是，API调用流与GPU硬件消耗的实际二进制命令缓冲区之间有很大的距离。可以这么说，驱动程序必须将API调用“编译”为GPU的机器语言。这不是一个微不足道的过程，它涉及许多API概念到低级硬件现实的转换，验证以确保GPU永远不会设置为无效状态，处理内存分配和数据，跟踪状态更改以发布纠正低级命令，依此类推等等。图形驱动程序负责所有这些工作。

在DX11 / GL4和更早版本的API中，这项工作通常由单个驱动程序线程完成。即使您从多个线程调用该API（例如，您可以使用DX11延迟命令列表执行此操作），它也只会将一些工作添加到队列中，以供驱动程序线程稍后通过。原因之一是我之前提到的状态跟踪。许多硬件级别的GPU配置细节都需要了解当前图形流水线状态，因此没有很好的方法将命令列表分解为可以并行处理的块-每个块都必须确切知道应该开始的状态即使尚未处理之前的代码块。

这是DX12 / Vulkan中发生的重大变化之一。一方面，它们将几乎所有图形管线状态合并到一个对象中；而对于另一个对象（至少在DX12中），当您开始创建命令列表时，必须提供初始管线状态。状态不会从一个命令列表继承到下一个命令列表。原则上，这允许驱动程序在开始编译之前不必了解任何先前的命令列表，从而使应用程序可以将其呈现分解为可并行化的块，从而生成完全编译的命令列表，然后可以将其

当然，新API还有许多其他更改，但是就多线程而言，这是最重要的部分。 >

#3 楼

现代GPU通常只有一个前端部分，可以处理来自CPU的完全线性的命令流。这是自然的硬件设计，还是只是在单个CPU内核为GPU生成命令的时代之外逐渐演变，这是有争议的，但这是现实。因此，如果生成单个线性的状态命令流，则在CPU的单个线程上线性生成该流当然是有道理的！是吗？

好吧，现代GPU通常也具有非常灵活的统一后端，可以同时处理许多不同的事物。一般而言，GPU可在相当精细的粒度下在顶点和像素上运行。 GPU在一次绘制中处理1024个顶点与在两次不同绘制中处理512 + 512个顶点之间并没有太大的区别。通过一次绘制调用在GPU上绘制顶点，将模型划分为多个部分，对这些部分进行廉价的粗略剔除，如果每个块都通过剔除测试，则分别提交。如果以正确的粒度进行操作，应该会获得不错的加速效果。原因的简化说明：GPU上的状态更改可能不直接与图形API调用相对应，因此许多图形API调用只是在驱动程序内部设置了一些状态，而依赖于此新状态的draw调用会遍历所有标记为自上次绘制以来已更改的状态，将其写入GPU的命令流中，然后实际启动绘制。这是为获取GPU前端单元的精简指令流而完成的所有工作。

归结为，您的抽奖预算完全由驱动程序的开销决定。 （我想我听说这些天您可以为60 FPS标题获得每帧5,000左右的收益。）您可以通过在并行块中构建此命令流来大幅提高该收益。也是其他原因（例如，用于改善VR延迟的异步时间扭曲），但这对于图形绑定游戏和其他需要大量调用的软件（例如3D建模包）来说是一个很大的原因。