我还没有找到明确的证据,无论是它们被编译成GPU可以处理的汇编表示法,还是有任何转换过程。如果有这样的转换,那么谁会执行?是软件库(Direct3D/OpenGL),驱动程序还是GPU本身?
同样,在哪里定义了图形管线?在GPU硬件、驱动程序还是软件库中?这让我特别困惑,尤其是可编程管线的概念。
有没有好的资源可以找到这些详细信息?
您提出了一个非常广泛且复杂的问题。实际上,您提出了几个广泛且复杂的问题。
管理硬件操作的软件称为硬件的“驱动程序”。自然地,对于图形硬件,这称为“图形驱动程序”。像所有驱动程序一样,图形驱动程序实际上是操作系统(OS)中可安装的部分;操作系统使图形驱动程序能够执行其工作并与硬件交互。两者相辅相成。
实际上有两种D3D或OpenGL(以下简称“API”)调用:那些与驱动程序交互的和那些不需要交互的。每个实际绘制某些内容的调用都需要(最终)与驱动程序交互,但设置稍后绘制调用的调用可能只是本地存储数据。
当您进行绘制调用时,API会进行一些检查,以确保您作为用户已经进行了有效的渲染调用。如果是这样,API就有一些选择。事实证明,直接与驱动程序通信需要很长时间,无论您何时开始通信,都需要很多命令。因此,通常发生的是,API会存储您的渲染调用并立即返回。然后,在另一个线程中,它可能会查看已存储多少个渲染调用。如果有“足够的”,则将它们转发给驱动程序。这称为“编组”。
驱动程序的工作是接收并转换已转发的这些调用,以执行GPU所需的操作。
在同一条线上,图形管道定义在哪里?在GPU硬件、驱动程序还是软件库中?
事实上,这现在是一个非常棘手的问题,并且随着每个硬件代之后变得更加棘手。
在过去,图形管线的构建严格受 GPU 硬件控制。但现在这种情况相对较少,虽然还是有一些硬件控制。在现代硬件上(支持 OpenGL 3.0 或 Direct3D10 或更好),如果你直接访问图形驱动程序,理论上可以设计一个使用略微改变版本的图形管线的 API。因此,API 决定了大部分图形管线的外观。
渲染管线中的每个阶段都会从前面的阶段输出值作为输入,并生成一些值作为输出。如果生成输出值的机制涉及执行用户提供的程序(称为“着色器”),则该阶段是“可编程”的。因此,目前并不存在可编程的管线;只有固定管线的可编程阶段。