c++ - 在图形应用程序中,为什么着色器会在运行时加载到应用程序中?

标签 c++ performance opengl glsl shader

用例如 GLSL 编写的着色器通常在运行时加载到图形应用程序中。我想知道为什么不只用着色器编译应用程序,这样以后就不必加载它们了。像这样:

#define glsl(version, glsl) "#version " #version "\n" #glsl

namespace glsl { namespace vs {
//VERTEX SHADERS
//=========================
// simple VS
//=========================
constexpr GLchar * const simple = glsl(450 core, 
    layout(location = 0) in vec3 position;

    void main() {
        gl_Position = vec4(position, 1.0f);
    }
    );

} namespace fs {
//FRAGMENT SHADERS
//=========================
// simple FS
//=========================
constexpr GLchar * const simple = glsl(450 core,
    out vec4 color;

    void main() {
        color = vec4(1.0f, 0.0f, 0.0f, 1.0f);
    }       
    );

} }

我认为这不会导致 exe 文件太大而且会加快加载时间;除非我弄错了一个典型的图形应用程序使用了多少着色器。我知道您可能想在编译后更新着色器,但这真的发生了吗?

有什么理由我不想这样做吗?

最佳答案

几个原因:

  • 在开发过程中,无需重新启动应用程序即可“热加载”着色器非常方便,因此您可以在调试或性能调整时进行更改并立即查看结果。当着色器存储为单独的文件时,这会更简单。
  • 如评论中所述,根据您的平台,将着色器从高级着色语言预编译为中间字节代码表示或实际最终 GPU 代码(例如,在 GPU 硬件是固定目标)。着色器编译可能非常耗时,因此最好离线进行,而不是尽可能在运行时进行。
  • 您采用的方法实际上在小型/简单应用程序中并不少见,您的应用程序越大,您需要管理的着色器越多,这种方法就越痛苦。就我个人而言,即使是小型个人项目,我也希望能够热加载着色器。
  • 这实际上是一个比着色器更普遍的问题。在任何项目中,您都可以选择何时将资源嵌入可执行文件(直接嵌入源代码或通过单独的构建步骤,如 Windows Resources)或将它们存储为单独的文件。这两种方法各有利弊,但嵌入的主要优点是应用程序可能需要的所有资源都嵌入到可执行文件中,因此您不必担心/处理可能丢失的资源。不利之处在于,如果您将所有内容都塞进可执行文件中(尤其是对于具有许多大型 Assets 的项目,例如游戏),那么您会增加构建时间,使热加载变得困难,并可能使 Assets 组织问题更加困难。

关于c++ - 在图形应用程序中,为什么着色器会在运行时加载到应用程序中?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/43769134/

相关文章:

c++ - 外部 "C"全局变量的外部声明

javascript - 实例化对象而不将它们存储在变量中

javascript - polymer 元素加载速度非常慢

c - 删除 GLUT 函数调用

c++ - 如何更新迭代(for 循环)求解器中的粒子位置

c++ - 如何从 Vim 编译和运行 C++ 程序?

c++ - 查找总和等于 k ​​的子集的数量

performance - 更快的素数生成 C#

c++ - OpenGL,达到目标后如何禁用 glutSpecialFunc?

c++ - Valarray 和自定义分配器