OpenGL函数加载机制是如何工作的？

Question

现代 OpenGL (>1.2) 函数必须在运行时加载。具体如何完成此操作取决于平台，但它似乎总是涉及调用“get-function”，该函数返回指向您请求的函数的指针。两个问题：

1. 谁实现了这个神奇的 get 函数？
2. 谁实现了它返回的函数（指针）？

让我们以 Linux 和 Mesa3D 为例。

我现在的理解是 Mesa3D 通过 libgl.so 和 gl.h 提供 get-function，并且它仅在用户空间中运行。也是Mesa3D实现了get函数返回的函数的用户空间端，内核端由GPU驱动程序实现。它是否正确？

这是否意味着（在本例中）像glad/glew/gl3w 这样的加载库直接位于 Mesa3D 之上，并且除了 Mesa3D 之外不与任何人通信？

Answer 1

1. 谁实现了这个神奇的 get 函数？

这个函数实际上有点棘手，因为这个函数不是 OpenGL 的一部分，而是特定于平台的 OpenGL 绑定库的一部分。例如，您可以wglGetProcAddress在 Win32/wgl、glxGetProcAddressX11、elgGetProcAddressEGL（多平台、更现代、更灵活的替代方案）上使用。

在Linux上，EGL和glX实现是OpenGL实现的一部分（例如mesa，但nivida的专有驱动程序带有自己的glX和egl库），因此您问题的答案是“opengl实现者”。

在 Windows 上，答案是“Microsoft”，但这是一个毫无意义的答案，因为 microsoft 函数基本上只调用 OpenGL ICD（可安装客户端驱动程序）中的一些特定于实现者的函数，该函数执行真正的工作，并且该函数来自 opengl cousre 的实现者（通常是 intel、nvidia、AMD，但您甚至可以在 Windows 上运行 mesa 软件光栅化器）。

2. 谁实现了它返回的函数（指针）？

OpenGL 实现者。通常，OpenGL 实现是图形驱动程序的一部分。

我现在的理解是 Mesa3D 通过 libgl.so 和 gl.h 提供 get-function，并且它仅在用户空间中运行。也是Mesa3D实现了get函数返回的函数的用户空间端，内核端由GPU驱动程序实现。它是否正确？

Mesa3D 有点特殊，因为它是多供应商 OpenGL 实现。实际上，mesa 由一些共享前端（形成libGL和其他的外部接口）和实用功能以及一些特定于供应商的后端组成。这些 mesa 后端实际上被视为图形驱动程序的一部分，驱动程序不仅仅是 mesa 与之通信的内核模块。很大一部分图形 API（尤其是在 GL 中）是在用户空间中实现的，而且仍然是高度特定于设备的。

这是否意味着（在本例中）像glad/glew/gl3w 这样的加载库直接位于 Mesa3D 之上，并且除了 Mesa3D 之外不与任何人通信？

或多或少。事实有点复杂和丑陋。在某些平台上，扩展函数指针查询函数不需要返回 OpenGL 1.1 核心中函数的指针，因此大多数加载器通过诉诸GetProcAddress(win32) 或dlsym在运行时查询这些符号来解决此问题，因此它们通常libdl.so也可以在 Linux 上使用（以及dlopen你背后的 GL 库）。请注意，这也意味着当您使用像 GLAD 这样的 GL 加载器时，您不必（实际上不应该）在项目中手动链接到libGL.so -无论如何，它在运行时完全加载，并且您的程序也可以退出如果用户系统上没有可用的 GL 库，则很好，而不是由于缺少库而导致二进制文件无法启动。

此外，现代 Linux 发行版使用libgvnd供应商中立的 GL 调度方案，这意味着即使您使用 Mesa3D，GL 加载程序实际上也会与 GLvnd 存根通信，该存根在内部会将请求路由到您使用的实现（在您的情况下是 mesa3d） 。