opengl - 显卡中如何处理Direct3D和OpenGL指令？

Question

我试图更好地理解GPU的工作方式，并对它们如何处理Direct3D或OpenGL等高级API感到困惑。常见的图形卡广告支持Direct3D和OpenGL硬件加速。这是否意味着它们直接在硬件中处理Direct3D和OpenGL指令？
我无法找到明确的证据，也无法找到将它们编译为GPU可以处理的程序集表示形式的证据。如果有这样的转换，那是谁呢？软件库(Direct3D/OpenGL)，驱动程序还是GPU本身？
在同一行上，在何处定义图形管道？在gpu硬件，驱动程序还是软件库中？这使我特别困惑可编程管线的概念。

有没有很好的资源可以在其中找到有关这些详细信息的信息？

Answer 1

您问了一个非常广泛而复杂的问题。实际上，您已经向问了几个广泛而复杂的问题。

对任何硬件的运行都有最终控制权的软件称为硬件的“驱动程序”。自然，对于图形硬件，这称为“图形驱动程序”。与所有驱动程序一样，图形驱动程序实际上是操作系统的可安装部分。操作系统是图形驱动程序完成其工作并与硬件对话的基础。两者携手并进。

实际上，有两种D3D或OpenGL(以前称为“API”)调用:与驱动程序对话的调用和不与驱动程序对话的调用。每个实际绘制内容的调用都需要(最终)与驱动程序进行通信，但是设置以后的绘制调用的调用可能仅将数据存储在本地。

当您进行绘图调用时，API会进行一些检查，以确保您作为用户已经进行了有效的渲染调用。如果是这样，API会提供一些有关操作的选项。事实证明，直接与驾驶员交谈需要很长时间，无论您开始交谈时发出了多少命令。因此，经常发生的情况是API存储了您的渲染调用并立即返回。然后，可能在另一个线程中，它看起来要查看已存储了多少个渲染调用。如果有“足够”，那么它将转发给驱动程序。这称为“编码”。

驾驶员的工作是接听这些已转发的调用，并将其转换为GPU会执行的操作。

On that same line, where is the graphics pipeline defined? in the gpu hardware, the driver, or the software library?

如今，这实际上是一个非常棘手的问题，并且在每一代硬件上都变得越来越棘手。

在过去，图形流水线的构建是由GPU硬件严格控制的。这些天来，尽管有一些硬件控制，但事实并非如此。在现代硬件(支持OpenGL 3.0或Direct3D10或更高版本)上，如果您可以直接访问图形驱动程序，则理论上可以设计一个使用图形管道版本有所更改的API。因此，API决定了图形管道的外观。

渲染管线中的每个阶段都将宝贵阶段中的某些值作为输入，并生成一定数量的值作为输出。如果用于从输入生成输出的机制涉及执行用户提供的程序(称为“着色器”)，则该阶段是“可编程的”。因此，还没有可编程管线这样的东西。只是固定管线的可编程阶段。