现代 OpenGL (>1.2) 函数必须在运行时加载。确切的完成方式取决于平台，但它似乎总是涉及调用“get-function”，该函数返回指向您请求的函数的指针。两个问题：
让我们以带有 Mesa3D 的 Linux 为例。
我现在的理解是 Mesa3D 通过 libgl.so 和 gl.h 提供 get-function，它只在用户空间中运行。也是 Mesa3D 实现了 get 函数返回的函数的用户空间端，内核端由 GPU 驱动程序实现。这是正确的吗？
这意味着（在此示例中）像glad/glew/gl3w 这样的加载库直接位于 Mesa3D 之上，并且除了 Mesa3D 之外不与其他任何人对话？
【问题讨论】：
- 谁实现了这个神奇的 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 实现者（通常是 intel、nvidia、AMD，但您甚至可以在 windows 上运行 mesa 软件光栅化器）。
- 谁实现了它返回的函数（指针）？
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 在以下位置查询这些符号来解决这个问题运行时，所以他们通常也可能在 Linux 上使用 libdl.so（以及 dlopen 背后的 GL 库）。请注意，这也意味着当您使用像 GLAD 这样的 GL 加载器时，您不必（实际上也不应该）在您的项目中手动链接到 libGL.so 根本 - 它完全加载在无论如何，运行时，如果用户系统上没有可用的 GL 库，您的程序也可以很好地退出，而不是由于缺少库而导致二进制文件甚至无法启动。
此外，现代 Linux 发行版使用 libgvnd 供应商中立的 GL 调度方案，这意味着即使您使用 Mesa3D，GL 加载程序实际上也会与 GLvnd 存根对话，后者会在内部将请求路由到您使用的实现（在你的情况下是 mesa3d）。
【讨论】：