我正在探索相对较新的功能 GL_ARB_separate_program_object。我理解的是我必须创建一个管道对象，该对象应该包含来自阶段的着色器，这些着色器通过映射到那里 glUseProgramStages
这让我想到了使用多个着色器的两种可能性：
1.使用来自一次映射到每个管道的变体顶点/片段着色器对（暂时不使用其他着色器类型）创建多个管道。
2.创建单个管道并在运行时使用
将映射切换到不同的着色器glUseProgramStages
我最关心的是性能。哪个选项更适合性能？
【问题讨论】：
您的问题无法真正得到回答，因为它会因驱动程序实现等而异。但是，功能的事实和历史应该提供信息。
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 中添加或删除纹理/渲染缓冲区。
【讨论】：