为什么在编译OpenGL程序时着色器总是一个额外的文件？

Question

为什么我们不将主文件和着色器文件代码放在一起？

为什么我们必须分开它们？

我们应该这样做吗？

为了让程序运行更快或任何其他原因？

Answer 1

问题存在于多个层面。

• OpenGL没有一致的字节码格式：简单地说，不能保证如果在一台计算机上创建着色器的编译字节码，那么相同的编译形式将在另一台计算机上运行，即使他们拥有相同的GPU。由于驱动程序更新和其他硬件更改，还无法保证字节码可以在具有相同GPU的同一台计算机上运行！这是Vulkan通过引入SPIR-V来解决的问题，应该适用于任何符合要求的Vulkan实现。但是OpenGL没有与SPIR-V相当的东西。

  编辑：为OpenGL引入了一个扩展，以支持SPIR-V。但它还不是核心，而且还有本文中列举的其他两个问题。

• 在大多数编程语言中没有“文件文字”：理论上可以将String-literal源代码编译到程序中，这至少可以解决在发布时必须发送多个文件的问题。但是大多数编程语言本身并不支持这种语言。 C ++提出了所谓的“文件文字”的建议，它允许文件的内容在编译时作为字符串文字存储，但截至目前（2016-09-14），这不是正式或良好的 - 支持。
• 字符串文字难以调试：没有什么可以阻止您直接在源代码中定义任何想要直接使用的着色器作为大型String对象，无论您的编程语言是什么。但它很难调试，也无法通过外部工具或程序进行修改/验证（如GLSL验证器或基于提供给它的输入“构建”GLSL着色器的程序“，这对于专业程序员来说通常是必不可少的。

许多程序员找到解决这些问题的解决方法和解决方案。在专业设置中，着色器源代码通常被压缩并存储在资源文件中，与存储模型，纹理，声音等的方式相同。所以很多时候这个问题被最小化或抽象掉了。

但从一般意义上讲，这个问题很少有实用，通用解决方案。

Answer 2

  

为什么我们不将主文件和着色器文件代码放在一起？

什么是“主”文件以及什么是“着色器”文件？

  

为什么我们必须分开它们？

我们没有。将着色器源字符串烘焙到可执行文件中是完全可能的。 GLSL着色器代码也很有可能在运行时生成（我开发的几个库/中间件就是这样做的）

  

我们应该这样做吗？

主要是为了方便起见。单独的文件更易于修改或更新。哎呀，你甚至可以在它上面添加一个文件系统监视器，以便在它发生变化时获得通知，并在它完成时重新编译着色器。这大大缩短了开发周期。

  

为了让程序运行更快或任何其他原因？

实际上，这只是一个方便的问题。 OpenGL并不关心它。所有OpenGL都希望看到一些有效的GLSL着色器源代码，而且它是一个快乐的露营者。