我在让 GLSL 着色器在 AMD 和 Nvidia 硬件上工作时遇到问题。
我不是在寻求修复特定着色器的帮助，而是寻求如何避免出现这些问题。是否可以检查着色器是否可以在 AMD/Nvidia 驱动程序上编译，而无需在具有相应硬件的计算机上运行应用程序并实际尝试它？
我知道，最终，测试是唯一确定的方法，但在开发过程中我希望至少避免明显的问题。
每个使用 GLSL 的人肯定都会遇到这些问题，那么为什么我找不到好的方法来解决这些问题呢？
是否可以检查着色器是否可以在 AMD/Nvidia 驱动程序上编译，而无需在具有相应硬件的计算机上运行应用程序并实际尝试？
不。如果您要认真开发应用程序，在各种硬件上进行测试是唯一可靠的方法。
一般来说，对于小团队来说，处理这个问题最简单的方法就是完全避免这个问题。大多数驱动程序不兼容来自于尝试做一些非正统的事情：将数组作为输出/输入变化变量传递，将矩阵作为属性传递，使用更新的驱动程序功能等。所以......不要这样做。仅使用 GLSL 中已有的可靠、安全的东西，并且几乎肯定已在现实世界的 OpenGL 应用程序中使用过。
使用 NVidias 的 NVEmulate 和 AMD 的 GPU ShaderAnalyzer 可能是一种选择。
AMD 的 GPU ShaderAnalyzer 是一个独立的 GLSL/HLSL 编译器。 NVidias 的 NVEmulate 是一个在软件中模拟不同（更好）NVidia 显卡功能的工具。因此，如果您有 NVidia 卡，您只需运行程序来测试它（可能使用 NVEmulate 模拟另一张 NVidia 卡）并使用 ShaderAnalyser 查看您的着色器是否可以在 AMD 卡上编译。
如果您的着色器在 AMD 上运行，它很可能会在 NVidia 上运行。您仍然可以使用 cgc（NVidias 独立 Cg 编译器，Cg 工具包的一部分）对其进行测试，它将 GLSL 和 Cg 代码编译为二进制或将其交叉编译为 HLSL。无论如何，这是 NVidia 驱动程序用于 GLSL 的编译器。 好处是您还可以看到着色器的二进制/汇编代码，这对于低级优化非常有帮助。
没有工具可以告诉您的是，着色器是否在不同的硬件上工作（如预期）。我最近发现一些新的 AMD 驱动程序无法正确处理默认统一值...没有警告或错误消息。但这是一个不同的故事。 因此，在某些时候您必须在目标硬件上测试您的代码。