问OpenGL在最底层是如何工作的？

EN

这个问题几乎不可能回答，因为OpenGL本身只是一个前端应用程序接口，只要实现遵循规范，结果符合规范，就可以按照您喜欢的任何方式完成。

问题可能是: OpenGL驱动程序如何在最低层上工作。现在，这又是不可能在一般情况下回答的，因为驱动程序与某个硬件紧密相关，无论开发人员如何设计，这些硬件可能会再次执行某些操作。

因此，问题应该是：“在OpenGL和图形系统的幕后，它的平均外观如何？”让我们从下往上看：

1. 在最底层有一些图形设备。如今，这些GPU提供了一组控制其操作的寄存器(这些寄存器完全依赖于设备)，具有一些用于着色器的程序内存，用于输入数据(顶点、纹理等)的大容量内存。以及到系统其余部分的I/O通道，它通过该通道接收/发送数据和命令流。
2. 图形驱动程序跟踪GPU状态和使用该GPU的所有资源应用程序。此外，它还负责转换或任何其他处理应用程序发送的数据(将纹理转换为GPU支持的像素格式，在GPU的机器代码中编译着色器)。此外，它还为应用程序提供了一些抽象的、依赖于驱动程序的接口。
3. 然后是依赖于驱动程序的OpenGL客户端库/驱动程序。在Windows上，它由代理通过opengl32.dll加载，在Unix系统上，它驻留在两个位置：

- X11 GLX module and driver dependent GLX driver
- and /usr/lib/libGL.so may contain some driver dependent stuff for direct rendering

在MacOS X上，这恰好是"OpenGL框架“。

正是这一部分将OpenGL调用转换为对(2)中描述的驱动程序部分中的驱动程序特定函数的调用。

1. 最后是实际的OpenGL API库，在Windows中是opengl32.dll，在Unix /usr/lib/libGL.so上；这主要是将命令传递给正确的OpenGL实现。

实际通信是如何发生的不能一概而论：

在Unix中，3<->4连接可以通过套接字(是的，它可以，如果您愿意的话，也可以通过网络)或通过共享内存进行连接。在Windows中，接口库和驱动程序客户端都被加载到进程地址空间中，因此没有太多的通信，只是简单的函数调用和变量/指针传递。在Windows中，这类似于Windows，只是在OpenGL界面和驱动程序客户端之间没有分离(这就是为什么MacOS X跟不上新的OpenGL版本的原因，它总是需要完全的操作系统升级才能提供新的框架)。

2之间的通信可以通过ioctl、读/写，或者通过将一些存储器映射到进程地址空间并配置MMU以在对该存储器的改变完成时触发一些驱动程序代码。这在任何操作系统上都非常相似，因为您总是必须跨越内核/用户的边界:最终，您需要经历一些syscall。

系统与GPU之间的通信是通过外围总线及其定义的访问方式实现的，因此PCI、AGP、PCI-E等都是通过Port-I/O、内存映射I/O、DMA、IRQ等方式工作的。

当我编译这个程序时，它是否会变成一系列ioctl调用，然后gpu驱动程序会向gpu发送适当的命令，所有旋转三角形和以适当的颜色设置适当像素的逻辑都会连接到gpu？或者程序会被编译成一个"gpu程序“，加载到gpu上并计算旋转等？

你离得不远了。您的程序调用可安装的客户端驱动程序(这不是一个真正的驱动程序，它是一个用户空间共享库)。它将使用ioctl或类似的机制将数据传递给内核驱动程序。

对于下一部分，它取决于硬件。较老的显卡有一个所谓的“固定功能管道”。显卡中有用于矩阵的专用内存空间，以及用于纹理查找、混合等的专用硬件。视频驱动程序将为每个单元加载正确的数据和标志，然后设置DMA来传输顶点数据(位置、颜色、纹理坐标等)。

较新的硬件在显卡中具有处理器核心(“着色器”)，它们与CPU的不同之处在于，它们各自的运行速度要慢得多，但它们中有更多的处理器是并行工作的。对于这些视频卡，驱动程序准备在GPU着色器上运行的程序二进制文件。

您的程序不是针对任何特定的图形处理器进行编译的；它只是针对将实现OpenGL的库进行动态链接。实际的实现可能涉及将OpenGL命令发送到GPU、运行软件回退、编译着色器并将其发送到GPU，甚至使用OpenGL命令的着色器回退。图形环境相当复杂。谢天谢地，链接将您与大多数驱动程序的复杂性隔离开来，让驱动程序实现者可以自由地使用他们认为合适的任何技术。