OpenGL Shading Language 4.60 Specification 読書ノート Part 1

仕様書該当部分

1. Introduction

本文書では OpenGL Shading Language (GLSL) のバージョン 4.60 しか規定していない。これは __VERSION__ に 460 を代入することを要求し、#version に 460 しか受け入れないことを要求している。もし #version がより小さな数字で宣言された場合、受け入れられる言語は前のバージョンであり、API のバージョンやコンテキストの種類によって対処されることになる。

OpenGL Shading Language や OpenGL ES Shading Language の旧バージョンは、特に精度、名前の隠蔽規則、インターフェイス変数の扱いなどについて、ここで指定されるバージョンの厳密な部分集合ではない。各言語の詳細については、その言語のバージョンに対応する仕様書を参照すること。

なお、Vulkan API で使用するために SPIR-V を生成する場合（文献を参照）は、「Vulkan を対象としている」という。

OpenGL Shading Language については、本仕様と OpenGL 仕様が正となっているが、 SPIR-V 生成については SPIR-V 仕様と SPIR-V クライアント API 仕様が正となっている（文献を参照）。

読者ノート

簡単に調べたところ、Vulkan API というのはクロスプラットフォームなグラフィックス API であって、より現代的な仕様であるらしい。

簡単に調べたところ、SPIR-V とは並列計算・グラフィックスの中間言語の一つだとある。たぶん GLSL と似たような概念だと思う。そのわりには「GLSL → SPIR-V コンパイラー」なる文言があり、不安になる。

SPIR-V 生成に対しては SPIR-V クライアント API が SPIR-V シェーダーを操作するための命令を仕様定義している。

独立したオフラインツールチェーンは GLSL を SPIR-V の中間言語にコンパイルする。 SPIR-V の生成は #extension, #version, またはプロファイルによって有効になるわけではない。代わりに、SPIR-V 用の GLSL の使用はオフラインツールチェーンの使用によって決定される。SPIR-V の生成をクライアント API に要求する方法については、そのようなツールの文書を参照すること。

GLSL → SPIR-V コンパイラーは、どの SPIR-V Capabilities が実行時に合法であるかを指示しなければならず、それらの機能以外の GLSL 機能の使用に対してはエラーを与える。これは、フロントエンドが GLSL ソースに存在する組み込み定数に対してエラーチェックできるような、実装依存の制限についても成り立つ。

SPIR-V 能力によって制御されていないが、GLSL でその等価物がある SPIR-V 機能（段階、組み込み関数、型、制限、等々）は、GLSL 等価物を対処する OpenGLドライバーで動作することしか期待されていない。

本仕様書において、OpenGL 仕様とは、他のプロファイルが指定されていない限り、バージョン 4.6 の Core プロファイルのことを指す。

1.1. Changes

読者ノート

本文書は GLSL 4.6 の revision 7 というものらしいので、それまでの変更ログが本節には列挙されている。

1.1.1. Changes from Revision 6 of GLSL 4.6

  • GL_KHR_vulkan_glsl 仕様を取り込んだ。

  • GLSL 機能に関連するので、SPIR-V 機能のドライバーに存在することについて、導入部に注記を追加した。

  • 既定の一様ブロック合致規則のきっかけになるのは同じ location であることを明言した。4.4.3. Uniform Variable Layout Qualifiers 参照。

読者ノート

こんな感じで、これ以降の節ではコミットログのようなものが続く。読み飛ばしても仕様理解に支障はたぶんないだろう。

1.1.2. Changes from Revision 5 of GLSL 4.6

  • 私的 GLSL issue #34: int → uint の暗黙の変換を明示的な構築と同じにすることを明確化、統合した。

  • 私的 GLSL issue #24: barrier() はそれだけで制御フローと shared 変数や細分化制御出力変数へのメモリーアクセスの両方を同期させるのに十分であることを明言した。その他のメモリーアクセスの場合は、追加のメモリーバリアが必要だ。

  • 浮動小数点表現形式の定義について IEEE-754 を規範的に参照した。

  • 私的 GLSL issue #36: double 型の関数 refract では eta 引数が double 型である必要がある。

  • 細分化制御と幾何の段階における入力変数の制限を明言した。

  • 私的 GLSL issue #15: 配列の配列に対する束縛の順序を明言した。

  • 私的 GLSL issue #14: 一様変数は、静的に使用されている場合には、リンク時にだけ合致する必要がある。

  • precise 計算には、制御フローや三項演算子 ?: の制御式は含まれない。

