2

vec4 と float を頂点シェーダーからジオメトリ シェーダー、さらにフラグメント シェーダーに渡す必要があります。3 つのシェーダーは、均一性を維持するために 3 つの異なるプログラムに属し、必要に応じてジオメトリ シェーダーがアタッチ/デタッチされた単一のプログラム パイプラインに 3 つが集められます。

GL_ARB_separate_shader_object 拡張機能は次のように述べています。

GLSL には、さまざまな出力変数を後続のシェーダーのさまざまな入力変数に接続するための「名前によるランデブー」モデルがあります。個別のシェーダーでは、前のシェーダーが特定のユーザー定義の入力可変変数を書き込むかどうかは保証されません。HLSL9、Cg、および OpenGL アセンブリ拡張プログラムは、この状況を「API リソースによるランデブー」モデルで処理します。GLSL の用語では、これは個別の GLSL シェーダーが、ユーザー定義の可変変数ではなく、組み込みの可変変数によって通信する/必要がある/通信することを意味します。

頂点シェーダーとジオメトリ シェーダーでは、vec4 に gl_FrontColor を使用し、float に gl_FogFragCoord を使用し、gl_FogFragCoord と gl_Color を介してフラグメントでそれらを読み取りました。

それはうまく動作します..しかし..つまり..cmon、本当に？

このすべての背後にある理論的根拠は理解できますが、それは本当にくだらない回避策のように思えます。すべてが同じプログラム パイプラインで動作する場合、異なるプログラムの異なるシェーダーが互いに通信するようにする他の方法はありませんか?

4

1 に答える 1

4

最初にこれを片付けましょう: あなたが読んだことは、その拡張機能/コア機能には当てはまりません。以下は、それが仕様にある場合にそれが正しくない理由と、なぜこの仕様に間違った行があるのか​​についての説明です。

拡張機能の仕様を読むときは、次の違いに注意することが重要です。

  • 規範的なテキスト: これは、拡張機能が実際にどのように機能するかを定義します。これが本文の肝です。
  • 説明テキスト: これは、機能の目的に関する拘束力のない概要を示します。これは拘束力がなく、実際の規範テキストがそれに反する可能性があることを意味します。
  • メタテキス​​ト: これは、規範的なテキストの背後にある理由を説明しています。また、ヘッダーとフッターの情報 (拡張機能の作成者、公開日など) も表します。

拡張機能の説明テキストは、「概要」と呼ばれるセクションで構成されています。

すべてがどのように機能するかを説明する部分である規範テキストは、セクション「新しい手順と機能」、「新しいトークン」、およびフォームのセクション「仕様への追加/変更」によって定義されます。

それ以外はすべてメタテキス​​トです。しかし、特に「問題」セクション。そのセクションでは、仕様で行われた決定の背後にある理由のいくつかを説明します。あなたが引用したものは、「問題」セクションからのものです。これは拘束力がないため、実際の機能には関係ありません。

さて、この場合、決定の背後にある理由がどのように間違っているのか疑問に思うかもしれません. 問題セクションが、明らかに誤りである拡張機能の内容について事実に基づく主張を行うのはなぜですか?

さて、それはこの拡張仕様に関する 2 つの事実に戻ります。

  1. GL_EXT_separate_shader_objectsと呼ばれる古い拡張機能に基づいています。その拡張では、上記のステートメントは真実でした。分離可能なプログラムでは、ユーザー定義の変数を使用できませんでした。これは、その拡張機能が NVIDIA によって完全に作成されたためであり、一部のユーザーのニーズを満たすのに十分なナンセンスを組み合わせただけです。それは本当の解決策ではなく、一時しのぎでした。

  2. ARB は、この拡張機能の仕様をまとめるのに驚くほど怠惰でした。これがどれほど怠惰に構築されたかは、実際にはばかげています。たとえば、第 2 号は、ARB 版では引用部分が完全に間違っているにもかかわらず、EXT 版から逐語的にコピーされています。

    他の問題のいくつかを読むことは、偏執狂的な統合失調症患者の心を掘り下げるようなものです. 彼らは他の事実に反する主張をし、すぐに矛盾します。それは、ARB のミーティングか何かのリングサイドの席に座っているようなものです。機能は（ほとんど）問題ありません。ジャンクなのは拡張仕様そのものです。

私はあなたの不満を理解しています。拡張機能から機能について学ぶための私の一般的な方法は、概要を読んでから問題にスキップすることです。概要では、何をすべきかについての良いアイデアが得られ、問題セクションでは、実装がどのように見えるかについての良いアイデアが得られます。「仕様言語」を介して解析する必要はありません。

この拡張機能ではこれを行うことはできません。問題セクションは無価値よりも悪いです。それは積極的に誤解を招くものです。仕様言語を読む必要があります。

于 2012-01-20T08:34:54.007 に答える