2

我需要一个 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，真的吗？

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

4

1 回答 1

4

让我们首先解决这个问题：您在那里读到的内容与该扩展/核心功能不符。以下是对如果它在规范中的不正确的解释，以及为什么在本规范中出现错误的行。

阅读扩展规范时，请务必注意以下内容之间的区别：

  • 规范性文本：这定义了扩展的实际工作方式。这是文本的肉。
  • 描述性文本：这给出了功能用途的非约束性概述。它不具有约束力，这意味着实际的规范性文本可能与之相反。
  • 元文本：这解释了规范文本背后的推理。它还表示页眉和页脚信息（谁编写了扩展，发布日期等）。

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

规范性文本，解释它如何工作的部分，由“新过程和功能”、“新令牌”部分以及表格的任何部分“对……规范的添加/更改”定义。

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

现在，您可能想知道在这种情况下，决策背后的推理怎么可能是错误的。为什么“问题”部分会对明显错误的扩展内容做出事实声明？

好吧，这可以追溯到关于这个扩展规范的两个事实。

  1. 它基于一个名为GL_EXT_separate_shader_objects的旧扩展。在那个扩展中，上述陈述是正确的。您不能将用户定义的变量与可分离的程序一起使用。那是因为该扩展完全是由 NVIDIA 编写的，他们实际上只是拼凑了一些足以满足某些用户需求的废话。这不是一个真正的解决方案，更多的是权宜之计。

  2. ARB非常懒惰地把这个扩展规范放在一起。这实际上是荒谬的，这是多么懒惰。例如，问题 2 是从 EXT 版本中逐字复制的，即使引用的部分在 ARB 版本中绝对不正确。

    阅读其他一些问题就像钻研偏执型精神分裂症的思想。他们提出其他非事实的主张，然后立即自相矛盾。这就像在 ARB 的会议或其他事情上拥有一个席位。功能（大部分）很好；扩展规范本身就是垃圾。

我理解你的沮丧。我从扩展中了解功能的一般方法是阅读概述，然后跳到问题。概述让我很好地了解了它应该做什么，问题部分让我很好地了解了实现的样子。所有这些都无需通过“规范语言”进行解析。

您无法使用此扩展程序执行此操作。问题部分比一文不值更糟糕；这是积极的误导。您必须阅读规范语言。

于 2012-01-20T08:34:54.007 回答