2013-04-07 99 views
0

我探索相对较新的功能GL_ARB_separate_program_object.What我了解我必须建立一个管道对象应包含从中通过 glUseProgramStagesOpenGL的独立程序阶段

映射到那里阶段着色器这让我想想2使用多个着色器的可能性:

1.创建具有变体的多个管道Vertex/Fragment着色器将来自一次映射到每个管道的耦合(现在不使用其他着色器类型)。

2.创建一个管道,在运行时切换使用

glUseProgramStages 

我最关注的performance.Which的选择是更明智的性能映射到不同的着色器?

+0

你有没有测量过?另外,我认为你应该存储管道对象,因为它们相对便宜,不是吗? – 2013-04-07 11:17:25

+0

我今天实现了这个系统,看到没有性能下降。但需要了解频繁更新管道对象是否会产生影响 – 2013-04-07 21:05:13

回答

1

你的问题不能真正回答,因为它会随着驱动程序的实现等而变化。然而,功能的事实和历史应该是信息性的。

EXT_separate_shader_objects是此功能的第一个化身。它们之间最大的区别是:你不能在EXT版本中使用用户定义的变化。你必须使用旧的兼容性输入/输出,如gl_TexCoord

Issue #2 in the EXT_separate_shader_objects specification 试图证明这种难以理解的监督 解释这样做的理由如下:

这是从性能的角度不良企图“按名称交会”以支持,因为单独的任意单独着色器着色器将不会自然编译,以便在没有特殊链接步骤的情况下匹配其相同名称的不同输入和输出。这种特殊的链接会引入额外的验证开销来绑定单独的着色器。链接本身必须被推迟到glBegin时间,因为当从一组一致的着色器转换到另一个着色器时,单独的着色器不匹配。当输入和输出变化名称匹配但它们的类型不匹配时,此特殊链接仍会产生错误或未定义的行为。

这表明理由不依靠名字匹配 ,除了无能, 是性能相关的(如果你不能告诉,我不觉得很高EXT_SSO的)。 “按名称集合”的表现来自于每次平局时都必须做到,而不是只能做一次。

ARB_separate_shader_objects将程序集合封装在一个对象中。因此,该对象可以存储所有的“集合点”数据。第一次绘制调用可能会比较慢,但只要您不附加新程序,相同PPO的后续使用将会很快。

因此,我会以此为证据,证明PPO应该在其上设置程序,然后单独留下。一般来说,应尽可能避免修改附件对象。这就是为什么你被鼓励不去添加或删除FBO的纹理/渲染缓冲区的原因。

+1

因此,用简单的话说 - “根据需要创建管线,并在这些管线之间切换,而不是每次需要更改新的着色器组合时都进行更改”。是什么意思? – 2013-04-07 14:29:00