严格的 nVidia OpenGL 支持 (OpenGL 3.2)答案

【问题标题】：Strict nVidia OpenGL support (OpenGL 3.2)严格的 nVidia OpenGL 支持 (OpenGL 3.2)
【发布时间】：2013-09-20 07:59:37
【问题描述】：

虽然 AMD 非常严格地遵循 OpenGL 规范，但即使未遵循规范，nVidia 也能正常工作。一个例子是 nVidia 支持 CPU 内存上的元素索引（在 glDrawElements 中使用），而 AMD 仅支持来自元素数组缓冲区的元素索引。

我的问题是：有没有办法使用 nVidia 驱动程序强制执行严格的 OpenGL 行为？目前我对 Windows/OpenGL 3.2/FreeGlut/GLEW 设置的解决方案感兴趣。

编辑：如果无法对驱动程序本身强制执行严格的行为 - 是否有一些 OpenGL 代理可以保证严格的行为（例如 GLIntercept）

【问题讨论】：

我已经让代码在 nVidia 卡上“完美”运行，然后在 AMD 卡上崩溃。不幸的是，我所能做的就是广泛使用 glGetError() ，因为即使您收到错误，nVidia 有时仍然可以正常工作。如果可以的话，我也会查看 ARB_Debug_output，但我确定它 >= 4.x。
使用核心配置文件上下文应该是对驱动程序的非常强提示，以禁止弃用行为。但是我已经看到所有供应商都允许在核心上下文中进行一些只应该在兼容性配置文件中工作的事情。如果您真的想强制执行严格的一致性，最好的方法是熟悉规范并仅使用 supposed 在您的上下文中可用的功能：P 也就是说，可以配置 gDEBugger每当您进行已弃用的 API 调用时都会向您发出警告。
@AndonM.Coleman 我的问题不是不推荐使用的 API 调用 - 而是不推荐使用的用法，所以我认为 gDEBugger 或 GLIntercept 不会发现此类问题 (?)。
应该，它也会在 API 调用中测试已弃用的令牌。例如在对glTexImage2D (...) 的调用中的GL_LUMINANCE_ALPHA。但是，确定传递的指针是指向客户端内存还是指向 VBO 的偏移要困难得多，我想检测这种行为的唯一方法是测试元素数组 VBO 是否已绑定。我自己从未尝试过这种情况，所以我不知道它是否能够检测到这种特殊情况。

标签： opengl nvidia

【解决方案1】：

没有供应商严格执行规范。无论是 AMD、nVidia、英特尔、PowerVR，……他们都有自己的特质，遗憾的是，你必须学会与他们相处。这是让每个供应商实现自己的 GLSL 编译器的烦人事情之一，而不是微软在 D3D 中实现唯一的 HLSL 编译器。

ANGLE project 试图通过提供在许多主要 Web 浏览器之间共享的单个着色器验证器来在一定程度上缓解这种情况，但这是一场艰苦的战斗，而且这在大多数情况下仅适用于 WebGL。当每个供应商自己实现整个 API 时，您总会有实现差异。

现在 Khronos 小组已经认真承担了为桌面 OpenGL 建立一组一致性测试的任务，就像他们为 WebGL / OpenGL ES 所做的那样，事情可能会开始好转一些。但是强制驱动程序以严格的一致性模式运行并不是真正的标准 - 可能有 #pragmas 和这样的提示编译器的行为更严格，但这些都是特定于供应商的。

顺便说一句，我意识到这个问题与 GLSL per-se 无关，但这是我能举出的最好的例子。

【讨论】：

我只是想插话那个标准的 GLSL 编译器。关于现代 OpenGL，我一直怀念的一点是缺乏以更底层的方式提供着色器，比如 AST 或某种中间低级代码（例如 LLVM 中间层，然后被翻译成优化的机器代码由架构后端）。这将允许人们发明自己的着色器语言前端，使运行时着色器生成器的开发更容易，最重要的是允许开发和发布标准 GLSL 编译器。

【解决方案2】：

不幸的是，唯一能确保 OpenGL 代码在目标硬件上运行的方法就是对其进行测试。从理论上讲，简单地编写符合标准的代码应该可以在任何地方使用，但遗憾的是并非总是如此。

【讨论】：