您的问题无法真正得到回答，因为它会因驱动程序实现等而异。但是，功能的事实和历史应该是有用的。
EXT_separate_shader_objects 是这个功能的第一个化身。它们之间最大的区别在于：您不能在 EXT 版本中使用用户定义的变量。您必须使用旧的兼容性输入/输出，例如gl_TexCoord.
EXT_separate_shader_objects 规范中的问题 #2 试图证明这种难以理解的疏忽是合理的，解释了以下原因：
从性能的角度来看，尝试支持任意单独着色器的“按名称会合”是不可取的，因为在没有特殊链接步骤的情况下，单独的着色器不会自然地编译以匹配它们不同的同名输入和输出。这种特殊的链接会引入额外的验证开销来绑定单独的着色器。链接本身必须推迟到 glBegin 时间，因为从一组一致的着色器过渡到另一组时，单独的着色器将不匹配。当输入和输出变量的名称匹配但它们的类型不匹配时，此特殊链接仍会产生错误或未定义的行为。
这表明不依赖名称匹配的原因，除了无能之外，还与性能有关（如果你看不出来，我对 EXT_SSO 的评价不高）。“按名称会合”的性能来自于必须在每次绘制调用时执行，而不是能够执行一次。
ARB_separate_shader_objects 将程序集合封装在一个对象中。因此，该对象可以存储所有“集合点”数据。第一次绘制调用可能会较慢，但随后使用同一 PPO 会很快，只要您不将新程序附加到它。
所以我会以此为证据，证明 PPO 应该在其上设置程序，然后不理会。通常，应尽可能避免修改附件对象。这就是为什么我们鼓励您不要在 FBO 中添加或删除纹理/渲染缓冲区。