问题描述
现代 OpenGL (>1.2) 函数必须在运行时加载。具体如何完成取决于平台,但它似乎总是涉及调用“get-function”,该“get-function”返回指向您请求的函数的指针。两个问题:
- 谁实现了这个神奇的 get 函数?
- 谁实现了它返回的函数(指针)?
我们以 Linux 和 Mesa3D 为例。
我现在的理解是 Mesa3D 通过 libgl.so 和 gl.h 提供 get-function,并且它只在用户空间中运行。同样是Mesa3D实现了get-function返回的函数的用户空间端,内核端由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 实现者(通常是英特尔、英伟达、AMD,但您甚至可以在 Windows 上运行台面软件光栅化器)。
- 谁实现了它返回的函数(指针)?
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)。