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 回答