根据我的理解（如果我错了，请纠正我），OpenGL api将源代码中程序员编写的函数调用转换为我们图形卡的特定gpu驱动程序调用。然后，gpu驱动程序能够通过PCIe，AGP或PCI等硬件接口将指令和数据真正发送到图形卡。
我的问题是，openGL是否知道如何与不同的图形卡交互，因为基本上只有3种类型的物理连接（PCIe，AGP和PCI）？
我认为这并不是那么简单，因为我总是看到不同的图形卡有不同的驱动程序，所以驱动程序不仅仅是一种使用物理接口的方式，但它的目的是使图形卡能够执行不同类型的命令（特定于供应商）。
我只是不了解大局。
答案 0 :(得分：4)
这是问题“my answer”How does OpenGL work at the lowest level?的副本（该问题已标记为删除，因此我在此处添加了一些冗余）。
这个问题几乎无法回答，因为OpenGL本身只是一个前端API，只要实现符合规范并且结果符合这一点，就可以按照您喜欢的方式完成。
问题可能是：OpenGL驱动程序如何在最低级别上运行。现在再次无法回答这个问题，因为驱动程序与某些硬件密切相关，而开发人员可能会再次设置它。
所以问题应该是：“它在OpenGL和图形系统的幕后平均看起来如何？”让我们从下往上看：
在最低级别有一些图形设备。现在这些是GPU，它们提供一组寄存器来控制它们的操作（这些寄存器完全取决于设备）具有一些用于着色器的程序存储器，用于输入数据的大容量存储器（顶点，纹理等）以及用于其余部分的I / O通道它接收/发送数据和命令流的系统。
图形驱动程序跟踪GPU状态以及使用GPU的所有资源应用程序。它还负责转换或任何其他处理应用程序发送的数据（将纹理转换为GPU支持的pixelformat，在GPU的机器代码中编译着色器）。此外，它还为应用程序提供了一些抽象的，依赖于驱动程序的接口。
然后是依赖于驱动程序的OpenGL客户端库/驱动程序。在Windows上，这会得到 由代理通过opengl32.dll加载，在Unix系统上，它驻留在两个地方：
在MacOS X上，这恰好是“OpenGL框架”。
正是这部分将OpenGL调用的方式转换为对（2）中描述的驱动程序部分中的驱动程序特定函数的调用。
最后是实际的OpenGL API库，Windows中的opengl32.dll和Unix上的/usr/lib/libGL.so;这大多只是将命令传递给OpenGL实现。
实际沟通的发生方式不能一概而论：
在Unix中，3＆lt; - ＆gt; 4连接可能通过套接字发生（是的，它可能，并且如果你愿意，它会通过网络进行）或通过共享内存。在Windows中，接口库和驱动程序客户端都被加载到进程地址空间中，因此没有那么多的通信，只有简单的函数调用和变量/指针传递。在MacOS X中，这与Windows类似，只是OpenGL界面和驱动程序客户端之间没有分离（这就是为什么MacOS X跟上新的OpenGL版本如此之慢的原因，它总是需要一个完整的操作系统升级来提供新的框架）。
3＆lt; - ＆gt; 2之间的通信可以通过ioctl，读/写，或者通过将一些存储器映射到进程地址空间并配置MMU以在每次完成对该存储器的改变时触发一些驱动器代码。这在任何操作系统上都非常相似，因为你总是必须跨越内核/用户空间边界：最终你会经历一些系统调用。
系统和GPU之间的通信是通过外围总线及其定义的访问方法实现的，因此PCI，AGP，PCI-E等通过端口I / O，内存映射I / O，DMA，IRQ进行。