为什么 opengl32.dll 和 gdi32.dll 之间函数重复？

Question

以下函数在 opengl32.dll 和 gdi32.dll 之间重复：

[opengl32.dll]         / [gdi32.dll]
wglChoosePixelFormat   / ChoosePixelFormat
wglDescribePixelFormat / DescribePixelFormat
wglGetPixelFormat      / GetPixelFormat
wglSetPixelFormat      / SetPixelFormat
wglSwapBuffers         / SwapBuffers

我一直在寻找答案很长时间，但似乎没有人知道为什么会这样以及它们的确切区别是什么。

OpenGL FAQ 第 5.190 节表明这些函数在功能上不相同：

为确保 OpenGL 正确运行，请使用 ChoosePixelformat， DescribePixelformat、GetPixelformat、SetPixelformat 和 SwapBuffers， 而不是 wgl 等效项 wglChoosePixelformat， wglDescribePixelformat、wglGetPixelformat、wglSetPixelformat 和 wglSwapBuffers。在所有其他情况下，使用 wgl 函数，其中 可用的。使用五个 wgl 函数只对 开发人员运行时链接到 OpenGL 驱动程序。

“运行时链接到 OpenGL 驱动程序”是否意味着绕过 opengl32.dll 并直接加载 ICD？

一个名为 "Mesa3D does not like my context creation code" 的 stackoverflow 线程似乎强化了这一点。

另一个名为 wglCreateContext in C# failing but not in managed C++ 的 stackoverflow 线程建议在使用 GDI 函数时必须在 gdi32.dll 之前加载 opengl32.dll，否则可能会出现运行时失败（错误：2000）。

我自己的测试表明，如果调用这些函数的 opengl32/wgl 版本，一些系统（Nvidia，但不是 Intel 或 Parallels VM）上会出现“错误：2000”。更改为 GDI 版本可以解决此问题，但使用 LoadLibrary("opengl32.dll") 似乎没有任何改变。

有没有人研究过这些 WGL 和 GDI 函数之间的区别？很明显，存在某种形式的差异，我试图了解在什么情况下应该使用哪个版本，以及如果使用了错误的版本，可能会遇到什么问题。

编辑：wayback machine brings up a webpage 描述了直接加载 ICD 的工作原理。这显然是 Voodoo 1/2 天的要求，当时 2d 和 3d 加速器是两个不同的硬件，具有单独的 ICD（普通的 opengl32.dll+ICD 机制无法处理）。地震 1 和 2 显然会加载直接因为这个ICD。

但是，下面的帖子显示 AMD ICD 不导出 wgl 变体，这与此想法相矛盾。

必须有人或某个地方掌握着这些知识的钥匙。

编辑 2：从上面的网页中得到了最清晰的建议：

"因此，如果您使用的是名为 opengl32.dll 的 OpenGL 驱动程序，您 必须调用 GDI 函数，如果您不使用名为 opengl32.dll 的驱动程序，则必须不调用 GDI 函数。 "

但这与 AMD ICD 不导出 wgl 函数这一事实有何关系？

编辑 2：显然 Mesa3d 导出 WGL 符号，如下所示：http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/windows/gdi

这是有道理的，因为 Mesa3d 不应该用作 ICD。这符合上面链接的 Mesa3d 线程中的模式：它们的调用没有通过 Microsoft 的 opengl32.dll 路由，因此 gdi 函数失败，但 Mesa3d 正在导出 wgl* 函数，因此这些函数仍然有效。但是，这是 Mesa3d 特有的 - 如果您尝试直接使用 AMD 的 ICD，该方法将失败。

Answer 1

有一个巨大的区别，即 WGL 函数的原型没有在任何系统头文件中定义。 opengl32.dll 导出符号，但除非您手动导入函数，否则您永远不会知道这一点。

但是，WGL 可安装客户端驱动程序 (ICD) 实现的功能实际上是这样的前缀：DrvSwapBuffers (...)、DrvSetPixelFormat (...)、DrvGetProcAddress (...) 等......所以如果你肯定没有直接链接到 ICD调用wglChoosePixelFormat (...) 而不是ChoosePixelFormat (...)。

opengl32.dll 基本上是微软的 OpenGL 的 GDI 实现和 ICD 的包装器。如果您查看Mesa，您甚至可以看到 ICD 的实现是什么样的；请注意没有任何函数以wgl 为前缀？ ICD不导出任何以wgl为前缀的符号，它们实现的WGL函数都是扩展（例如wglSwapIntervalEXT (...)、wglChoosePixelFormatARB (...)等），只能使用wglGetProcAddress (...)或DrvGetProcAddress (...)加载。

---

看看 AMD 的 OpenGL ICD：

        

您会注意到 AMD 实际上在其 ICD 中完全实现了 EGL API（您可以获得必要的标头以在 AMD 硬件here 上使用 EGL），但不会导出 WGL 符号。

---

更新：

如 cmets 中所述，当您调用 ChoosePixelFormat (...) 时，gdi32.dll 实际上会调用 wglChoosePixelFormat (...)。该函数所做的第一件事是尝试加载 opengl32.dll 并调用 wglChoosePixelFormat (...):

.text:4D579CAC ; int __stdcall ChoosePixelFormat(HDC,const PIXELFORMATDESCRIPTOR *)
.text:4D579CAC                 public _ChoosePixelFormat@8
.text:4D579CAC _ChoosePixelFormat@8 proc near
.text:4D579CAC
.text:4D579CAC hLibModule      = dword ptr -4
.text:4D579CAC arg_0           = dword ptr  8
.text:4D579CAC arg_4           = dword ptr  0Ch
.text:4D579CAC
.text:4D579CAC                 mov     edi, edi
.text:4D579CAE                 push    ebp
.text:4D579CAF                 mov     ebp, esp
.text:4D579CB1                 push    ecx
.text:4D579CB2                 push    esi
.text:4D579CB3                 lea     eax, [ebp+hLibModule]
.text:4D579CB6                 push    eax             ; int
.text:4D579CB7                 push    offset aWglchoosepixel ; "wglChoosePixelFormat"
.text:4D579CBC                 call    _GetAPI@12      ; GetAPI(x,x,x)
.text:4D579CC1                 xor     esi, esi
.text:4D579CC3                 test    eax, eax
.text:4D579CC5                 jz      short loc_4D579CD1
.text:4D579CC7                 push    [ebp+arg_4]
.text:4D579CCA                 push    [ebp+arg_0]
.text:4D579CCD                 call    eax
.text:4D579CCF                 mov     esi, eax

这里是GetAPI（它所做的只是加载 opengl32.dll 并从中导入一个命名函数）：

                              

现在，ICD 实际上并没有实现ChoosePixelFormat (...)，因为它在所有实现中的功能都是相同的。这是一个简单的模式匹配功能。如果您想了解 opengl32.dll 如何在运行时将其 wgl... 函数之一分派到 ICD，请查看 wglSwapBuffers 的控制流：

  

红色左侧分支是安装 ICD 时出现的情况，绿色右侧分支是 wglSwapBuffers 的默认 GDI 实现。有趣的是，您可以看到 GDI 实现需要完整的glFinish (...)。大多数硬件驱动程序在交换缓冲区时倾向于刷新命令队列而不是完成，这可以实现更好的 CPU/GPU 并行性。