程序流水線着色器變量交換

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語言」解析。

你不能用這個擴展名做到這一點。問題部分比毫無價值更糟糕;這是積極的誤導。你必須閱讀規範語言。