我需要一个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在片段中读取它们。
它有效，很好......但是......我的意思是...... cmon，真的吗？
我能理解这一切背后的理由，但对我来说这似乎是一个糟糕的解决方法。 如果它们都在同一个程序管道中工作，那么没有其他方法可以让不同程序的不同着色器相互通信？
答案 0 :(得分：4)
让我们首先解决这个问题：你所读到的内容并不适用于扩展/核心功能。接下来是如果它在规范中是如何不正确的解释，以及为什么在这个规范中出现错误的行。
阅读扩展规范时，请务必注意以下几点之间的区别：
扩展程序的描述性文本包含“概述”部分。
规范性文本，解释它如何运作的部分，由“新程序和功能”，“新标记”部分以及表格的任何部分“添加/更改......规范”定义。
其他一切都是元文本。但尤其是“问题”部分。该部分解释了规范中做出的决定背后的一些推理。你引用的内容来自“问题”部分。它不具有约束力，因此与实际功能无关。
现在，您可能想知道在这种情况下，决策背后的推理如何是错误的。为什么“问题”部分会对扩展内容明显错误提出事实主张？
嗯，这可以追溯到有关此扩展规范的两个事实。
它基于名为GL_EXT_separate_shader_objects的旧扩展程序。在那个扩展名中，上面的陈述是真的。您无法对可分离的程序使用用户定义的变换。那是因为该扩展完全是由NVIDIA编写的，他们真的只是拼凑了一些废话，足以满足一些用户的需求。这不是一个真正的解决方案，更多的是一个止损。
将此扩展程序规范放在一起时，ARB非常懒惰。实际上这是多么懒惰，这实际上是荒谬的。例如，问题2从EXT版本复制 verbatum ，即使引用的部分在ARB版本中绝对不正确。
阅读其他一些问题就像钻研偏执型精神分裂症的思想一样。他们提出其他非事实性主张，然后立即自相矛盾。就像在ARB的会议上有一个环形座位或其他东西。功能（大部分）都很好;这是扩展规范本身就是垃圾。
我理解你的沮丧。我从扩展中了解某个功能的一般方法是阅读概述，然后跳到问题。概述让我对它应该做的事情有了一个很好的了解，而问题部分让我对实现的内容有了一个很好的了解。所有这一切都无需通过“规范语言”解析。
您无法使用此扩展程序执行此操作。问题部分比无价值更糟糕;这是积极的误导。你必须阅读规范语言。