程序流水线着色器变量交换

Question

我需要一个vec4和一个浮点数从顶点着色器传递到几何着色器，然后到片段着色器。 3个着色器属于3个不同的程序，以便保持统一的唯一性，并且3个被收集在单个程序流水线中，并根据需要附加/分离几何着色器。

的GL_ARB_separate_shader_object扩展说：

GLSL有一个“按名称交会”为不同的输出变量连接到不同的后续着色器的输入变量模型。对于单独的着色器，无法保证前面的着色器是否会写入给定的用户定义的输入变量。 HLSL9，Cg和OpenGL程序集扩展程序通过“API资源集合”模型处理这种情况。 在GLSL术语中，这意味着单独的GLSL着色器/必须/通过内置变量变量而不是用户定义的变量变量进行通信。

细，在顶点和几何着色器我用gl_FrontColor为vec4，和gl_FogFragCoord浮子，在经由gl_FogFragCoord和gl_Color片段读取它们。

It works，fine .. but ..我是说.. cmon，真的吗？

我可以理解所有这些背后的基本原理，但它对我来说确实是一个糟糕的解决方法。 真的没有其他方法可以使不同程序的不同着色器相互通信，如果它们全部在相同的程序管道中工作的话？

Answer 1

让我们先把它摆在第一位：你读到的东西并不是真的那个扩展/核心功能。接下来是如何解释它是否属于规范，以及为什么在这个规范中不正确的行。

当读取扩展规范，一定要注意以下之间的区别是很重要的：

• 规范性文本：定义扩展的实际工作原理。这是文本的肉。
• 描述性文本：这提供了一个非约束性的功能概述。它没有约束力，这意味着实际的规范性文本可能会违背它。
• 元文本：这解释了规范文本背后的推理。它也代表页眉和页脚信息（谁写了扩展名，它发布的日期等）。

扩展的描述性文本由名为“概述”的部分组成。

规范性文本，解释它如何工作的部分，由“新程序和函数”，“新标记”以及表单的任何部分“添加/更改...规范”。

其他一切都是元文本。但尤其是的“问题”部分。该部分解释了规范中做出的决定背后的一些推理。您引用的内容来自“问题”部分。它没有约束力，因此与实际功能无关。

现在，您可能想知道在这种情况下，决策背后的推理是错误的。问题部分为什么会对扩展名的内容做出实质性声明？那么，这可以回到关于这个扩展规范的两个事实上。

1. 它基于名为GL_EXT_separate_shader_objects的较旧的扩展名。在即的扩展中，上述说法属实。您无法使用用户定义的可变程序进行变化。那是因为这个扩展完全是由NVIDIA编写的，他们真的只是拼凑了一些足以满足用户需求的废话。这不是一个真正的解决方案，更多的是阻碍。

2. 该ARB是惊人地懒惰把这个扩展规范放在一起。这是如何懒散地构建这实际上是荒谬的。例如，问题2从EXT版本复制verbatum，即使ARB版本中带引号的部分绝对不正确。

   阅读其他一些问题就像深入研究偏执型精神分裂症患者的思维。他们做出其他非事实性的主张，然后立即自相矛盾。这就像在ARB的会议上有一个环形座位或什么的。功能（大部分）很好;这是扩展规范本身就是垃圾。

我明白你的失望。我从扩展中学习功能的一般方法是阅读概述，然后跳到问题。概述给了我一个它应该做什么的好主意，问题部分给了我一个关于实现的样子的好主意。所有这些都不需要通过“spec语言”解析。

你不能用这个扩展名做到这一点。问题部分比毫无价值更糟糕;这是积极的误导。你必须阅读规范语言。