GLSL多个着色程序VS制服开关

Question

我正在研究着色器管理器架构,我有几个问题需要更高级的人员.我目前的选择反对两种设计:

1.每个材质着色器程序

=>为程序中使用的每种材质创建一个着色器程序.

潜在的缺点:

• 考虑到每个对象可能都有自己的材质,它涉及很多glUseProgram调用.
• 意味着创建了许多着色器程序对象.
• 更复杂的架构#2.

优点:

• 可以专门为材料中使用的每个"选项"生成着色器代码.
• 如果我没错,制服必须只设置一次(创建着色器程序时).

2.全局着色器程序

=>为每个着色器功能(闪电,反射,视差映射......)创建一个着色器程序,并根据要渲染的材质使用配置变量启用或放弃选项.

潜在的缺点:

• 每帧必须多次更换制服.

优点:

• 较低的着色器程序计数.
• 减少SP swich(glUseProgram).

您可能会注意到我目前的趋势是#1,但我想知道您对此的看法.

• 初始制服设置是否会抵消glUseProgram呼叫开销(我不是特别速度怪胎)？
• 在#1的情况下,对于任何内存或性能考虑,我应该在创建SP时只调用一次glLinkProgram,还是每次调用glUseProgram时都必须取消链接/链接？
• 有更好的解决方案吗？

谢谢!

Answer 1

让我们来看看#1:

考虑到每个对象可能都有自己的材质,它涉及很多glUseProgram调用.

真的,这不是什么大不了的事.交换程序很难,但你也在交换纹理,所以它并不像你没有改变重要的状态.

意味着创建了许多着色器程序对象.

这会受到伤害.实际上,#1的主要问题是着色器的爆炸性组合.虽然ARB_separate_program_objects会有所帮助,但它仍然意味着你必须编写很多着色器,或者想出一种不写很多着色器的方法.

或者您可以使用延迟渲染,这有助于缓解此问题.其众多优点之一是它将材料数据的生成与将该材料数据转换为光反射(颜色)的计算分开.因此,您可以使用更少的着色器.您有一组生成材质数据的着色器,以及一个使用材质数据进行光照计算的集合.

所以我想说#1使用延迟渲染.

Answer 2

这实际上取决于您的硬件和应用程序的特定需求.

#2的另一个问题是,你的着色器通常最终效率不高,因为它必须根据你传入的制服进行一些条件分支.所以你基本上在较少的时间切换状态和着色器中降低的吞吐量之间进行权衡.这取决于哪一个更糟糕.

你绝对应该每个着色器只调用一次glLinkProgram.编译着色器比切换已编译的着色器需要更长的时间.

没有更好的解决方案.几乎所有编写渲染引擎的人都必须做出你所面临的决定.