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

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

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

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

我们以 Linux 和 Mesa3D 为例。

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

这意味着（在这个例子中）一个像glad/glew/gl3w这样的加载库直接位于Mesa3D之上，除了Mesa3D之外没有其他人与其他人对话？

解决方法

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

那个实际上有点棘手，因为这个函数不是 OpenGL 的一部分，而是特定于平台的 OpenGL 绑定库的一部分。例如，您在 Win32/wgl 上有 wglGetProcAddress，在 X11 上有 glxGetProcAddress，在 EGL 上有 elgGetProcAddress（多平台，更现代和灵活的替代方案）。

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

在 Windows 上，答案是“Microsoft”，但这是一个毫无意义的答案，因为 microsoft 函数基本上只调用 OpenGL ICD（可安装的客户端驱动程序）中的一些特定于实现者的函数，它完成了真正的工作，然后出现了来自 cousre 的 opengl 实现者（通常是英特尔、英伟达、AMD，但您甚至可以在 Windows 上运行台面软件光栅化器）。

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

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

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

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

这意味着（在这个例子中）一个像glad/glew/gl3w这样的加载库直接位于Mesa3D之上，除了Mesa3D之外没有其他人与其他人对话？

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

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