1.1.3. Changes from Revision 4 of GLSL 4.6

  • 私的バグ 13012: 組み込み一様変数が断片段階でしか利用できない場合があることを明言した。

  • 私的バグ 13837: 三項演算子とシーケンス演算子が void 型を操作できるようになった。

  • 前処理に起因するエラーはコンパイル時に返さなければならないことを明言した。

  • 変数のどの部分へのアクセスも静的使用となることを明言した。

  • 私的 GLSL issue 19: switch の最後にあるラベルには文が必要だ。

  • 私的 GLSL issue 26: SPIR-V 用にコンパイルした場合 noise は有効ではない。

  • 私的 GLSL issue 20: 定数値を返す length() 式は、副作用を含んではならない。

  • 公的 OpenGL-API issue 7: 変数を readonly と writeonly の両方で宣言できる。

  • 私的 GLSL issue 16: #line 指令で定数式の使用は未定義だ。

  • float 画像の imageAtomicExchange の戻り値型を訂正した。

  • 私的 GLSL issue 32: length() メソッドの矛盾点を消した：実行時サイズではない配列は、明示的サイズあり配列の length() しか対処しない。

  • 私的 GLSL issue 21: interpolateAt の左辺値の制限を明言した。

  • 私的 OpenGL-API issue 53: location aliasing に対するビット幅の要件を明言した。

  • 公的 GLSL issue 15: gl_in は unsized-array 構文を使って再宣言することができる。

  • DEPTH_COMPONENT と STENCIL_COMPONENT に必要な各種テクスチャーの表現形式を明言した。

  • 4.4. Layout Qualifiers の表に画像表現形式を追加した。

1.1.4. Changes from Revision 3 of GLSL 4.6

私的 GLSL issue 13: allInvocationsEqual() のミススペルを修正。表中のものは anyInvocationsEqual() と誤って記載されていて、他の綴りは正しかった。

1.1.5. Summary of Changes from Revision 7 of GLSL Version 4.50

  • GL_ARB_shader_atomic_counter_ops 拡張を導入した。

  • GL_ARB_shader_draw_parameters 拡張を導入した。

  • GL_ARB_shader_group_vote 拡張を導入した。

  • GL_ARB_gl_spirv 拡張を導入した。

  • 私的バグ 16070: 大域スコープにある余計なセミコロンを許す。

  • 私的 GLSL Issue 5: いくつかの形態のエラーについて、「リンクに失敗する」が実際には「コンパイルエラーまたはリンクエラー」であることを明示する。

  • 私的 GLSL Issue 7: gl_MaxComputeUniformComponents を 1024 に変更。

  • 私的 OpenGL API Issue 35: SPIR-V に対しては透明な個々の一様変数の位置を要求する。

  • 私的 GLSL Issue 8: interpolateAt() interpolant が構造体のメンバーである可能性があることをより明確にする。

  • 私的 GLSL Issue 9: xfb_buffer がブロック配列とどのように相互作用するかを指定する：捕捉バッファーはブロック配列要素ごとにインクリメントする。

1.2. Overview

本書は OpenGL Shading Language バージョン 4.60 について記述する。

読者ノート

ずっと疑問なのだが、バージョンが 4.6 なのか 4.60 なのかはっきりさせてほしい。

この言語で書かれた独立したコンパイル単位をシェーダーと呼ぶ。プログラムとは、API パイプラインを構成するプログラム可能な段階の一つまたはそれ以上を完全に作成しているコンパイルとリンクされたシェーダーの集合だ。単一のプログラム可能段階に対するすべてのシェーダーは同じプログラム内になければならない。プログラム可能段階の完全な集合を単一のプログラムに入れることも、複数のプログラムに分割することもできる。

この文書の狙いは、プログラミング言語を徹底的に仕様にすることだ。規範となる参考文献 (11. Normative References) では、プログラムやシェーダーの操作や通信に使用される API 入場地点を仕様にする。

1.3. Error Handling

一般に、コンパイラーは不正なプログラムをすべて検出することは不可能だ。したがって不正なプログラムを受け入れることがある。移植性が保証されるのは、本仕様書に記載されている整形式のプログラムだけだ。コンパイラーは、不正なプログラムを検出して診断内容を出すことが推奨されるが、すべての場合にそうする必要はない。字句や文法的に正しくないシェーダーについては、コンパイル時にエラーを返さなければならない。その他のエラーは、コンパイル時またはリンク時に報告する。「死にコード」であってもエラーチェックは必要だ。例えば：

if (false)     // changing false to true cannot uncover additional errors
    statement; // statement must be error checked regardless

1.4. Typographical Conventions

本仕様書では、主に読みやすさを向上させるために、イタリック体、ボールド体、およびフォントを選んで使用する。

  • コード片は固定幅のフォントを使用する。

  • テキストに埋め込まれた識別子はイタリック体で表示される。

  • テキストに埋め込まれたキーワードは太字で表示する。

等々。

読者ノート

当ノートでは Sphinx を使っていることと、他のノートとの一貫性を採りたいことから、別の typographical conventions を採用している。

1.5. Deprecation

OpenGL Shading Language ではいくつかの機能が廃止された。そのようなものは本仕様書の中で deprecated と明記されている。これらの機能は、このバージョンの言語ではまだ存在しているが、シェーディング言語の将来のバージョンで削除される可能性がある。 OpenGL API には、廃止された機能の使用を禁止する前方互換モードがある。非推奨機能の使用が禁止されているモードでコンパイルすると、その使用によりコンパイルエラーやリンクエラーが発生する。非推奨の言語機能を受け入れたり、エラーを返したりする原因については、OpenGL の仕様書を参照すること。