WebGPU シェーディング言語

1. 序論

WebGPU シェーディング言語（WGSL）は、[WebGPU] 用のシェーダー言語です。 つまり、WebGPU API を使用するアプリケーションは、GPU 上で実行されるシェーダーと呼ばれるプログラムを WGSL を使用して表現します。

// テクスチャーが適用されたジオメトリーを点光源で照らすフラグメントシェーダー。

// ストレージバッファーバインディングからの光源。
struct PointLight {
  position : vec3f,
  color : vec3f,
}

struct LightStorage {
  pointCount : u32,
  point : array<PointLight>,
}
@group(0) @binding(0) var<storage> lights : LightStorage;

// テクスチャーとサンプラー。
@group(1) @binding(0) var baseColorSampler : sampler;
@group(1) @binding(1) var baseColorTexture : texture_2d<f32>;

// 関数の引数は頂点シェーダーからの値。
@fragment
fn fragmentMain(@location(0) worldPos : vec3f,
                @location(1) normal : vec3f,
                @location(2) uv : vec2f) -> @location(0) vec4f {
  // テクスチャーからサーフェスの基本色をサンプリングする。
  let baseColor = textureSample(baseColorTexture, baseColorSampler, uv);

  let N = normalize(normal);
  var surfaceColor = vec3f(0);

  // シーンの点光源を反復処理する。
  for (var i = 0u; i < lights.pointCount; i++) {
    let worldToLight = lights.point[i].position - worldPos;
    let dist = length(worldToLight);
    let dir = normalize(worldToLight);

    // この光源によるサーフェス色への寄与を求める。
    let radiance = lights.point[i].color * (1 / pow(dist, 2));
    let nDotL = max(dot(N, dir), 0);

    // サーフェス色に光源の寄与を累積する。
    surfaceColor += baseColor.rgb * radiance * nDotL;
  }

  // 累積したサーフェス色を返す。
  return vec4(surfaceColor, baseColor.a);
}

1.1. 概要

WebGPU は、GPU コマンドの形式で作業単位を GPU に発行します。 WGSL は、次の2種類の GPU コマンドに関係します。

• 描画コマンドは、 レンダー パイプラインを 入力、出力、および接続されたリソースのコンテキストで実行します。

• ディスパッチ コマンドは、コンピュートパイプラインを 入力および接続されたリソースのコンテキストで実行します。

どちらの種類のパイプラインも、WGSL で記述されたシェーダーを使用します。

シェーダーは、 パイプライン内のシェーダー ステージを実行する WGSL プログラムの一部分です。 シェーダーは、次の要素で構成されます。

• エントリーポイントの関数。

• エントリーポイントから始まる、呼び出されるすべての関数の推移閉包。 この集合には、ユーザー定義関数と組み込み関数の両方が含まれます。 （より厳密な定義については、「シェーダーステージ内の関数」を参照してください。）

• これらすべての関数によって静的にアクセスされる変数および定数の集合。

• これらすべての関数、変数、および定数の定義または解析に使用される型の集合。

注記: WGSL プログラムにエントリーポイントは必須ではありませんが、 エントリーポイントは GPUProgrammableStage の作成に必要なため、そのようなプログラムを API で実行することはできません。

シェーダーステージを実行するとき、実装は次の処理を行います。

• モジュールスコープで宣言された定数の値を計算します。

• リソースを シェーダーのリソースインターフェイス内の変数にバインドし、 実行中にシェーダーがそれらのリソースの内容を利用できるようにします。

• その他のモジュールスコープ変数のためにメモリを割り当て、 指定された初期値をそのメモリに設定します。

• エントリーポイントの仮引数が存在する場合は、シェーダーステージの入力を設定します。

• エントリーポイントの戻り値が存在する場合は、シェーダーステージの出力に接続します。

• その後、エントリーポイントを呼び出します。

WGSL プログラムは、次の要素で構成されます。

• モジュールレベルの動作制御を指定するディレクティブ。

• 実行動作を指定する関数。

• 宣言または実行可能な動作の単位である文。

• 純粋な数学的値のテキスト表現であるリテラル。

• それぞれが特定の時点で計算される値に名前を与える定数。

• それぞれが値を保持するメモリに名前を与える変数。

• それぞれが一連の値を組み合わせて結果値を生成する式。

• それぞれが次の内容を記述する型。

  • 値の集合。

  • サポートされる式に対する制約。

  • それらの式のセマンティクス。

• オブジェクトを変更し、次のような追加情報を指定する属性。

  • エントリー ポイントに対するインターフェイスの指定。

  • 診断フィルターの指定。

注記: 現在、WGSL プログラムは単一の WGSL モジュールから構成されます。

WGSL は命令型言語です。動作は、実行する文のシーケンスとして指定されます。 文では、次のことを行えます。

• 定数または変数を宣言する。

• 変数の内容を変更する。

• 構造化プログラミング構文を使用して実行順序を変更する。

  • 選択的な実行: if（任意の else if および else 節を伴う）、switch。

  • 反復: loop、while、for。

  • 入れ子になった実行構文からの脱出: continue、break、break if。

  • リファクタリング: 関数呼び出しおよびreturn。

• 上記の動作の一部として式を評価し、値を計算する。

• 定数式に対する前提条件を、シェーダー作成時に検査する。

WGSL は静的型付け言語です。特定の式によって計算される各値は、 プログラムソースを調べることだけで決定される特定の型に属します。

WGSL には、ブール値および数値 （整数と浮動小数点数）を記述する型があります。 これらの型は、複合型 （ベクトル、行列、 配列、および構造体）に集約できます。 WGSL には、固有の操作を提供する特殊な型（例: アトミック型）があります。 WGSL では、メモリに格納できる型をメモリビューとして記述します。 WGSL は、一般的に使用されるレンダリング型を テクスチャーおよびサンプラーの形式で提供します。 これらの型には、グラフィックスレンダリングで一般的に提供される GPU ハードウェアの機能を公開する 組み込み関数が関連付けられています。

WGSL の暗黙的な変換および昇格は非常に限定されています。 引数として関数呼び出しに渡される抽象型およびバッファーポインターからの暗黙的な変換と昇格のみを提供します。 ある具象数値型またはブール型の値から別の型への変換には、 明示的な変換、 値コンストラクター、または ビットの 再解釈が必要です。ただし、WGSL はスカラー型から ベクトル型への昇格について、限定的な機能を提供します。 これは、複合型にも適用されます。

シェーダーステージの作業は1つ以上の呼び出しに分割されます。 各呼び出しは、わずかに異なる条件下でエントリーポイントを実行します。 シェーダーステージ内の呼び出しは、特定の変数へのアクセスを共有します。

• ステージ内のすべての呼び出しは、シェーダーインターフェイス内のリソースを共有します。

• コンピュート シェーダーでは、同じ ワークグループ内の呼び出しが、 ワークグループアドレス空間内の変数を共有します。 異なるワークグループ内の呼び出しは、それらの変数を共有しません。

ただし、呼び出しは、同等の呼び出しから区別するための識別値を提供する組み込み入力を含む、 異なるシェーダーステージ入力の集合に作用します。 各呼び出しは、プライベートおよび関数アドレス空間内の 変数という形式で、独立した固有のメモリ空間を持ちます。

シェーダーステージ内の呼び出しは並行して実行され、多くの場合は並列に実行されます。 シェーダー作成者は、シェーダーステージ内の呼び出しの動的な動作が 次の条件を満たすようにする責任があります。

• テクスチャーサンプリングおよび制御バリアを含む、特定のプリミティブ操作の 均一性要件を満たす。

• データ競合を回避するため、共有変数への競合する可能性のあるアクセスを調整する。

WGSL では、特定の機能について複数の動作が許容されることがあります。 異なる実装が異なる動作を示す可能性があるため、これは移植性上の危険となります。 WGSL の設計は、そのような場合を最小限に抑えることを目指していますが、実現可能性と、 幅広いデバイスで高いパフォーマンスを達成するという目標による制約を受けます。

動作 要件は、WGSL プログラムを処理または実行するときに実装が 行うアクションです。プログラマーとの契約における 実装の義務を記述します。 この仕様では、これらの義務が明白でない可能性がある場合に、それらを明示的に記述します。

1.2. 構文表記

次の構文表記は、WGSL の構文文法の規約を記述します。

• 規則の両側にある斜体テキストは、構文規則を示します。

• 規則の右辺にある、一重引用符（'）で始まり終わる太字の等幅テキストは、 キーワードおよびトークンを示します。

• 通常のテキスト内のコロン（:）は、構文規則を登録します。

• 通常のテキスト内の縦棒（|）は、選択肢を示します。

• 通常のテキスト内の疑問符（?）は、直前のキーワード、トークン、規則、 またはグループが0回または1回出現すること（任意であること）を示します。

• 通常のテキスト内のアスタリスク（*）は、直前のキーワード、トークン、規則、またはグループが 0回以上出現することを示します。

• 通常のテキスト内のプラス（+）は、直前のキーワード、トークン、規則、またはグループが 1回以上出現することを示します。

• 通常のテキスト内の左丸括弧（(）と右丸括弧 （)）の対応する組は、要素のグループを示します。

1.3. 数学用語と表記

角度:

• 慣例により、角度はラジアンで測定されます。

• 角度を測定するための基準半直線は、原点 (0,0) から (+∞,0) に向かう半直線です。

• 比較対象の半直線と基準半直線がなす角度を θ とします。 比較対象の半直線が反時計回りに移動すると、θ は増加します。

• 完全な円には 2 π ラジアンがあります。

• 例:

  • 角度 0 は原点から右方向の (1,0) を指します

  • 角度 2π は原点から右方向の (1,0) を指します

  • 角度 π/4 は原点から点 (1,1) を指します

  • 角度 π/2 は原点から点 (0,1) を指します

  • 角度 π は原点から点 (-1,0) を指します

  • 角度 (3/2)π は原点から点 (0,-1) を指します

双曲角は、 従来の意味での角度ではなく、単位を持たない面積です。 具体的には、次のとおりです。

• x > 0 に対する双曲線 x² - y² = 1 を考えます。

• R を、原点から双曲線上の点 (x, y) までの半直線とします。

• a を、R、x 軸、および双曲線の曲線 自体によって囲まれる面積の2倍とします。

• R が x 軸より上にある場合は a を正、 下にある場合は負とみなします。

このとき、面積 a は、x が a の双曲線余弦となり、 y が a の双曲線正弦となるような双曲角です。

正の無限大は +∞ で表され、すべての実数より真に大きい一意の値です。

負の無限大は −∞ で表され、すべての実数より真に小さい一意の値です。

拡張実数 （アフィン拡張実数とも呼ばれる）は、実数に +∞ と −∞ を加えた集合です。 コンピューターは、両方の無限大の値を含む拡張実数を近似的に表現するために 浮動小数点型を使用します。 § 15.7 浮動小数点評価を参照してください。

区間は、 下限と上限を持つ連続した数の集合です。 文脈に応じて、整数、浮動小数点数、実数、または拡張実数の集合となります。

• 閉区間 [a,b] は、a ≤ x ≤ b を満たす数 x の集合です。

• 半開区間 [a,b) は、a ≤ x < b を満たす数 x の集合です。

• 半開区間 (a,b] は、a < x ≤ b を満たす数 x の集合です。

床式は、 拡張実数 x に対して次のように定義されます。

• ⌊ +∞ ⌋ = +∞

• ⌊ −∞ ⌋ = −∞

• 実数 x について、⌊x⌋ = k。ここで k は、 k ≤ x < k+1 を満たす一意の整数です

天井 式は、拡張実数 x に対して次のように定義されます。

• ⌈ +∞ ⌉ = +∞

• ⌈ −∞ ⌉ = −∞

• 実数 x について、⌈x⌉ = k。ここで k は、 k-1 < x ≤ k を満たす一意の整数です

truncate 関数は、 拡張実数 x に対して次のように定義されます。

• truncate(+∞) = +∞

• truncate(−∞) = −∞

• 実数 x について、その絶対値が x の絶対値以下である 最も近い整数を計算します。

  • x ≥ 0 の場合は truncate(x) = ⌊x⌋、それ以外の x < 0 の場合は ⌈x⌉。

roundUp 関数は、 正の整数 k および n に対して次のように定義されます。

• roundUp(k, n) = ⌈n ÷ k⌉ × k

roundDown 関数は、 正の整数 k および n に対して次のように定義されます。

• roundDown(k, n) = ⌊n ÷ k⌋ × k

転置は、 c 列 r 行の行列 A の行を A^T の列としてコピーすることによって形成される、r 列 c 行の行列 A^T です。

• transpose(A) = A^T

• transpose(A)_i,j = A_j,i

列ベクトルの転置は、列ベクトルを1行の行列として解釈することによって定義されます。 同様に、行ベクトルの転置は、行ベクトルを1列の行列として解釈することによって定義されます。

2. WGSL モジュール

WGSL プログラムは、単一の WGSL モジュールで構成されます。

モジュールは、任意のディレクティブのシーケンスと、それに続くモジュールスコープの宣言およびアサーションです。 モジュールは、次の要素で構成されます。

• モジュールレベルの動作制御を指定するディレクティブ。

• 実行動作を指定する関数。

• 宣言または実行可能な動作の単位である文。

• 純粋な数学的値のテキスト表現であるリテラル。

• それぞれが値を保持するメモリに名前を与える変数。

• それぞれが特定の時点で計算される値に名前を与える定数。

• それぞれが一連の値を組み合わせて結果値を生成する式。

• それぞれが次の内容を記述する型。

  • 値の集合。

  • サポートされる式に対する制約。

  • それらの式のセマンティクス。

• オブジェクトを変更し、次のような追加情報を指定する属性。

  • エントリー ポイントに対するインターフェイスの指定。

  • 診断フィルターの指定。

2.1. シェーダーのライフサイクル

WGSL プログラムと、それに含まれる可能性のあるシェーダーのライフサイクルには、4つの主要なイベントがあります。 最初の2つは、WGSL プログラムを実行するために準備する際に使用される WebGPU API メソッドに 対応します。 最後の2つは、シェーダーの実行の開始と終了です。

イベントは次のとおりです。

1. シェーダーモジュール の作成

   • これは、 WebGPU createShaderModule() メソッドが 呼び出されたときに発生します。 この時点で、WGSL プログラムのソーステキストが提供されます。

2. パイプライン の作成

   • これは、 WebGPU createComputePipeline() メソッド または WebGPU createRenderPipeline() メソッドが 呼び出されたときに発生します。 これらのメソッドは、以前に作成された1つ以上のシェーダーモジュールを、その他の 構成情報とともに使用します。

   • GPUProgrammableStage の指定されたエントリーポイントのシェーダーを形成するコードのみが、 パイプラインの作成中に考慮されます。 つまり、エントリーポイントに関係のないコードは、コンパイル前に実質的に除去されます。

   • 注記: 各シェーダーステージは 個別にコンパイルされるとみなされるため、 モジュールの異なる部分が含まれる可能性があります。

3. シェーダー 実行の開始

   • これは、描画コマンドまたはディスパッチコマンドが GPU に発行され、 パイプラインの実行を開始し、 シェーダーステージのエントリーポイント関数を呼び出したときに発生します。

4. シェーダー実行 の終了

   • これは、シェーダー内のすべての作業が完了したときに発生します。

     • そのすべての呼び出しが終了し、

     • リソースへのすべてのアクセスが完了し、

     • 出力が存在する場合、それが後続のパイプラインステージに渡されます。

イベントの順序は、次の理由によって決まります。

• データ依存関係: シェーダーの実行にはパイプラインが必要であり、パイプラインにはシェーダーモジュールが必要です。

• 因果関係: シェーダーは、実行を終了する前に実行を開始しなければなりません。

2.2. エラー

WebGPU 実装は、次の2つの理由でシェーダーの処理に失敗する場合があります。

• シェーダーが WGSL または WebGPU 仕様の要件を満たしていない場合、 プログラムエラーが発生します。

• すべての WGSL および WebGPU の要件が満たされている場合でも、 分類不能 エラーが発生する可能性があります。 考えられる原因には、次のものがあります。

  • シェーダーが複雑すぎて実装の能力を超えているものの、 規定された制限では容易に表現できない場合。 シェーダーを簡略化すると、問題を回避できる可能性があります。

  • WebGPU 実装の欠陥。

処理エラーは、シェーダーのライフサイクルにおける3つの段階で発生する可能性があります。

• シェーダー作成 エラーは、シェーダーモジュール作成時に実行可能な範囲で検出できるエラーです。 検出は、WGSL モジュールのソーステキストと、 createShaderModule API メソッドが利用できるその他の情報のみに依存します。 この仕様においてプログラムが一般にしなければならないことを記述する文は、 その要件に違反した場合、通常はシェーダー作成エラーを発生させます。

• パイプライン作成エラーは、 パイプライン作成時に検出可能なエラーです。 検出は、WGSL モジュールのソーステキストと、 特定のパイプライン作成 API メソッドが利用できるその他の情報に依存します。 これらのエラーは、GPUProgrammableStage のためにコンパイルされるエントリーポイントの シェーダーに存在するコードについてのみ発生します。

• 動的エラーは、 シェーダーの実行中に発生するエラーです。 これらのエラーは、検出できる場合とできない場合があります。

注記: たとえば、データ競合は検出できない場合があります。

各要件は、最も早い機会に必ず検査されます。 つまり、次のようになります。

• シェーダー作成時に検出可能な要件を満たさなかった場合、シェーダー作成 エラーとなります。

• パイプライン作成時には検出できるものの、それより前には検出できない要件を満たさなかった場合、 パイプライン作成エラーとなります。

文脈から明らかでない場合、この仕様では、 特定の要件を満たさなかったことによって シェーダー作成エラー、パイプライン作成エラー、または動的エラーのいずれが発生するかを示します。

エラーの結果は次のとおりです。

• シェーダー作成エラーまたはパイプライン作成エラーを含む WGSL モジュールは、 パイプラインに組み込まれないため、 実行されません。

• 検出可能なエラーは、診断を必ずトリガーします。

• 動的エラーが 発生した場合:

  • メモリアクセスは、 必ず次のものに制限されます。

    • シェーダーステージの入力、

    • シェーダーステージの出力、

    • WGSL モジュール内の変数にバインドされたリソースの任意の部分、および

    • WGSL モジュール内で宣言されたその他の変数。

  • それ以外については、プログラムがこの仕様の残りの部分で説明されているように動作しない場合があります。 注記: これらの影響は非局所的である可能性があります。

2.3. 診断

実装は、シェーダーモジュール作成時またはパイプライン作成時に 診断を生成できます。 診断は、 アプリケーション作成者のために実装が生成するメッセージです。

特定の条件が満たされたときに診断が作成、すなわち トリガーされます。その条件は トリガー規則と呼ばれます。 ソーステキスト内でその条件が満たされた場所は、ソーステキスト内の点または範囲として表され、 トリガーロケーションと呼ばれます。

診断には、次の プロパティがあります。

• 重大度。

• トリガー規則。

• トリガーロケーション。

診断の重大度は、重要度が高いものから低いものの順に、次のいずれかになります。

error

診断はエラーです。 これは、シェーダー作成エラーまたはパイプライン作成 エラーに対応します。

warning

診断は、アプリケーション開発者が注意を払うに値するものの、エラーではない異常を記述します。

info

診断は、アプリケーション開発者が注意を払うに値するものの、エラーでも警告でもない注目すべき状態を記述します。

off

診断は無効です。アプリケーションには伝達されません。

トリガー規則の名前は、次のいずれかです。

• diagnostic_name_token、または

• ピリオド '.' (U+002E) で区切られた2つのdiagnostic_name_tokenトークン。

2.3.1. 診断処理

トリガーされた診断は、次のように必ず処理されます。

1. 各診断 D について、D のトリガー ロケーションを含む最小の影響範囲を持ち、同じトリガー規則を持つ診断フィルターを見つけます。

   • そのようなフィルターが存在する場合、それを D に適用し、D の重大度を更新します。

   • それ以外の場合、D は変更されません。

2. 重大度が off の診断を破棄します。

3. 残りの診断のうち少なくとも1つの DI の重大度が info である場合:

   • 同じトリガー規則を持つその他の info 診断は、元の診断 DI のみを残して 破棄してもよい。

4. 残りの診断のうち少なくとも1つの DW の重大度が warning である場合:

   • 同じトリガー規則を持つその他の info または warning 診断は、元の診断 DW のみを残して破棄してもよい。

5. 残りの診断のうち少なくとも1つが error の重大度を持つ場合:

   • error の重大度を持つその他の診断を含め、 その他の診断を破棄してもよい。

   • プログラムエラーが 生成されます。

     • 診断がシェーダーモジュール作成時にトリガーされた場合、 エラーはシェーダー作成エラーです。

     • 診断がパイプライン作成時にトリガーされた場合、 エラーはパイプライン作成エラーです。

6. シェーダーモジュール作成時に処理している場合、残りの診断は、 WebGPU GPUCompilationInfo オブジェクトの messages メンバーに設定されます。

7. パイプライン作成時に処理している場合、error 診断は、GPUProgrammableStage の検証時に WebGPU 検証の失敗を引き起こします。

注記: この規則により、実装はエラーが検出されるとすぐに WGSL モジュールの処理を停止できます。 さらに、特定の種類の警告の解析は最初の警告で停止でき、 特定の種類の info 診断の解析は最初の発生時に停止できます。 WGSL は、異なる種類の解析を実行する順序や、単一の解析内での順序を指定しません。 したがって、同じ WGSL モジュールについて、異なる実装が同じ重大度を持つ異なる診断インスタンスを 報告する可能性があります。

2.3.2. フィルター可能なトリガー規則

ほとんどの診断は、無条件に WebGPU アプリケーションへ報告されます。 一部の種類の診断は、そのトリガー規則を指定することなどにより、フィルタリングできます。 次の表に、フィルタリング可能な標準のトリガー規則一式を示します。

単一の診断名トークンからなる認識されないトリガー規則を使用すると、 ユーザーエージェントは警告を発するべきです。

実装は、ここで規定されていないトリガー規則をサポートできます。 ただし、その規則はdiagnostic_rule_nameの複数トークン形式を使用して表記する必要があります。 複数トークン形式で表記された認識されないトリガー規則を使用すること自体が、診断をトリガーする場合があります。

この仕様の将来の版では、特定の規則を削除したり、そのデフォルトの重要度を弱めたり （すなわち、現在のデフォルトを重要度の低いデフォルトに置き換えたり）しても、後方 互換性を満たしているとみなされる場合があります。 たとえば、WGSL の将来の版では、derivative_uniformityのデフォルトの重要度をerrorから warningまたはinfoへ変更する可能性があります。 仕様にそのような変更が行われた後も、以前に有効だったプログラムは有効なままです。

2.3.3. 診断のフィルタリング

フィルタリング可能なトリガー規則を持つ診断がトリガーされると、WGSL は、その 診断を破棄したり、その重要度を変更したりする仕組みを提供します。

診断フィルター DFには、次の3つのパラメーターがあります。

• AR：影響範囲と呼ばれるソーステキストの範囲

• NS：新しい重要度

• TR：トリガー規則

診断フィルターDF(AR,NS,TR)を診断Dに適用すると、 次の効果があります。

• Dのトリガー位置がAR内にあり、かつ Dのトリガー規則がTRである場合、 Dの重要度プロパティをNSに設定します。

• それ以外の場合、Dは変更されません。

範囲診断 フィルターは、診断フィルターのうち、その影響範囲が指定された ソーステキストの範囲であるものです。 範囲診断フィルターは、次の表に示すように、影響を受けるソース範囲の先頭にある @diagnostic 属性として指定されます。 @diagnostic属性は、それ以外の場所に現れてはなりません。

注： 次のものも複合文です。 関数本体、case節、単独のdefault 節、 whileおよびforループの本体、 ならびにif_clause、else_if_clause、およびelse_clauseの本体。

var<private> d: f32;
fn helper() -> vec4<f32> {
  // 「if」の本体内で derivative_uniformity 診断を
  // 無効にする。
  if (d < 0.5) @diagnostic(off,derivative_uniformity) {
    return textureSample(t,s,vec2(0,0));
  }
  return vec4(0.0);
}

グローバル 診断フィルターを使用すると、WGSL モジュール全体に診断フィルターを適用できます。

diagnostic(off,derivative_uniformity);
var<private> d: f32;
fn helper() -> vec4<f32> {
  if (d < 0.5) {
    // ここでは、グローバル診断フィルターによって
    // derivative_uniformity 診断が無効になっている。
    return textureSample(t,s,vec2(0,0));
  } else {
    // derivative_uniformity 診断の重要度が「warning」に設定される。
    @diagnostic(warning,derivative_uniformity) {
      return textureSample(t,s,vec2(0,0));
    }
  }
  return vec4(0.0);
}

2つの診断フィルター DF(AR1,NS1,TR1)およびDF(AR2,NS2,TR2)は、 次の場合に競合します。

• (AR1 = AR2)であり、

• (TR1 = TR2)であり、

• (NS1 ≠ NS2)である。

診断フィルターは競合してはなりません。

注： 複数のグローバル診断フィルターは、 競合しない限り許可されます。

WGSL の診断フィルターは、その影響範囲が完全に入れ子になるよう設計されています。 DF1の影響範囲とDF2の影響範囲が重なる場合、 DF1の影響範囲がDF2の影響範囲に完全に含まれるか、その逆になります。

ソース位置Lおよびトリガー規則TRに対する 最も近い外側の診断フィルターが存在する場合、それは 次の条件を満たす診断フィルターDF(AR,NS,TR)です。

• Lが影響範囲AR内にあり、かつ

• LがAR'内にある別のフィルターDF'(AR',NS',TR)が存在する場合、 ARがAR'に含まれる。

影響範囲は入れ子になるため、最も近い外側の診断フィルターは次のいずれかになります。

• 一意の範囲診断フィルター、

• そうでなければ、重複する（競合しない）グローバル診断 フィルターの集合の1つ、

• そうでなければ、存在しません。

2.4. 制限

WGSL 実装は、次の制限を満たすシェーダーをサポートします。 WGSL 実装は、規定された制限を超えるシェーダーをサポートしてもかまいません。

注： WGSL 実装は、規定された制限を 超えるシェーダーをサポートしない場合、エラーを発するべきです。

3. テキスト構造

text/wgslメディアタイプは、コンテンツを WGSL モジュールとして識別するために使用されます。 付録A：text/wgsl メディアタイプを参照してください。

WGSL モジュールは、バイトオーダーマーク（BOM）のない、UTF-8 エンコーディングを使用した Unicode テキストです。

WGSL モジュールのテキストは、一連の Unicode コードポイントからなり、次のものを形成する連続した空でない集合にまとめられます。

• コメント

• トークン

• 空白

プログラムテキストには、ヌルコードポイント（U+0000）を含めてはなりません。

3.1. 構文解析

WGSL モジュールを構文解析するには、次のようにします。

1. コメントを削除します。

   • 最初のコメントを空白コードポイント（U+0020）に置き換えます。

   • コメントがなくなるまで繰り返します。

2. § 3.9 テンプレートリストのアルゴリズムを使用して、テンプレートリストを検出します。 この手順により、'<'（U+003C）および'>'（U+003E）コード ポイントを、テンプレートリストの区切り文字として使用する場合と、比較演算子などのその他の用途に使用する場合との 曖昧さが解消されます。

3. translation_unit 文法規則への一致を試みながら、テキスト全体を構文解析します。 構文解析には、次のカスタマイズを施した LALR(1) パーサー（1トークンの先読み）[DeRemer1969]を使用します。

   • トークン化は構文解析と交互に行われ、文脈を考慮します。 パーサーが次のトークンを要求した場合、次のようにします。

     • 先頭にある一連の空白コードポイントを消費して無視します。

     • 次のコードポイントがテンプレートリストの先頭である場合、それを消費して _template_args_startを返します。

     • 次のコードポイントがテンプレートリストの末尾である場合、それを消費して _template_args_endを返します。

     • それ以外の場合、次のようにします。

       • トークン候補とは、消費されていない残りのコード ポイントの空でない接頭辞から形成される、任意の WGSL トークンです。

       • 返されるトークンは、現在の パーサー状態に対して有効な先読みトークンでもある、最長のトークン 候補です。[VanWyk2007]

次の場合、シェーダー作成 エラーになります。

• ソーステキスト全体を有限個の有効なトークンの列へ変換できない場合、または

• translation_unit文法規則が トークン列全体に一致しない場合。

3.2. 空白と改行

空白とは、 Unicode の Pattern_White_Spaceプロパティに含まれるコードポイントを1つ以上組み合わせたものです。 次に、Pattern_White_Spaceに含まれるコードポイントの集合を示します。

• 空白（U+0020）

• 水平タブ（U+0009）

• 改行（U+000A）

• 垂直タブ（U+000B）

• 改ページ（U+000C）

• 復帰（U+000D）

• 次行（U+0085）

• 左から右へのマーク（U+200E）

• 右から左へのマーク（U+200F）

• 行区切り（U+2028）

• 段落区切り（U+2029）

改行とは、 行の終わりを示す連続した空白コードポイントの列です。 これは、 UAX14 6.1節「調整不可能な行分割規則」のLB4およびLB5で定義される「強制分割」を示す空白として定義されます。 すなわち、改行は次のいずれかです。

• 改行（U+000A）

• 垂直タブ（U+000B）

• 改ページ（U+000C）

• 後ろに改行（U+000A）が続かない復帰（U+000D）

• 後ろに改行（U+000A）が続く復帰（U+000D）

• 次行（U+0085）

• 行区切り（U+2028）

• 段落区切り（U+2029）

注： ソーステキストの位置を 行番号で報告する診断では、行数を 数えるために改行を使用するべきです。

3.3. コメント

コメントとは、 WGSL プログラムの有効性や意味に影響を与えないテキストの範囲です。ただし、コメントによってトークンを分離できる点は例外です。 シェーダーの作成者は、プログラムを文書化するためにコメントを使用できます。

行末 コメントとは、コメントの一種であり、 2つのコードポイント//（U+002Fの後にU+002F）と、その後に続くコード ポイントからなります。ただし、次のものは含みません。

• 次の改行、または

• プログラムの末尾。

ブロックコメントとは、 コメントの一種であり、次のものからなります。

• 2つのコードポイント/*（U+002Fの後にU+002A）

• 続いて、次のものからなる任意の列。

  • ブロックコメント、 または

  • */（U+002Aの後に U+002F） もしくは/*（U+002Fの後にU+002A）を含まないテキスト

• 続いて、2つのコードポイント*/（U+002Aの後にU+002F）

注： ブロックコメントは入れ子にできます。 ブロックコメントでは、開始と終了のテキスト列が対応している必要があり、任意の入れ子が許可されるため、 ブロックコメントを正規表現で認識することはできません。 これは、正規言語の反復補題から導かれます。

const f = 1.5; // これは行末コメントである。
const g = 2.5; /* これは複数行にまたがる
                ブロックコメントである。
                /* ブロックコメントは入れ子にできる。
                 */
                ただし、すべてのブロックコメントを終端しなければならない。
               */

3.4. トークン

トークンとは、 次のいずれかを形成する連続したコードポイントの列です。

• リテラル。

• キーワード。

• 予約語。

• 構文トークン。

• 識別子。

• 文脈依存名。

3.5. リテラル

リテラルは、次のいずれかです。

• 真偽値 リテラル：trueまたはfalse。

• 数値 リテラル：整数リテラルまたは浮動小数点リテラルであり、 数値を表すために使用されます。

3.5.1. 真偽値リテラル

const a = true;
const b = false;

3.5.2. 数値リテラル

数値 リテラルの形式は、パターンマッチングによって定義されます。

整数リテラルは、 次のとおりです。

• 次のいずれかとして指定された整数。

  • 0

  • 先頭の数字が0ではない、10進数字の列。

  • 0xまたは0Xの後に16進数字の列が続くもの。

• その後に、省略可能なiまたはu接尾辞。

注： 0ではない整数リテラルの先頭に0を付けること（例： 012）は禁止されています。 これは、先頭の0が8進数を意味する他の言語の表記との混同を避けるためです。

const a = 1u;
const b = 123;
const c = 0;
const d = 0i;

const a = 0x123;
const b = 0X123u;
const c = 0x3f;

浮動小数点 リテラルは、10進浮動小数点リテラル または16進浮動小数点リテラルです。

浮動小数点 リテラルには、分数を表す仮数部と、省略可能な指数部という2つの論理的な部分があります。 おおまかには、リテラルの値は、底の値を指定された指数で累乗した値に仮数部を掛けたものです。 仮数部の数字が有効であるとは、その数字が0でないか、 または、その左側と右側の両方に0でない仮数部の数字があることをいいます。 有効数字は左から右へ数えます。N番目の有効数字の左側には、N-1個の 有効数字があります。

10進 浮動小数点リテラルは、次のとおりです。

• 数字の列として指定され、その途中に省略可能な小数点（.）を持つ仮数部。 仮数部は、10を底とする表記で分数を表します。

• その後に、次のものからなる省略可能な指数接尾辞。

  • eまたはE。

  • その後に、省略可能な先行符号（+ または-）を持つ10進数として指定された指数。

  • その後に、省略可能なfまたはh接尾辞。

• 小数点、指数、fまたはh接尾辞のうち、少なくとも1つが 存在しなければなりません。 いずれも存在しない場合、そのトークンは代わりに整数リテラルになります。

const a = 0.e+4f;
const b = 01.;
const c = .01;
const d = 12.34;
const f = .0f;
const g = 0h;
const h = 1e-3;

注： 10進数の仮数部は20個の 10進数字の後で切り捨てられ、分数内にはおよそ log(10)/log(2)×20 ≈ 66.4 有効ビットが保持されます。

16進浮動小数点リテラルは、次のとおりです。

• 0xまたは0X接頭辞

• その後に、16進数字の列として指定され、その途中に省略可能な16進小数点 （.）を持つ仮数部。 仮数部は、16を底とする表記で分数を表します。

• その後に、次のものからなる省略可能な指数接尾辞。

  • pまたはP

  • その後に、省略可能な先行符号（+ または-）を持つ10進数として指定された指数。

  • その後に、省略可能なfまたはh接尾辞。

• 16進小数点または指数のうち、少なくとも1つが存在しなければなりません。 いずれも存在しない場合、そのトークンは代わりに整数リテラルになります。

const a = 0xa.fp+2;
const b = 0x1P+4f;
const c = 0X.3;
const d = 0x3p+2h;
const e = 0X1.fp-4;
const f = 0x3.2p+2h;

注： 16進数の仮数部は16個の 16進数字の後で切り捨てられ、分数内にはおよそ 4 ×16 = 64 有効ビットが保持されます。

数値リテラルに 接尾辞がある場合、そのリテラルは特定の具象スカラー型の値を表します。 それ以外の場合、リテラルは、以下で定義する抽象数値型のいずれかの値を表します。 いずれの場合も、リテラルが表す値は、§ 15.7.6 浮動小数点変換の規則に従って 対象の型へ変換した後の数学的な値です。

次の場合、シェーダー作成 エラーになります。

• iまたはu接尾辞を持つ整数リテラルを 対象の型で表現できない場合。

• fまたはh接尾辞を持つ16進浮動小数点リテラルが オーバーフローするか、対象の型で正確に表現できない場合。

• fまたはh接尾辞を持つ10進浮動小数点リテラルが 対象の型でオーバーフローする場合。

• h接尾辞を持つ浮動小数点リテラルが、 f16 拡張が有効でないときに使用された場合。

注： 16進浮動小数点値 0x1.00000001p0 を 正確に表現するには仮数部に33ビット必要ですが、 f32には明示的な仮数部ビットが23ビットしかありません。

注： f接尾辞を使用して 16進浮動小数点リテラルをその型に強制する場合、そのリテラルでは 2進指数も使用する必要があります。たとえば、0x1p0fと記述します。これに対し、0x1fは 16進整数リテラルです。

3.6. キーワード

キーワードとは、 事前定義された言語概念を指すトークンです。 WGSL キーワードの一覧については、§ 16.1 キーワード一覧を参照してください。

3.7. 識別子

識別子とは、 名前として使用されるトークンの一種です。 § 5 宣言とスコープを参照してください。

WGSL では、用途を分けるために2つの文法非終端記号を使用します。

• identは、 宣言されたオブジェクトの名前に使用されます。

• member_identは、構造体型のメンバーの名前に使用されます。

識別子の形式は、 Unicode 標準附属書#31の Unicode バージョン14.0.0に基づき、 次の詳細化を加えたものです。

識別子は、UAX31 文法で記述された次のプロファイルを使用します。

<Identifier> := <Start> <Continue>* (<Medial> <Continue>+)*

<Start> := XID_Start + U+005F
<Continue> := <Start> + XID_Continue
<Medial> :=

これは、次のような非 ASCII コードポイントを持つ識別子が 有効であることを意味します：Δέλτα、réflexion、Кызыл、𐰓𐰏𐰇、 朝焼け、سلام、검정、שָׁלוֹם、गुलाबी、 փիրուզ。

ただし、次の例外があります。

• 識別子は、キーワードまたは予約語と同じ綴りであってはなりません。

• 識別子は、_（単一のアンダースコア、 U+005F）であってはなりません。

• 識別子は、__（2つのアンダースコア、 U+005Fの後にU+005F）で始まってはなりません。

Unicode バージョン14.0.0の Unicode 文字データベースには、 XID_Startおよび XID_Continueの両方について、 有効なすべてのコードポイントを含む参考情報の一覧が収録されています。

注： 一部の組み込み関数の戻り値の型は、その名前を WGSL ソース内で使用できない構造体型です。 それらの構造体型は、2つのアンダースコアで始まる名前で事前宣言されているかのように記述されます。 結果値は、型推論を使用して新しく宣言されたletまたはvarへ 保存するか、そのメンバーの1つを名前によって 直ちに抽出できます。使用例については、frexpおよび modfの説明を参照してください。

3.7.1. 識別子の比較

2つの WGSL 識別子は、同じコードポイント列からなる場合に限り同じです。

注： この仕様では、比較を目的とした値の Unicode 正規化は許可されません。 視覚的および意味的には同一でも、異なる Unicode 文字列を使用する値は一致しません。 コンテンツの作成者には、同じエンコーディング列を一貫して使用するか、値を選択するときに問題となる可能性のある 文字を避けることを推奨します。詳細については、[CHARMOD-NORM]を参照してください。

注： WGSL モジュールに現れる識別子をすべて、 その識別子の同形表記の1つに置き換えると意味が変わる場合、ユーザーエージェントは開発者に見える 警告を発するべきです。 （同形文字とは、読者には別のコードポイント列と同じに見える可能性があるコードポイント列です。 同形文字を検出するための対応付けの例としては、 前の段落で述べた変換、対応付け、および照合アルゴリズムがあります。ある識別子について、部分列をその同形文字に 繰り返し置き換えることで一方のコードポイント列をもう一方へ変換できる場合、その2つのコードポイント列は同形表記です。）

3.8. 文脈依存名

文脈依存 名とは、特定の文法的文脈においてのみ概念の名前として使用されるトークンです。 トークンの綴りは識別子と同じ場合がありますが、そのトークンは宣言されたオブジェクトへ解決されません。 この節では、文脈依存名として使用されるトークンを列挙します。 トークンはキーワードまたは予約語であってはなりません。

3.8.1. 属性名

§ 12 属性を参照してください。

attributeの名前は、 次のとおりです。

• 'align'

• 'binding'

• 'builtin'

• 'compute'

• 'const'

• 'diagnostic'

• 'fragment'

• 'group'

• 'id'

• 'interpolate'

• 'invariant'

• 'location'

• 'blend_src'

• 'must_use'

• 'size'

• 'vertex'

• 'workgroup_size'

• 'subgroup_size'

3.8.2. 組み込み値名

組み込み値 名トークンとは、組み込み値の名前で使用されるトークンです。

§ 13.3.1.1 組み込み入力と出力を参照してください。

組み込み値の名前は 次のとおりです。

• 'vertex_index'

• 'instance_index'

• 'position'

• 'front_facing'

• 'frag_depth'

• 'sample_index'

• 'sample_mask'

• 'local_invocation_id'

• 'local_invocation_index'

• 'global_invocation_id'

• 'global_invocation_index'

• 'workgroup_id'

• 'workgroup_index'

• 'num_workgroups'

• 'subgroup_invocation_id'

• 'subgroup_size'

• 'primitive_index'

• 'subgroup_id'

• 'num_subgroups'

3.8.3. 診断規則名

診断 名トークンとは、診断のトリガー規則の名前で使用されるトークンです。

§ 2.3 診断を参照してください。

事前定義された診断規則の名前は、次のとおりです。

• 'derivative_uniformity'

• 'subgroup_uniformity'

3.8.4. 診断重要度制御名

有効な診断 フィルターの重要度制御名は§ 2.3 診断に列挙されていますが、 識別子と同じ形式を持ちます。

診断フィルターの 重要度制御名は、次のとおりです。

• 'error'

• 'warning'

• 'info'

• 'off'

3.8.5. 拡張名

有効な有効化拡張の 名前は§ 4.1.1 拡張の有効化に列挙されていますが、一般には 識別子と同じ形式を持ちます。

有効化拡張の 名前は、次のとおりです。

• 'f16'

• 'clip_distances'

• 'dual_source_blending'

• 'subgroups'

• 'primitive_index'

• 'subgroup_size_control'

有効な言語 拡張の名前は§ 4.1.2 言語拡張に列挙されていますが、 一般には識別子と同じ形式を持ちます。

言語 拡張の名前は、次のとおりです。

• 'readonly_and_readwrite_storage_textures'

• 'packed_4x8_integer_dot_product'

• 'unrestricted_pointer_parameters'

• 'pointer_composite_access'

• 'uniform_buffer_standard_layout'

• 'subgroup_id'

• 'subgroup_uniformity'

• 'texture_and_sampler_let'

• 'texture_formats_tier1'

• 'linear_indexing'

• 'immediate_address_space'

• 'fragment_depth'

• 'buffer_view'

• 'swizzle_assignment'

3.8.6. 補間型名

補間型名トークンとは、 interpolate_type_nameに対する補間型の名前で使用されるトークンです。

§ 13.3.1.4 補間を参照してください。

補間 型の名前は、次のとおりです。

• 'perspective'

• 'linear'

• 'flat'

3.8.7. 補間サンプリング名

補間サンプリング名トークンとは、 補間サンプリングの名前で使用されるトークンです。

§ 13.3.1.4 補間を参照してください。

補間 サンプリングの名前は、次のとおりです。

• 'center'

• 'centroid'

• 'sample'

• 'first'

• 'either'

3.8.8. スウィズル名

スウィズル名は、 ベクトルアクセス式およびスウィズルビュー 式で使用されます。

3.8.9. 深度モード名

深度モード 名トークンは、トークンであり、 frag_depth組み込み値で、fragment_depth機能が サポートされる場合に使用されます。

• 'less'

• 'greater'

3.9. テンプレートリスト

テンプレート パラメーター化とは、一般的な概念を変更するパラメーターを指定する方法です。 テンプレートパラメーター化を記述するには、一般的な概念に続けてテンプレートリストを記述します。

コメントおよび空白を無視すると、テンプレートリストは次のとおりです。

• 先頭の'<'（U+003C）コードポイント、その後に

• コンマで区切られた、 1つ以上のテンプレートパラメーターのリスト、その後に

• 省略可能な末尾のコンマ、その後に

• 終端の'>'（U+003E）コードポイント。

テンプレート パラメーターの形式は、以下のテンプレートリスト検出アルゴリズムによって暗黙的に定義されます。 一般に、これらは名前、式、または型です。

注： たとえば、vec3<f32>という句は、 vec3が変更される一般的な概念であり、 <f32>が1つのパラメーターであるf32型を含むテンプレートリストである、テンプレートパラメーター化です。 これらを合わせたvec3<f32>は、特定のベクトル型を表します。

注： たとえば、 var<storage,read_write>という句は、一般的なvar概念をテンプレート パラメーターstorageおよびread_writeによって変更します。

テンプレートリストを区切る'<'（U+003C）および'>'（U+003E）コードポイントは、 次のものを表記するときにも使用されます。

• relational_expression内の比較演算子。

• shift_expression内のシフト演算子。

• シフト演算の後に代入を行うためのcompound_assignment_operator。

構文上の曖昧さは、テンプレートリストを優先して解決されます。

• テンプレートリストは、宣言、式、文を構文解析する前の、構文解析の初期段階で検出されます。

• 後の段階でトークン化するとき、 テンプレートリストの先頭の'<'（U+003C）は_template_args_startトークンに対応付けられ、 テンプレートリストを終端する'>'（U+003E）は_template_args_endトークンに対応付けられます。

テンプレート リスト検出アルゴリズムを以下に示します。 このアルゴリズムでは、次の仮定および性質を使用します。

1. テンプレート パラメーターは式であるため、 '<'（U+003C）または'='（U+003D）コードポイントのいずれでも始まりません。

2. 式には、コードポイント';'（U+003B）、'{'（U+007B）、または ':'（U+003A）は含まれません。

3. 式には代入は含まれません。

4. '='（U+003D）コードポイントが現れるのは、比較演算の一部である場合のみです。 すなわち、 '<='、 '>='、 '=='、または '!='の いずれかです。 それ以外の場合、'='（U+003D）コードポイントは代入の一部として現れます。

5. テンプレートリストの区切り文字は、丸括弧「(...)」および配列インデックス指定 「[...]」によって形成される入れ子の式を尊重します。 テンプレートリストの先頭と末尾は、同じ入れ子レベルに現れなければなりません。

アルゴリズム： テンプレートリストの検出

入力： プログラムのソーステキスト。

レコード型：

UnclosedCandidateを、次のものを含むレコード型とします。

• position：ソーステキスト内の位置

• depth：整数であり、positionにおける式の入れ子の深さ

TemplateListを、次のものを含むレコード型とします。

• start_position：このテンプレートリストを開始する'<'（U+003C）コードポイントの ソース内の位置。

• end_position：このテンプレートリストを終了する'>'（U+003E）コードポイントの ソース内の位置。

出力： DiscoveredTemplateLists：TemplateListレコードのリスト。

手順：

• DiscoveredTemplateListsを空のリストに初期化します。

• Pending変数を、UnclosedCandidate レコードの空のスタックとして初期化します。

• 整数変数CurrentPositionを0に初期化します。 この変数は、現在検査しているコードポイントの位置を、ソーステキストの先頭から後にある コードポイント数として符号化します。

  • この変数は、アルゴリズムの実行中にテキスト内を前方へ進みます。 テキストの末尾に達したら、アルゴリズムを直ちに終了し、 DiscoveredTemplateListsを返します。

• 整数変数NestingDepthを0に初期化します。

• 次の手順を繰り返します。

  • CurrentPositionを、空白、コメント、およびリテラルの後まで進めます。

  • ident_pattern_tokenが CurrentPositionのテキストと一致する場合、次のようにします。

    • CurrentPositionをident_pattern_tokenの後まで進めます。

    • 空白およびコメントが存在する場合、CurrentPositionをそれらの後まで進めます。

    • CurrentPositionに'<'（U+003C）が現れる場合、次のようにします。

      • 注： このコード ポイントは、テンプレートリストの先頭である候補です。 後で入力に現れる終端の '>'（U+003E）と照合できるように、十分な状態を保存します。

      • UnclosedCandidate(position=CurrentPosition,depth=NestingDepth)を Pendingスタックにプッシュします。

      • CurrentPositionを次のコードポイントへ進めます。

      • CurrentPositionに'<'（U+003C）が現れる 場合、次のようにします。

        • 注： 仮定1より、テンプレートパラメーターは'<'（U+003C）で始まらないため、 直前のコードポイントをテンプレートリストの先頭とすることはできません。 したがって、現在と直前のコードポイントは'<<' 演算子でなければなりません。

        • Pendingスタックから最上位の項目をポップします。

        • CurrentPositionをこのコードポイントの後まで進め、 ループの次の反復を開始します。

      • CurrentPositionに'='（U+003D）が現れる場合、次のようにします。

        • 注： 仮定1より、テンプレートパラメーターは'=' （U+003C）で始まらないため、直前のコードポイントを テンプレートリストの先頭とすることはできません。 現在と直前のコードポイントが'<=' 比較演算子を形成すると仮定します。 後の手順で'='（U+003D）コードポイントを代入と誤認しないように、 そのコードポイントを読み飛ばします。

        • Pendingスタックから最上位の項目をポップします。

        • CurrentPositionをこのコードポイントの後まで進め、 ループの次の反復を開始します。

    • ループの次の反復を開始します。

  • CurrentPositionに'>'（U+003E）が現れる場合、次のようにします。

    • 注： このコードポイントは、 テンプレートリストの末尾である候補です。

    • Pendingが空でない場合、その最上位の項目をTとし、 T.depthがNestingDepthと等しい場合、次のようにします。

      • 注： このコード ポイントは、先頭がTに記録されている現在のテンプレートリストを終了します。

      • TemplateList(start_position=T.position, end_position=CurrentPosition)を DiscoveredTemplateListsに追加します。

      • PendingスタックからTをポップします。

      • CurrentPositionをこのコードポイントの後まで進め、 ループの次の反復を開始します。

    • それ以外の場合、このコードポイントはテンプレートリストを終了しません。

      • CurrentPositionをこのコードポイントの後まで進めます。

      • CurrentPositionに'='（U+003D）が現れる場合、次のようにします。

        • 注： 現在と直前のコードポイントが'>=' 比較演算子を形成すると仮定します。 後の手順で'='（U+003D）コードポイントを代入と誤認しないように、 そのコードポイントを読み飛ばします。

        • CurrentPositionをこのコードポイントの後まで進めます。

      • ループの次の反復を開始します。

  • CurrentPositionに'('（U+0028）または'['（U+005B）が現れる 場合、次のようにします。

    • 注： 入れ子の 式に入ります。

    • NestingDepthに1を加えます。

    • CurrentPositionをこのコードポイントの後まで進め、 ループの次の反復を開始します。

  • CurrentPositionに')'（U+0029）または']'（U+005D）が現れる 場合、次のようにします。

    • 注： 入れ子の 式から出ます。

    • Pendingスタックが空になるか、その最上位の項目の depthがNestingDepthより小さくなるまで、項目をポップします。

    • NestingDepthを0またはNestingDepth − 1の いずれか大きい方に設定します。

    • CurrentPositionをこのコードポイントの後まで進め、 ループの次の反復を開始します。

  • CurrentPositionに'!'（U+0021）が現れる場合、次のようにします。

    • CurrentPositionをこのコードポイントの後まで進めます。

    • CurrentPositionに'='（U+003D）が現れる場合、次のようにします。

      • 注： 現在と直前のコードポイントが'!='比較 演算子を形成すると仮定します。 後の手順で'='（U+003D）コードポイントを 代入と誤認しないように、そのコードポイントを読み飛ばします。

      • CurrentPositionをこのコードポイントの後まで進めます。

    • ループの次の反復を開始します。

  • CurrentPositionに'='（U+003D）が現れる場合、次のようにします。

    • CurrentPositionをこのコードポイントの後まで進めます。

    • CurrentPositionに'='（U+003D）が現れる場合、次のようにします。

      • 注： 現在と直前のコードポイントが'==' 比較演算子を形成すると仮定します。 後の手順で'='（U+003D）コードポイントを 代入と誤認しないように、そのコードポイントを読み飛ばします。

      • CurrentPositionをこのコードポイントの後まで進め、 ループの次の反復を開始します。

    • 注： このコードポイントは、 式の一部としては現れ得ず、したがってテンプレートリスト内にも現れ得ない代入の 一部であると仮定します。 保留中の閉じられていない候補を消去します。

    • NestingDepthを0に設定します。

    • Pendingスタックからすべての項目を削除します。

    • CurrentPositionをこのコードポイントの後まで進め、 ループの次の反復を開始します。

  • CurrentPositionに';'（U+003B）、'{'（U+007B）、または ':'（U+003A）が現れる場合、次のようにします。

    • 注： これらは 式の途中には現れ得ず、したがってテンプレートリスト内にも現れ得ません。 保留中の閉じられていない候補を消去します。

    • NestingDepthを0に設定します。

    • Pendingスタックからすべての項目を削除します。

    • CurrentPositionをこのコードポイントの後まで進め、 ループの次の反復を開始します。

  • '&&'または'||'が CurrentPositionのテキストと一致する場合、次のようにします。

    • 注： これらは 比較よりも優先順位が低い演算子です。現在の式レベルにある保留中の閉じられていない 候補をすべて棄却します。

    • 注： この規則により、 プログラム断片a<b || c>dではテンプレートリストは検出されません。 代わりに、2つの比較を短絡評価する論理和として認識されます。

    • Pendingスタックが空になるか、その最上位の項目の depthがNestingDepthより小さくなるまで、項目をポップします。

    • CurrentPositionを2つのコードポイントの後まで進め、 ループの次の反復を開始します。

  • CurrentPositionを現在のコードポイントの後まで進めます。

注： 一部の数値リテラルは、たとえば1.0fのように 文字で終わるため、アルゴリズムはリテラルを明示的に読み飛ばします。 終端のfをident_pattern_tokenの 先頭と誤認するべきではありません。

注： A ( B < C, D > ( E ) )という句では、部分< C, D >がテンプレートリストです。

注： アルゴリズムは式の入れ子を尊重します。 特定のテンプレートリストの先頭と末尾を、異なる式の入れ子レベルに置くことはできません。 たとえば、array<i32,select(2,3,a>b)>のテンプレートリストには3つのパラメーターがあり、 最後のパラメーターはselect(2,3,a>b)です。 a>b内の'>'は、select関数を呼び出す式の 丸括弧で囲まれた部分に含まれているため、テンプレートリストを終了しません。

注： テンプレートリストの両端は、同じ インデックス指定 式内に現れなければなりません。たとえば、a[b<d]>()には有効なテンプレートリストが含まれません。

注： A<B<<C>という句では、 B<<Cという句は、Bの後に左シフト演算子'<<'、さらにCが続くものとして構文解析されます。 テンプレート検出アルゴリズムは、B、次に「<」（U+003C）の検査を開始しますが、 次の'<'（U+003C）コードポイントはテンプレート引数を開始できないことを検出するため、 Bの直後の'<'はテンプレートリストの先頭ではありません。 最初の'<'と最後の'>'だけがテンプレートリストの区切り文字であり、その テンプレートパラメーターはB<<Cです。

注： A<B<=C>という句は、 前の注と同様に解析されるため、B<=Cという句は、Bの後に 以下演算子'<='、さらにCが続くものとして構文解析されます。 テンプレート検出アルゴリズムは、B、次に'<'（U+003C）の検査を開始しますが、 次の'='（U+003D）コードポイントはテンプレート引数を開始できないことを検出するため、 Bの直後の'<'はテンプレートリストの先頭ではありません。 最初の'<'と最後の'>'だけがテンプレートリストの区切り文字であり、その テンプレートパラメーターはB<=Cです。

注： A<(B>=C)>という句を検査するとき、最初の'<'（U+003C） コードポイントから始まり、最後の'>'（U+003E）コードポイントで終わる1つのテンプレートリストがあり、そのテンプレート引数は B>=Cです。 最初の'>'（U+003C）コードポイント（Bの後）を検査した後、 '='（U+003D）コードポイントが代入の一部とみなされないよう、特別に認識する必要があります。

注： A<(B!=C)>という句を検査するとき、最初の'<'（U+003C） コードポイントから始まり、最後の'>'（U+003E）コードポイントで終わる1つのテンプレートリストがあり、そのテンプレート引数は B!=Cです。 '!'（U+0021）コードポイント（'B'の後）を検査した後、 '='（U+003D）コードポイントが代入の一部とみなされないよう、特別に認識する必要があります。

注： A<(B==C)>という句を検査するとき、最初の'<'（U+003C） コードポイントから始まり、最後の'>'（U+003E）コードポイントで終わる1つのテンプレートリストがあり、そのテンプレート引数は B==Cです。 最初の'='（U+003D）コードポイント（'B'の後）を検査した後、 どちらも代入の一部とみなされないよう、2つ目の '='（U+003D）コードポイントを特別に認識する必要があります。

テンプレート リストの検出が完了した後、 構文解析は、各テンプレートリストをtemplate_list 文法規則に一致させることを試みます。

4. 指令

指令は、 WebGPU 実装が WGSL プログラムを処理する方法を変更するトークン列です。

指令は省略可能です。 指令が存在する場合、すべての指令は、あらゆる宣言またはconst アサーションより前に現れなければなりません。

4.1. 拡張

WGSL は、時間の経過とともに進化することが想定されています。

拡張は、 WGSL 仕様に対する一貫した変更の集合を名前付きでまとめたものであり、次のものを任意に組み合わせて構成されます。

• 新しい構文による新しい概念および動作の追加。これには次のものが含まれます。

  • 宣言、文、属性、および組み込み関数。

• 現在の仕様または以前に公開された拡張にある制限の撤廃。

• 許容される動作の集合を狭めるための構文。

• プログラムの一部で利用できる機能を制限するための構文。

• 拡張が既存の仕様、および必要に応じて他の拡張とどのように相互作用するかについての説明。

仮に、拡張では次のことが可能です。

• 異なるビット幅の整数など、数値スカラー型を追加する。

• 浮動小数点の丸めモードを制約する構文を追加する。

• シェーダーがアトミック型を使用しないことを示す構文を追加する。

• 新しい種類の文を追加する。

• 新しい組み込み関数を追加する。

• シェーダー呼び出しの実行方法を制約する構文を追加する。

• 新しいシェーダーステージを追加する。

拡張には、有効化拡張および言語拡張という2種類があります。

4.1.1. 有効化拡張

有効化拡張は、 次の条件を満たす場合にのみ機能を利用できる拡張です。

• 実装がその拡張をサポートしており、かつ

• シェーダーがenable指令によって明示的にその拡張を要求し、かつ

• 対応する WebGPU のGPUFeatureNameが、 GPUDeviceの作成時に要求された必須機能の1つである。

有効化拡張は、 普遍的にはサポートされていないハードウェア機能を公開することを目的としています。

enable指令は、 1つ以上の有効化拡張のサポートを有効にする指令です。 実装が列挙されたすべての有効化拡張をサポートしていない場合、シェーダー作成 エラーになります。

他の指令と同様に、enable指令が存在する場合、その指令はすべての宣言およびconstアサーションより前に現れなければなりません。 拡張名は識別子ではありません。 拡張名は宣言へ解決されません。

有効な有効化拡張を次の表に示します。

// 任意精度浮動小数点型のための仮想的な拡張を有効にする。
enable arbitrary_precision_float;
enable arbitrary_precision_float; // 冗長な enable 指令も許容される。

// 丸めモードを制御するための仮想的な拡張を有効にする。
enable rounding_mode;

// arbitrary_precision_float により次の使用が有効になると仮定する。
//    - 型 f<E,M>
//    - 関数の戻り値、仮パラメーター、および let 宣言における型としての使用
//    - AbstractFloat からの値コンストラクターとしての使用
//    - 除算演算子 / のオペランド
// @rounding_mode 属性は、rounding_mode enable 指令によって有効になると仮定する。
@rounding_mode(round_to_even)
fn halve_it(x : f<8, 7>) -> f<8, 7> {
  let two = f<8, 7>(2);
  return x / 2; // 最近接偶数への丸めモードを使用する。
}

4.1.2. 言語拡張

言語拡張は、 実装がサポートしている場合に自動的に利用可能になる拡張です。 プログラムが明示的に要求する必要はありません。

言語拡張は、 どの WebGPU 実装でも合理的にサポートできる機能を具体化します。 その機能が普遍的にサポートされていないとすれば、それは一部の WebGPU 実装がまだ 実装していないためです。

注： たとえば、do-whileループは言語 拡張になり得ます。

WebGPU のGPU オブジェクトのwgslLanguageFeatures メンバーは、実装がサポートする 言語拡張の集合を列挙します。

requires指令は、 プログラムが1つ以上の言語拡張を使用することを文書化する指令です。 実装が公開する機能は変更しません。 実装が必須拡張のいずれかをサポートしていない場合、シェーダー作成 エラーになります。

WGSL モジュールは、移植できない可能性、および移植性に対して意図する最低基準を示すため、 requires指令を使用できます。

注： WebGPU 実装外部のツールは、 プログラムが使用するすべての言語拡張が、プログラム内のrequires指令によって網羅されているかを検査できます。

他の指令と同様に、requires指令が存在する場合、その指令はすべての宣言およびconstアサーションより前に現れなければなりません。 拡張名は識別子ではありません。 拡張名は宣言へ解決されません。

注： その時点で一般的にサポートされている 言語拡張のすべての機能を具体化する言語拡張を、WGSL が時間の経過とともに定義していくことを意図しています。 requires指令では、これらは一般的な機能をすべて列挙するための 簡略形式として機能します。 これらは段階的に増大する機能の集合を表しており、ある種の言語バージョンと考えることができます。

4.2. グローバル診断フィルター

グローバル診断 フィルターは、その影響範囲が WGSL モジュール全体である診断フィルターです。 これは指令であるため、 あらゆるモジュールスコープ 宣言より前に現れます。 属性形式と同じように表記されますが、先頭の@（U+0040）コードポイントはなく、 末尾にセミコロンが付きます。

5. 宣言とスコープ

宣言は、 識別子を次のいずれかの種類のオブジェクトに関連付けます。

• 型

• 型ジェネレーター

• 値

• 変数

• 関数

• 仮 パラメーター

• 列挙値

言い換えると、宣言はオブジェクトの名前を導入します。

宣言がプログラムのソース内に現れるものの、 他のいかなる宣言のテキスト内にも現れない場合、その宣言はモジュール スコープにあります。

関数宣言は モジュールスコープに現れます。 関数宣言は、仮パラメーターがある場合、その宣言を含み、 また、その本体内に変数および値の宣言を含む場合があります。 したがって、これらの内包された宣言はモジュールスコープにはありません。

注： 別の宣言を含む唯一の種類の宣言は、 関数宣言です。

特定のオブジェクトは WebGPU 実装によって提供され、 WGSL モジュールのソースが始まる前に宣言されたかのように扱われます。 このようなオブジェクトを事前宣言済みと呼びます。 たとえば、WGSL は次のものを事前宣言します。

• 組み込み 関数、

• i32およびf32などの組み込み型、

• array、ptr、 およびtexture_2dなどの組み込み型ジェネレーター、および

• read_write、 workgroup、およびrgba8unormなどの 列挙値。

宣言のスコープとは、 宣言された識別子が、その関連付けられたオブジェクトを表す可能性がある プログラムのソース位置の集合です。 これらのソース位置では、その識別子が（宣言の）スコープ 内にあるといいます。

宣言が現れる場所によって、そのスコープが決まります。

• 事前宣言済みのオブジェクト、およびモジュールスコープで宣言されたオブジェクトは、 プログラムのソース全体でスコープ内にあります。

• ユーザー宣言関数の各仮パラメーターは、対応する関数本体全体でスコープ内にあります。 § 11.1 ユーザー定義関数の宣言を参照してください。

• それ以外の場合、スコープは宣言の末尾の直後から始まるテキストの範囲です。 詳細については、§ 7 変数および値の宣言を参照してください。

同じ WGSL ソースプログラム内の2つの宣言は、次の両方を同時に満たしてはなりません。

• 同じ識別子名を導入し、かつ

• 同じスコープ終端を持つ。

注： 事前宣言済みのオブジェクトは、 WGSL ソース内に宣言を持ちません。 したがって、モジュールスコープまたは関数内にあるユーザー指定の宣言は、事前宣言済みの オブジェクトと同じ名前を持つことができます。

識別子は、文法的な文脈によって区別され、次のように使用されます。

• ident文法要素に一致するトークンは、次のように使用されます。

  • 宣言内で、宣言されるオブジェクトの名前として使用されるか、

  • 別の場所で宣言されたオブジェクトを表す名前として使用されます。これは一般的な場合です。

• member_ident文法要素に一致するトークンは、次のように使用されます。

  • 構造体 型の宣言内で、 メンバーの名前として使用されるか、

  • 構造体値のメンバーを表す名前、または構造体のメンバーへの参照を表す名前として使用されます。 § 8.5.4 構造体アクセス式を参照してください。

identトークンが、 別の場所で宣言されたオブジェクトを表す名前として現れる場合、 そのトークンは何らかの宣言についてスコープ内になければなりません。 識別子トークンが表すオブジェクトは、次のように決定されます。

• トークンが少なくとも1つの非モジュールスコープ宣言についてスコープ内にある場合、 そのトークンは、それらの宣言のうち最も近い宣言に関連付けられたオブジェクトを表します。

  注： そのような最も近い宣言は、 識別子トークンより前に現れます。

• それ以外の場合、その名前を持つモジュールスコープ宣言が存在するなら、トークンは その宣言されたオブジェクトを表します。

  注： モジュールスコープ宣言は、 識別子トークンの前または後に現れる場合があります。

• それ以外の場合、その名前を持つ事前宣言済みのオブジェクトが存在するなら、トークンはその オブジェクトを表します。

上記のアルゴリズムを使用して識別子を宣言に対応付ける場合、その識別子が その宣言へ解決されるといいます。 同様に、その識別子が宣言されたオブジェクトへ解決されるともいいます。

いずれかのモジュールスコープ宣言が再帰的である場合、 シェーダー作成エラーになります。 すなわち、宣言間に循環が存在してはなりません。

次のような有向グラフを考えます。

• 各ノードは宣言Dに対応します。

• Dの定義で、Tへ解決される識別子が言及される場合、 宣言Dから宣言Tへの辺があります。

このグラフに循環があってはなりません。

注： 関数本体は関数宣言の一部であるため、 関数は直接的にも間接的にも再帰してはなりません。

注： 非モジュールスコープの識別子宣言は、テキスト内でその使用より前に 現れなければなりません。

// 有効。ユーザー定義変数は組み込み関数と同じ名前を持つことができる。
var<private> modf: f32 = 0.0;

// 有効。foo_1 はプログラム全体でスコープ内にある。
var<private> foo: f32 = 0.0; // foo_1

// 有効。bar_1 はプログラム全体でスコープ内にある。
var<private> bar: u32 = 0u; // bar_1

// 有効。my_func_1 はプログラム全体でスコープ内にある。
// 有効。foo_2 は関数の末尾までスコープ内にある。
fn my_func(foo: f32) { // my_func_1, foo_2
  // 「foo」への参照はすべて関数パラメーターへ解決される。

  // 無効。modf はモジュールスコープ変数へ解決される。
  let res = modf(foo);

  // 無効。foo_2 のスコープは関数の末尾で終了する。
  var foo: f32; // foo_3

  // 有効。bar_2 は関数の末尾までスコープ内にある。
  var bar: u32; // bar_2
  // 「bar」への参照は bar_2 へ解決される。
  {
    // 有効。foo_4 は複合文の末尾までスコープ内にある。
    var foo : f32; // foo_4

    // 有効。bar_3 は複合文の末尾までスコープ内にある。
    var bar: u32; // bar_3
    // 「bar」への参照は bar_3 へ解決される。

    // 無効。bar_4 は bar_3 と同じスコープ終端を持つ。
    var bar: i32; // bar_4

    // 有効。i_1 は for ループの末尾までスコープ内にある。
    for ( var i: i32 = 0; i < 10; i++ ) { // i_1
      // 無効。i_2 は i_1 と同じスコープ終端を持つ。
      var i: i32 = 1; // i_2。
    }
  }

  // 無効。bar_5 は bar_2 と同じスコープ終端を持つ。
  var bar: u32; // bar_5

  // 有効。モジュールスコープ宣言である later_def は、プログラム全体でスコープ内にある。
  var early_use : i32 = later_def;
}

// 無効。bar_6 は bar_1 と同じスコープを持つ。
var<private> bar: u32 = 1u; // bar_6

// 無効。my_func_2 は my_func_1 と同じスコープ終端を持つ。
fn my_func() { } // my_func_2

// 有効。my_foo_1 はプログラム全体でスコープ内にある。
fn my_foo( //my_foo_1
  // 有効。my_foo_2 は関数の末尾までスコープ内にある。
  my_foo: i32 // my_foo_2
) { }

var<private> later_def : i32 = 1;

// この宣言は、事前宣言済みの組み込み関数「min」を隠す。
// この宣言はモジュールスコープにあるため、ソース全体でスコープ内に
// ある。組み込み関数にはアクセスできなくなる。
fn min() -> u32 { return 0; }

const rgba8unorm = 12; // これは事前宣言済みの列挙値「rgba8unorm」を隠す。

6. 型

プログラムは値を計算します。

WGSL では、型は値の集合であり、 各値は正確に1つの型に属します。 値の型によって、その値に対して実行できる演算の構文および意味が決まります。

たとえば、数学的な数1は、WGSL では次の異なる値に対応します。

• 32ビット符号付き整数値1i、

• 32ビット符号なし整数値1u、

• 32ビット浮動小数点値1.0f、

• f16拡張が有効である場合、16ビット浮動小数点値1.0h、

• AbstractInt値1、および

• AbstractFloat値 1.0

これらは機械表現および演算が異なるため、WGSL は異なるものとして扱います。

一部の型は不透明です。 これは、その値が実装定義の表現を持ち、 WGSL プログラム内で直接検査、分解、または操作できないことを意味します。

型は、事前宣言済みであるか、 WGSL ソース内の宣言によって作成されます。

一部の型はテンプレートパラメーター化として表現されます。 型ジェネレーターは、 テンプレート リストによってパラメーター化されたときに型を表す、事前宣言済みのオブジェクトです。 たとえば、型atomic<u32>は、型ジェネレーターatomicと テンプレートリスト<u32>を組み合わせます。

型の概念と、その型を表す WGSL の構文を区別します。 多くの場合、この仕様における型の表記は、その WGSL 構文と同じです。 次に例を示します。

• 32ビット符号なし整数値の集合は、この仕様でも WGSL モジュールでもu32と表記されます。

• 構造体型、または構造体を含む型では表記が異なります。

一部の WGSL 型は、ソースプログラムの解析および プログラムの実行時の動作の決定にのみ使用されます。 この仕様ではそのような型について説明しますが、それらは WGSL ソーステキストには現れません。

注： 参照型は WGSL モジュール内には記述されません。§ 6.5.3 参照型およびポインター型を参照してください。

注： スウィズルビュー型は WGSL モジュール内には記述されません。§ 6.5.4 スウィズルビュー型を参照してください。

6.1. 型検査

WGSL の値は、式を評価することによって計算されます。 式は、 名前が「expression」で終わる WGSL 文法規則の1つとして構文解析される ソーステキストの区間です。 式Eには、外側の式Eに完全に含まれる式である部分式を含めることができます。 最上位 式は、それ自体が部分式ではない式です。 § 8.19 式文法の概要を参照してください。

式の評価によって生成される特定の値は、次のものに依存します。

• 静的文脈： 式を囲むソーステキスト、および

• 動的 文脈： 式を評価する呼び出しの状態、 およびその呼び出しが実行されている実行文脈。

特定の式を評価した結果となり得る値は、常に特定の WGSL 型に属します。 この型を、式の静的型と呼びます。 WGSL の規則は、式の静的型が、その式の静的 文脈のみに依存するよう設計されています。

型表明は、 ある WGSL ソース式から WGSL 型への対応付けです。 次の表記

e : T

は、Tが WGSL 式eの静的型であることを意味する型表明です。

注： 型表明は、 プログラムのテキストに関する事実の記述です。 実行時検査ではありません。

文では式が頻繁に使用され、その式の静的型に要件が課される場合があります。 次に例を示します。

• if文の条件式は、bool型でなければなりません。

• 明示的な型が指定されたlet宣言では、初期化子 式はその型へ評価されなければなりません。

正常に構文解析された WGSL モジュールの型検査とは、 各式をその静的型に対応付け、 各文の型要件が満たされていることを検証する処理です。 型検査が失敗した場合、型エラーと呼ばれる、シェーダー作成エラーの特殊な場合になります。

型検査は、構文的な句に型規則を再帰的に適用することで実行できます。 ここで、構文的な句は、式または文のいずれかです。 型規則は、 構文的な句の静的文脈によって、 その句に含まれる式の静的型がどのように決定されるかを説明します。 型規則には、次の2つの部分があります。

• 結論。

  • 句が式である場合、結論はその式に対する型表明です。

  • 句が文である場合、結論は、その文の最上位式ごとに1つずつある、型表明の集合です。

  • どちらの場合も、構文的な句は図式的に指定され、 部分式または構文的に決定されるその他のパラメーターを表すために斜体の名前を使用します。

• 前提条件。次のものからなります。

  • 式の場合：

    • 部分式がある場合、その部分式に対する型表明。 各型表明は、直接満たすか、実行可能な自動変換（§ 6.1.2 変換ランクで定義）によって満たすことができます。 WGSL は、プログラムの静的型を決定するために必要なすべての定数式を評価します。

    • 式が文内でどのように使用されるか。

  • 文の場合：

    • 文の構文形式、および

    • 文内の最上位式に対する型表明。

  • 他の図式的パラメーターがある場合、そのパラメーターに関する条件。

  • 必要に応じて、その他の静的文脈。

型規則は、その前提条件および結論に型パラメーターを持つ場合があります。 型規則の結論または前提条件に型パラメーターが含まれている場合、その型規則をパラメーター化済みと呼びます。 型パラメーターが含まれていない場合、その規則を完全に具体化済みと呼びます。 パラメーター化された型規則の各型パラメーターを型で置換することにより、 完全に具体化された型規則を作成できます。 このとき、規則内にある同じパラメーターのすべての出現箇所には、同じ型を使用します。 規則の型パラメーターに型を割り当てることを、置換と呼びます。

たとえば、次に論理否定 （!e形式の式）の型規則を示します。

これは型パラメーターTを含むため、パラメーター化された規則です。 Tは、 bool、vec2<bool>、 vec3<bool>、またはvec4<bool>という4つの型のいずれかを表せます。 Tをvec3<bool>へ対応付ける置換を適用すると、 次の完全に具体化された型規則が生成されます。

規則の他の条件を満たす何らかの置換を適用することによって、 パラメーター化された規則から生成できる完全に具体化された各規則を、 そのパラメーター化された規則のオーバーロードと呼びます。 たとえば、真偽値否定規則には4つのオーバーロードがあります。 これは、その型パラメーターTへ型を割り当てる方法が4通りあるためです。

注： 言い換えると、パラメーター化された型規則は、 完全に具体化された型規則の集合に対するパターンを提供します。 各規則は、パラメーター化された規則に異なる置換を適用することで生成されます。

次の場合、型規則が構文的な句に適用されます。

• 規則の結論が、構文的な句の有効な構文解析に一致し、かつ

• 規則の前提条件が満たされる。

パラメーター化された型規則は、 式に適用される完全に 具体化された型規則を生成する置換が存在する場合、 その式に適用されます。

式1u+2uについて考えます。 この式には、1uおよび2uという2つのリテラル部分式があり、 どちらもu32型です。 最上位 式は加算です。 § 8.8 算術式の規則を参照すると、次の理由により、加算の型規則が この式に適用されます。

• 1u+2uはe1+e2形式の構文解析に一致し、e1は 1uを、e2は2uを表し、かつ

• e1はu32型であり、かつ

• e2はu32型であり、かつ

• 型規則の型パラメーターTをu32で置換でき、その結果、 式全体に適用される完全に具体化された規則が得られる。

構文的な 句を解析するとき、次の3つの場合があります。

• 式に適用される型規則がない場合。これは型エラーになります。

• 正確に1つの完全に 具体化された型規則が式に適用される場合。 この場合、その規則の結論が表明され、式の静的型が決定されます。

• 複数の型規則が適用される場合。すなわち、複数のオーバーロードの前提条件が満たされる場合。 この場合、§ 6.1.3 オーバーロード解決で説明する優先順位決定手順が使用されます。

  • オーバーロード解決が成功した場合、単一のオーバーロードが式に適用されるものとして決定されます。 そのオーバーロードの結論に含まれる型表明が表明され、 したがって、構文的な 句内の1つまたは複数の式の型が決定されます。

  • オーバーロード解決が失敗した場合、型エラーになります。

上記の例を続けると、式1u+2uには1つの型規則だけが適用されるため、 型検査は、その型規則の結論、すなわち1u+2uがu32型であることを 受け入れます。

WGSL ソースプログラムは、次の場合に適切に型付けされているといいます。

• 型規則を適用することで、プログラム内の各式の静的型を決定でき、かつ

• 各文の型要件が満たされている。

それ以外の場合、型エラーがあり、 ソースプログラムは有効な WGSL モジュールではありません。

WGSL は静的型付け言語です。 これは、プログラムのソーステキストを検査するだけで、WGSL モジュールの型検査が成功するか、 型エラーを検出するためです。

6.1.1. 型規則表

式に対する WGSL の型規則は、 型規則ごとに1行を割り当てた型規則 表として編成されます。

式の 意味論とは、その式を評価することによる効果であり、 主として結果値を生成することです。 式に適用される型規則の説明列は、その式の意味論を規定します。 意味論は通常、あらゆる部分式について想定される値を含め、 型規則のパラメーターの値に依存します。 式の意味論には、部分式の結果値以外の効果など、 結果値の生成以外の効果が含まれることもあります。

fn foo(p : ptr<function, i32>) -> i32 {
  let x = *p;
  *p += 1;
  return x;
}

fn bar() {
  var a: i32;
  let x = foo(&a); // foo の呼び出しは値を返し
                   // a の値を更新する
}

6.1.2. 変換ランク

型表明 e:T が型規則の前提条件として使用される場合、 次のとき満たされます：

• e がすでに型 T である、または

• e が型 S であり、かつ型 S が、以下で定義するように型 T へ自動的に 変換可能である。

この規則は、型の組に対するConversionRank 関数として、以下の表に定式化されています。 ConversionRank 関数は、 ある型（Src）の値を別の型（Dest）へ自動変換する場合の優先度と実行可能性を表します。 ランクが低いほど優先されます。

実行可能な 自動変換は、型 Src の値を型 Dest へ変換するものであり、 ConversionRank(Src,Dest) が有限である場合に許可されます。 このような変換は、§ 15.7 浮動小数点評価で説明する制限の範囲内で、 値を保持します。

注： 自動変換が行われる状況は2種類だけです。 第1は、定数式を、GPU で使用できる対応する型付き数値へ変換するときです。 第2は、メモリへの参照からロードが行われ、そのメモリに格納された値が得られるときです。

注： ランクが無限大の変換は実行不可能、すなわち 許可されません。

注： 変換が行われない場合、変換ランクは 0 です。

1. これらの変換には、unrestricted_pointer_parameters および buffer_view 言語機能が必要です。

次の場合、型 T は型 S の具象化です：

• T が具象であり、かつ

• T が参照型ではなく、かつ

• T がスウィズルビュー型ではなく、かつ

• ConversionRank(S, T) が有限であり、かつ

• 上記の基準を満たす他の任意の型 T2 について、ConversionRank(S, T2) > ConversionRank(S, T) である。

型 T の値 e の具象化 された値とは、T を T の具象化へ写像する実行可能な変換を e に適用して得られる値です。

注： f32 への変換は常に f16 より優先されるため、 モジュール内で f16 拡張が有効になっている場合に限り、 自動変換によって f16 値が生成されます。

6.1.3. オーバーロード解決

複数の型規則が構文句に適用される場合、 どれを有効にするか決定するために、同順位を解消する手続きが使用されます。 この手続きはオーバーロード解決と呼ばれ、 型検査によって部分式の静的型がすでに正常に検出されていることを前提とします。

構文 句 P と、P に適用されるすべての型規則について考えます。 オーバーロード解決アルゴリズムでは、これらの型規則をオーバーロード候補と呼びます。 各候補について：

• その前提条件は、直接または自動 変換によって満たされています。

• その結論には、次のものがあります：

  • P の有効な構文解析に一致する構文形式、および

  • P 内の各トップレベル式に対応する型 表明。

P のオーバーロード解決は、単一の最も優先されるオーバーロード 候補を見つけることを目的として、次のように進行します：

1. 各候補 C について、構文句内の部分式の変換ランクを列挙します。 候補の前提条件は満たされているため、P 内の i 番目の部分式について：

   • その静的型は計算済みです。

   • 式の静的型から、前提条件内の対応する型表明が要求する型への実行可能な自動変換があります。 C.R(i) を、その変換のConversionRank とします。

2. 実行可能な自動変換後に、ある部分式が抽象型へ解決される一方、 候補内の別の部分式が定数式ではない候補を除外します。

   注： その結果、構文句内のいずれかの部分式が定数式でない場合、 構文句内のすべての部分式は具象型を持たなければなりません。

3. 候補をランク付けします：2つのオーバーロード候補 C1 と C2 が与えられたとき、次の場合に C1 は C2 より優先されます：

   • P 内の各式位置 i について、C1.R(i) ≤ C2.R(i)。

     • すなわち、C1 を P に適用するために必要な各式変換が、 C2 を P に適用するために必要な対応する式変換と同等以上に優先されます。

   • C1.R(i) < C2.R(i) となる式位置 i が少なくとも1つあります。

     • すなわち、C1 を適用するために必要な式変換のうち少なくとも1つが、 C2 を適用するために必要な対応する変換より厳密に優先されます。

4. 他のすべての候補より優先される候補 C が1つだけある場合、 オーバーロード解決は成功し、候補の型規則 C が得られます。 それ以外の場合、オーバーロード解決は失敗します。

6.2. 単純型

単純型は、真偽値、数値、ベクトル、 行列、またはそのような値の集約を機械上で表現するための型です。

単純型は、スカラー型、アトミック型、 または複合型のいずれかです。

注： WGSL の単純型は C++ の Plain-Old-Data 型に似ていますが、 アトミック型と抽象数値型も含みます。

6.2.1. 抽象数値型

これらの型を WGSL ソース内に記述することはできません。これらは型検査でのみ使用されます。

特定の式はシェーダー作成時に、 GPU で直接実装される範囲よりも大きい場合がある数値範囲と精度を使用して評価されます。

WGSL は、これらの評価のために2つの抽象数値型を定義します：

• AbstractInt 型は、符号ビットを最上位ビット位置に置く64ビット2の補数形式で表現可能な整数の集合です。

• AbstractFloat 型は、IEEE-754 のbinary64（倍精度）形式で表現可能な 有限浮動小数点数の集合です。

これらの型のいずれかで式を評価するとき、オーバーフローしたり、無限大または NaN 値を生成したりしてはなりません。

抽象数値型であるか、抽象数値型を含む場合、その型は抽象です。 抽象でない場合、その型は具象です。

接尾辞のない数値リテラルは、 抽象数値型の値を表します：

• i または u 接尾辞のない整数リテラルは、 AbstractInt 値を表します。

• f または h 接尾辞のない浮動小数点リテラルは、 AbstractFloat 値を表します。

例：式 log2(32) は次のように解析されます：

• log2(32) は、オペランドとして AbstractInt 値 32 を持つ、組み込み関数 log2 の関数呼び出しとして構文解析されます。

• 整数スカラーの仮パラメーターを持つ log2 のオーバーロードはありません。

• 代わりにオーバーロード 解決が適用され、3つの可能なオーバーロードと実行可能な 自動変換が考慮されます：

  • AbstractInt から AbstractFloat。（変換ランク 4）

  • AbstractInt から f32。（変換ランク 5）

  • AbstractInt から f16。（変換ランク 6）

• 結果となる計算は AbstractFloat として行われます（例：log2(32.0)）。

例：式 1 + 2.5 は次のように解析されます：

• 1 + 2.5 は、部分式として AbstractInt 値 1 と AbstractFloat 値 2.5 を持つ加算演算として構文解析されます。

• e が整数型で f が浮動小数点型である場合の e+f のオーバーロードはありません。

• ただし、実行可能な自動変換を使用すると、3つの潜在的なオーバーロードがあります：

  • 1 は AbstractFloat 値 1.0 に変換され（ランク 4）、 2.5 は AbstractFloat のままです（ランク 0）。

  • 1 は f32 値 1.0f に変換され（ランク 5）、2.5 は f32 値 2.5f に変換されます（ランク 1）。

  • 1 は f16 値 1.0f に変換され（ランク 6）、2.5 は f16 値 2.5h に変換されます（ランク 2）。

• 最初のオーバーロードが優先される候補となり、型検査は成功します。

• 結果となる計算は AbstractFloat の 1.0 + 2.5 として行われます。

例：let x = 1 + 2.5;

• この例は上記と似ていますが、x は抽象数値型へ解決できません。

• したがって、実行可能なオーバーロード候補は2つあります。f32 または f16 を使用する加算です。

• 優先される候補は f32 を使用します。

• この宣言の効果は、let x : f32 = 1.0f + 2.5f; と記述した場合と同じです。

例：1u + 2.5 はシェーダー作成エラーになります：

• 1u 項は u32 型の式です。

• 2.5 項は AbstractFloat 型の式です。

• 有効なオーバーロード候補はありません：

  • GPU 上で実体化された整数スカラー型から 浮動小数点型への実行可能な自動変換はありません。

  • e が整数 スカラー型で、f が浮動小数点型である e+f に一致する型規則はありません。

例：-1 * i32(-2147483648) はシェーダー作成エラーになりません：

• -1 項は AbstractInt 型の式です。

• i32(-2147483648) 項は i32 型の式です。

• これら2つの型に対する乗算演算子のオーバーロードはなく、i32 項を AbstractInt へ昇格変換することはできません。

• 実行可能な自動変換は AbstractInt から i32 への変換だけであるため：

  • 結果となる計算は i32 同士の乗算演算になります。

  • i32 演算は2の補数算術を使用し、 オーバーフロー時の動作が定義されています。

  • ラップアラウンドが発生します。

// 明示的に型指定された符号なし整数リテラル。
var u32_1 = 1u; // 変数は u32 を保持する

// 明示的に型指定された符号付き整数リテラル。
var i32_1 = 1i; // 変数は i32 を保持する

// 明示的に型指定された浮動小数点リテラル。
var f32_1 = 1f; // 変数は f32 を保持する

// 明示的に型指定された符号なし整数リテラルを負にすることはできない。
var u32_neg = -1u; // 無効：単項マイナスは u32 をサポートしない

// 具象型が必要であるものの、文や式のどの部分も特定の具象型を
// 強制しない場合、整数リテラルは i32 値として解釈される：
//   let 宣言の初期化子は構築可能（またはポインター）でなければならない。
//   AbstractInt から構築可能型への最も優先される自動変換は
//   変換ランク 2 の AbstractInt から i32 への変換である。そのため '1' は i32 と推論される。
let some_i32 = 1; // let some_i32: i32 = 1i; と同様

// 宣言の型から推論される。
var i32_from_type : i32 = 1; // 変数は i32 を保持する。AbstractInt から i32、変換ランク 2
var u32_from_type : u32 = 1; // 変数は u32 を保持する。AbstractInt から u32、変換ランク 3

// 接尾辞のない整数リテラルは、必要な場合に浮動小数点へ変換できる：
//   変換ランク 5 で AbstractInt を f32 へ自動変換する。
var f32_promotion : f32 = 1; // 変数は f32 を保持する

// 無効：浮動小数点から整数への実行可能な変換はない
var i32_demotion : i32 = 1.0; // 無効

// 式から推論される。
var u32_from_expr = 1 + u32_1; // 変数は u32 を保持する
var i32_from_expr = 1 + i32_1; // 変数は i32 を保持する

// 値は表現可能でなければならない。
let u32_too_large   : u32 = 1234567890123456890; // 無効、オーバーフロー
let i32_too_large   : i32 = 1234567890123456890; // 無効、オーバーフロー
let u32_large : u32 = 2147483649; // 有効
let i32_large : i32 = 2147483649; // 無効、オーバーフロー
let f32_out_of_range1 = 0x1p500; // 無効、範囲外
let f32_hex_lost_bits = 0x1.0000000001p0; // 無効、f32 で正確に表現できない

// 最小整数：AbstractInt に対する単項否定の後、i32 を推論する。
// AbstractInt から構築可能型への最も優先される変換（最小の
// 変換ランクを持つもの）は、AbstractInt から i32 への変換である。
let i32_min = -2147483648;  // 型は i32

// 無効。上記と同様に AbstractInt から i32 を選択するが、値が
// 範囲外であり、シェーダー作成エラーが発生する。
let i32_too_large_2 = 2147483648; // 無効。

// 部分式は AbstractInt および AbstractFloat へ解決できる。
// 次の例はすべて有効であり、変数の値は 6u である。
var u32_expr1 = (1 + (1 + (1 + (1 + 1)))) + 1u;
var u32_expr2 = 1u + (1 + (1 + (1 + (1 + 1))));
var u32_expr3 = (1 + (1 + (1 + (1u + 1)))) + 1;
var u32_expr4 = 1 + (1 + (1 + (1 + (1u + 1))));

// 組み込み関数のパラメーターに基づく推論。

// 最も優先される候補は clamp(i32,i32,i32)->i32
let i32_clamp = clamp(1, -5, 5);
// 最も優先される候補は clamp(u32,u32,u32)。
// リテラルは AbstractInt から u32 への自動変換を使用する。
let u32_clamp = clamp(5, 0, u32_from_expr);
// 最も優先される候補は clamp(f32,f32,f32)->f32
// リテラルは AbstractInt から f32 への自動変換を使用する。
let f32_clamp = clamp(0, f32_1, 1);

// 次の例はすべて f32 に昇格し、初期値は 10f となる。
let f32_promotion1 = 1.0 + 2 + 3 + 4;
let f32_promotion2 = 2 + 1.0 + 3 + 4;
let f32_promotion3 = 1f + ((2 + 3) + 4);
let f32_promotion4 = ((2 + (3 + 1f)) + 4);

// 型規則違反。

// 無効。初期化子は f32 にしか解決できない：
// AbstractFloat から u32 への実行可能な自動変換はない。
let mismatch : u32 = 1.0;

// 無効。異なる符号のパラメーターを許容する clamp のオーバーロードはない。
let ambiguous_clamp = clamp(1u, 0, 1i);

// 推論は文レベルで完了する。

// let 宣言の初期化子は構築可能（またはポインター）でなければならない。
// AbstractInt から構築可能型への最も優先される自動変換は
// 変換ランク 2 の AbstractInt から i32 への変換である。そのため '1' は i32 と推論される。
let some_i32 = 1; // let some_i32: i32 = 1i; と同様

let some_f32 : f32 = some_i32; // 型エラー：i32 を f32 に代入することはできない

// 別のオーバーフローのケース
let overflow_u32 = (1 -2) + 1u; // 無効、-1 は u32 の範囲外

// 理想値は32ビットの範囲外だが、範囲内に戻される
let out_and_in_again = (0x1ffffffff / 8);

// 同様だが無効
let out_of_range = (0x1ffffffff / 8u); // 計算を32ビットで行う必要があるため、
                                       // 0x1ffffffff が範囲外になる。

6.2.2. 真偽値型

bool 型は、 true と false の値を含みます。

6.2.3. 整数型

u32 型は、 32ビット符号なし整数の集合です。

i32 型は、 32ビット符号付き整数の集合です。 これは、符号ビットを最上位ビット位置に置く2の補数表現を使用します。

オーバーフローする式を具象整数型に対して評価すると、 2^bitwidth を法とする結果が生成されます

注： AbstractInt も整数型です。

6.2.4. 浮動小数点型

f32 型は、 IEEE-754 のbinary32（単精度）形式による 32ビット浮動小数点値の集合です。 詳細については、§ 15.7 浮動小数点評価を参照してください。

f16 型は、 IEEE-754 のbinary16（半精度）形式による 16ビット浮動小数点値の集合です。プログラムに enable f16; ディレクティブが含まれ、f16 拡張が有効になっていない状態で f16 型を使用すると、シェーダー作成 エラーになります。詳細については、§ 15.7 浮動小数点評価を参照してください。

次の表は、浮動小数点型の特定の極値を示します。 それぞれに対応する負の値があります。

注： AbstractFloat も浮動小数点型です。

6.2.5. スカラー型

スカラー型は、bool、AbstractInt、 AbstractFloat、i32、u32、f32、および f16 です。

数値スカラー型は、 AbstractInt、 AbstractFloat、i32、u32、f32、および f16 です。

整数スカラー型は、 AbstractInt、i32、および u32 です。

スカラー変換は、 あるスカラー型の値を別のスカラー型の値へ写像します。 一般に、結果値は変換先の型による制限の範囲内で、元の値に近い値になります。 スカラー変換は、次のいずれかによって行われます：

• 値コンストラクターを明示的に呼び出す、または

• 抽象数値型の定数式を、 実行可能な自動変換によって別の型へ変換する。

6.2.6. ベクトル型

ベクトルは、2個、3個、または4個の スカラー成分をまとめた列です。

成分型が数値スカラーである場合、そのベクトルは数値 ベクトルです。

ベクトルの主な用途には、次のものがあります：

• 方向と大きさの両方を表す。

• 空間内の位置を表す。

• 特定の色空間における色を表す。 たとえば、各成分を赤、緑、青の強度とし、 4番目の成分をアルファ（不透明度）値とすることができます。

ベクトル（および行列）に対する多くの演算は、 成分ごとに作用します。すなわち、 各スカラー成分を独立して演算することで結果が形成されます。

vec2<f32>  // 2個の f32 からなるベクトル。

let x : vec3<f32> = a + b; // a と b は vec3<f32>
// x[0] = a[0] + b[0]
// x[1] = a[1] + b[1]
// x[2] = a[2] + b[2]

WGSL は、次の型エイリアスも事前宣言します：

6.2.7. 行列型

行列は、2個、3個、または4個の 浮動小数点ベクトルをまとめた列です。

行列の主な用途は、線形変換を表現することです。 この解釈では、行列のベクトルは列ベクトルとして扱われます。

積演算子（*）は、次のいずれかに使用されます：

• スカラー量によって変換を拡大縮小する。

• 変換をベクトルに適用する。

• 変換を別の行列と合成する。

§ 8.8 算術式を参照してください。

mat2x3<f32>  // これは32ビット浮動小数点数による2列3行の行列。
             // 同等に、型 vec3<f32> の2個の列ベクトルである。

WGSL は、次の型エイリアスも事前宣言します：

6.2.8. アトミック型

アトミック型は、 次のような具象整数スカラー型を 内包します：

• アトミックオブジェクトは、並行する観察者に特定の保証を提供し、かつ

• アトミックオブジェクトに対する有効な演算は、アトミック 組み込み関数だけです。

式を評価した結果がアトミック型になってはなりません。

アトミック型は、workgroup アドレス空間内の変数、または read_write アクセスモードを持つストレージ バッファ変数によってのみインスタンス化できます。 この型に対する演算のメモリスコープは、それがインスタンス化されるアドレス空間によって決まります。 workgroup アドレス空間内のアトミック型は、 Workgroup のメモリスコープを持ちます。一方、 storage アドレス空間内のものは、QueueFamily のメモリスコープを持ちます。

アトミック 変更とは、アトミックオブジェクトの内容を設定する、そのオブジェクトに対する任意の 演算です。 新しい値がオブジェクトの既存の値と同じであっても、その演算は変更として数えられます。

WGSL では、アトミック変更はオブジェクトごとに相互に順序付けられます。 すなわち、シェーダーステージの実行中、各アトミックオブジェクト A について、すべての エージェントは A に適用された変更演算を同じ順序で観察します。 異なるアトミックオブジェクトの順序付けには、いかなる関係もない場合があります。 因果関係は含意されません。 workgroup 空間内の変数は、 1つのワークグループ内では共有されますが、 異なるワークグループ間では共有されないことに注意してください。

6.2.9. 配列型

配列は、 インデックスでアクセス可能な要素値の列です。

配列の最初の要素のインデックスは 0 であり、後続の各要素は次の整数インデックスにあります。 § 8.5.3 配列アクセス式を参照してください。

式を評価した結果が実行時サイズ配列型になってはなりません。

固定サイズ配列の要素数式 N には、次の制約が適用されます：

• オーバーライド式でなければなりません。

• 評価結果が具象整数スカラーにならなければなりません。

• N が0より大きくない場合：

  • N が定数式である場合、シェーダー作成エラーになります。

  • それ以外の場合、パイプライン作成エラーになります。

注： N がオーバーライド宣言に依存する場合、要素数の値はパイプライン作成時に完全に決定され、 それ以外の場合はシェーダーモジュール作成時に完全に決定されます。

注： 型の等価性を満たすには、定数式ではないオーバーライド式が 識別子でなければなりません。 オーバーライド可能な定数によってサイズが決まるワークグループ変数を参照してください

実行時サイズ配列の要素数は、対応するストレージバッファ変数に関連付けられた バッファバインディングのサイズによって決定されます。 § 13.3.4 バッファバインディングによる 実行時サイズ配列の要素数の決定を参照してください。

配列の要素型は、次のいずれかでなければなりません：

• スカラー型

• ベクトル型

• 行列型

• アトミック型

• 作成時固定フットプリントを持つ配列型

• 作成時固定フットプリントを持つ構造体型。

注： 配列の要素型をバッファ型にすることはできません。

注： 要素型は単純型でなければなりません。

2つの配列型が同じであるための必要十分条件は、次のすべてが成り立つことです：

• 要素型が同じである。

• 要素数の指定が一致する、すなわち次のいずれかが成り立つ：

  • 両方とも実行時サイズである。

  • 両方とも作成時固定フットプリントを持つ固定サイズであり、 一方が符号付きで他方が符号なしであっても、要素数の値が等しい。 （要素数は常に正であるため、この場合は符号付き値と符号なし値を比較できます。）

  • 両方とも固定サイズであり、要素数が、パイプラインでオーバーライド可能な定数の 同じ宣言へ解決される識別子として指定されている。

// array<f32,8> と array<i32,8> は異なる型：
// 要素型が異なる
var<private> a: array<f32,8>;
var<private> b: array<i32,8>;
var<private> c: array<i32,8u>;  // array<i32,8> と array<i32,8u> は同じ型

const width = 8;
const height = 8;

// array<i32,8>、array<i32,8u>、および array<i32,width> は同じ型。
// これらの要素数の評価結果は 8 になる。
var<private> d: array<i32,width>;

// array<i32,height> と array<i32,width> は同じ型。
var<private> e: array<i32,width>;
var<private> f: array<i32,height>;

注： オーバーライド可能な定数によってサイズが決まる配列型の 有効な用途は、workgroup アドレス空間内のメモリビューだけです。 これには、ワークグループ変数の格納型が含まれます。 § 7 変数および値の宣言を参照してください。

override blockSize = 16;

var<workgroup> odds: array<i32,blockSize>;
var<workgroup> evens: array<i32,blockSize>; // 同じ型

// 次のものはいずれも 'odds' および 'evens' と同じ型ではない。

// 異なる型：識別子 'blockSize' ではない
var<workgroup> evens_0: array<i32,16>;
// 異なる型：要素数の表現に算術を使用している。
var<workgroup> evens_1: array<i32,(blockSize * 2 / 2)>;
// 異なる型：識別子だけでなく、括弧を使用している。
var<workgroup> evens_2: array<i32,(blockSize)>;

// オーバーライド可能な要素数は外側のレベルにしか現れることができないため、
// 無効な例。
// var<workgroup> both: array<array<i32,blockSize>,2>;

// オーバーライド可能な要素数はワークグループ変数に対してのみ
// 有効であるため、無効な例。
// var<private> bad_address_space: array<i32,blockSize>;

6.2.10. 構造体型

構造体は、 名前を持つメンバー値を 名前付きでグループ化したものです。

構造体型はモジュールスコープで宣言されます。 プログラムソース内の他の場所では、構造体型はその識別子名によって表されます。 § 5 宣言とスコープを参照してください。

2つの構造体型が同じであるための必要十分条件は、それらが同じ名前を持つことです。

構造体のメンバー型は、次のいずれかでなければなりません：

• スカラー型

• ベクトル型

• 行列型

• アトミック型

• 作成時固定フットプリントを持つ固定サイズ 配列型

• 実行時サイズ配列型。 ただし、それが構造体の最後のメンバーである場合に限ります

• 作成時固定フットプリントを持つ構造体型

注： 構造体のメンバー型をバッファ型にすることはできません。

注： ユーザーが宣言したすべての構造体型は具象です。

注： 各メンバー型は単純型でなければなりません。

構造体のメンバー型と配列の要素型に対する制限から得られる帰結には、次のものがあります：

• ポインター、テクスチャ、またはサンプラーが、配列または構造体内のいずれかの入れ子レベルに 現れてはなりません。

• 実行時サイズ配列が より大きな型の一部である場合、それは構造体の最後の要素としてのみ使用できます。 さらに、その構造体自体を、それを囲む配列または構造体の一部にすることはできません。

// 3つのメンバーを持つ構造体。
struct Data {
  a: i32,
  b: vec2<f32>,
  c: array<i32,10>, // 最後のカンマは省略可能
}

// 型 Data の値を格納する変数を宣言する。
var<private> some_data: Data;

構造体のメンバーには、次の属性を適用できます：

• align

• builtin

• location

• blend_src

• interpolate

• invariant

• size

属性 builtin、location、blend_src、 interpolate、 および invariant は IO 属性です。 構造体 S のメンバーに付けられたIO 属性は、 S がエントリーポイントの仮パラメーターまたは戻り値の型として使用される場合にのみ効果を持ちます。 § 13.3.1 ステージ間の入力および出力インターフェイスを参照してください。

属性 align および size はレイアウト属性であり、 構造体型を使用してuniform バッファまたはストレージバッファを定義する場合に必要となることがあります。 § 14.4 メモリレイアウトを参照してください。

struct my_struct {
  a: f32,
  b: vec4<f32>
}

// 実行時配列
alias RTArr = array<vec4<f32>>;
struct S {
  a: f32,
  b: f32,
  data: RTArr
}
@group(0) @binding(0) var<storage> buffer: S;

6.2.11. 複合型

他の型の組み合わせとして表される内部構造を持つ場合、その型は複合です。 内部の各部分は重なり合わず、成分と呼ばれます。 複合値は、その成分へ分解できます。§ 8.5 複合値の分解式を参照してください。

複合型は次のとおりです：

• ベクトル型

• 行列型

• 配列型

• 構造体型

複合型 T について、NestDepth(T) と記述する T の入れ子の深さは、次のとおりです：

• ベクトル型の場合は 1

• 行列型の場合は 2

• 要素型が E である配列型の場合は 1 + NestDepth(E)

• T がメンバー型 M₁,...,M_N を持つ構造体型である場合は、 1 + max(NestDepth(M₁),..., NestDepth(M_N))

6.2.12. 構築可能型

多くの種類の値は、作成、ロード、格納、関数への受け渡し、 および関数からの返却が可能です。 これらを構築可能と呼びます。

次のいずれかである場合、その型は構築可能です：

• スカラー型

• ベクトル型

• 行列型

• 作成時固定フットプリントを持ち、 その要素型が構築可能である固定サイズ 配列型。

• すべてのメンバーが構築可能である構造体型。

注： すべての構築可能型は作成時固定フットプリントを持ちます。

注： アトミック型と実行時サイズ配列型は構築可能ではありません。 アトミック型および実行時サイズ配列を含む複合型も構築可能ではありません。

6.2.13. 固定フットプリント型

変数のメモリフットプリントとは、 変数の内容を格納するために使用されるメモリ位置の数です。 変数のメモリフットプリントは、その格納型に依存し、 シェーダーのライフサイクルのいずれかの時点で確定します。 ほとんどの変数のサイズは、非常に早いシェーダー作成時に決定されます。 一部の変数のサイズは、より後のパイプライン作成時に決定され、 さらに別のものはシェーダー実行の開始時になって初めて決定される場合があります。

ある型の具象化のサイズが、 シェーダー作成時に完全に決定される場合、その型は 作成時固定フットプリントを持ちます。

ある型のサイズがパイプライン作成時に完全に決定される場合、 その型は固定 フットプリントを持ちます。

注： すべての具象の作成時固定フットプリント型および 固定フットプリント型は格納可能です。

注： パイプライン作成はシェーダー作成に依存するため、 作成時固定フットプリントを持つ型は、 固定フットプリントも持ちます。

作成時固定フットプリントを持つ型は、次のとおりです：

• スカラー型

• ベクトル型

• 行列型

• アトミック型

• 次の場合の固定サイズ 配列型：

  • その要素 数が定数式である。

• すべてのメンバーが作成時固定フットプリントを持つ構造体型。

• 次の場合の固定サイズ バッファ型：

  • そのサイズが定数式である。

注： 構築可能型は作成時固定フットプリントを持ちます。

固定 フットプリントを持つ型は、次のいずれかです：

• 作成時固定フットプリントを持つ型

• 固定サイズ 配列型（その要素数をさらに制限しない）

• 固定サイズ バッファ型（そのサイズをさらに制限しない）

注： 要素数が定数式ではないオーバーライド式である固定サイズ配列の有効な用途は、 workgroup アドレス空間内の メモリビューだけです。 これには、ワークグループ変数の格納型が含まれます。

注： 固定フットプリント型は、直接または間接的に アトミック型を含むことができますが、 構築可能型は含むことができません。

注： 固定フットプリント型には、 実行時サイズ配列、 実行時サイズバッファ、および実行時サイズ配列を含むすべての構造体が含まれません。

6.3. バッファ型

これらの型には、buffer_view 言語機能が必要です。

バッファ値は、 その内容を別のホスト共有可能型として解釈できるメモリを表します。 それ以外の点では、バッファ値は不透明です。 変数内のデータへ複数の異なる型としてアクセスする必要がある場合や、 シェーダー作成者が1つの変数を複数の論理変数へ分割したい場合に役立ちます。

バッファ型は構築可能ではなく、 buffer_view 組み込み関数によって そのデータを不透明でないホスト共有可能型として解釈した後にのみアクセスできます。

式を評価した結果が バッファ型になってはなりません。

固定サイズバッファは、storage、uniform、および workgroup アドレス空間内の変数によってのみインスタンス化できます。 storage および uniform アドレス空間では、サイズは定数式でなければなりません。 実行時サイズバッファは、storage アドレス空間内の変数によってのみインスタンス化できます。

N が0より大きくない場合：

• N が定数式である場合、シェーダー作成エラーになります。

• それ以外の場合、パイプライン作成エラーになります。

f16 拡張が有効であり、 N が2で割り切れない場合：

• N が定数式である場合、シェーダー作成エラーになります。

• それ以外の場合、パイプライン作成エラーになります。

f16 拡張が有効ではなく、 N が4で割り切れない場合：

• N が定数式である場合、シェーダー作成エラーになります。

• それ以外の場合、パイプライン作成エラーになります。

次の条件のいずれかが成り立つ場合に限り、2つのバッファ型は同じです：

• 両方とも実行時サイズである。

• 両方とも作成時固定フットプリントを持つ固定サイズであり、 一方が符号付きで他方が符号なしであっても、サイズの値が等しい。 （サイズは常に正であるため、この場合は符号付き値と符号なし値を比較できます。）

• 両方とも固定サイズであり、サイズが、パイプラインでオーバーライド可能な定数の 同じ宣言へ解決される識別子として指定されている。

6.4. 列挙型

列挙型は、 名前を持つ有限の値の集合です。 列挙型は、有効なテクセル形式の集合など、特定の概念に対する選択肢の集合を区別するために使用されます。

列挙子は、 列挙型に含まれる名前付きの値の1つです。 各列挙子は、 他のすべての列挙子、および他のすべての種類の値とは異なります。

WGSL ソース内で新しい列挙子または新しい列挙型を宣言する仕組みはありません。

注： 列挙子はテンプレートパラメーターとして使用されます。

6.4.1. 事前宣言済みの列挙子

次の表は、WGSL の列挙型、その事前宣言済みの列挙子、および列挙型に必要な言語拡張を示します。 列挙型は存在しますが、WGSL ソース内に記述することはできません。

6.5. メモリビュー

WGSL プログラムは、単純値による計算に加えて、 メモリアクセス演算によって、 メモリから値を読み取ったり、メモリへ値を書き込んだりすることもよくあります。 各メモリアクセスは、メモリビューを介して実行されます。

メモリビューは、 次のものから構成されます：

• 特定のアドレス空間内にある一連のメモリ 位置、

• メモリモデル参照、

• それらの位置の内容を WGSL の型として解釈したもの。これは格納型と呼ばれます、および

• アクセスモード。

メモリビューのアクセスモードは、アドレス空間によってサポートされていなければなりません。 § 7 変数および値の宣言を参照してください。

6.5.1. 格納可能型

変数に含まれる値は、 格納可能型でなければなりません。 格納可能型は、§ 14.4.4 値の内部レイアウトで説明するように、 WGSL によって定義された明示的な表現を持つ場合があります。また、 テクスチャやサンプラーのように不透明である場合もあります。

ある型が具象であり、かつ次のいずれかである場合、 その型は格納可能です：

• スカラー型

• ベクトル型

• 行列型

• アトミック型

• 配列型

• 構造体型

• テクスチャ型

• サンプラー型

• バッファ型

注： すなわち、格納可能型とは、 具象単純型、 テクスチャ型、サンプラー型、およびバッファ型です。

6.5.2. ホスト共有可能型

ホスト共有可能型は、ホストと GPU の間で共有されるバッファ、 または形式変換を行わずにホストと GPU の間でコピーされるバッファの内容を記述するために使用されます。 この目的で使用する場合、§ 14.4 メモリレイアウトで説明するように、 その型へレイアウト属性を追加で適用できます。 § 7.3 var 宣言で説明するように、uniform バッファ変数およびストレージバッファ変数の格納型は、 ホスト共有可能でなければなりません。

ある型が具象であり、かつ次のいずれかである場合、 その型はホスト共有可能です：

• 数値スカラー型

• 数値ベクトル型

• 行列型

• アトミック型

• 作成時固定フットプリントを持ち、 その要素型がホスト共有可能である固定サイズ 配列型

• その要素型がホスト共有可能である実行時サイズ配列型

• すべてのメンバーがホスト共有可能である構造体型

• バッファ型

注： ステージ間の入力および出力の型に対する制限は、 § 13.3.1 ステージ間の入力および出力インターフェイスおよび それ以降の節で説明します。 これらの型にもサイズがありますが、数え方は異なります。

注： テクスチャと サンプラーもホストと GPU の間で共有できますが、その内容は不透明です。 この節のホスト共有可能型は、特にstorage および uniform バッファで使用するためのものです。

6.5.3. 参照型とポインター型

WGSL には、メモリビューを表現するための2種類の型があります： 参照型とポインター型です。

2つのポインター型が同じであるための必要十分条件は、アドレス空間、格納型、およびアクセスモードが同じであることです。

WGSL モジュールを解析するとき、参照型とポインター型は、 アドレス空間、格納可能型、およびアクセスモードによって完全にパラメーター化されます。 この仕様のコード例では、コメントにこの完全にパラメーター化された形式を示します。

ただし、WGSL のソーステキストでは：

• 参照型が現れてはなりません。

• ポインター型は現れることができます。

  • ポインター型は、次のパラメーターを指定して記述されます：

    • アドレス空間、

    • 格納型、および

    • § 14.3 アドレス空間で規定するように、場合によっては アクセスモード。

  • ポインター型がプログラムソース内に現れる場合、 プログラム内のいずれかの場所で、そのポインター型の アドレス空間、格納 型、およびアクセスモードを使用して、 変数を宣言すること、または 関数呼び出しからその型を返すことも有効で なければなりません。

    注： この制限は、実行時に決して使用できない特定の 型エイリアスおよび関数の仮パラメーターの宣言を禁止します。 この制限がなければ、ポインター型へのエイリアスを宣言することは有効でも、 その型のポインター値を作成することは決してできない場合があります。 同様に、ポインターの仮パラメーターを持つ関数を宣言することは有効でも、 その関数を呼び出すことは決してできない場合があります。

fn my_function(
  /* 'ptr<function,i32,read_write>' は、'function' アドレス空間内の
     メモリ位置を使用して、'i32' 値を保持するメモリを参照する
     ポインター値の型である。ここで 'i32' は格納型である。
     暗黙のアクセスモードは 'read_write' である。
     既定値については「アドレス空間」の節を参照。 */
  ptr_int: ptr<function,i32>,

  // 'ptr<private,array<f32,50>,read_write>' は、'private' アドレス空間内の
  // メモリ位置を使用して、型 'f32' の50個の要素からなる配列を保持する
  // メモリを参照するポインター値の型である。
  // ここで格納型は 'array<f32,50>' である。
  // 暗黙のアクセスモードは 'read_write' である。
  // 既定値については「アドレス空間」の節を参照。
  ptr_array: ptr<private, array<f32, 50>>
) { }

参照型とポインター型は、どちらもメモリビューの集合です。 特定のメモリビューには、一意の参照値と一意のポインター値が関連付けられます：

型 ptr<AS,T,AM> の各ポインター値 p は、 型 ref<AS,T,AM> の一意の参照値 r に対応し、 その逆も成り立ちます。 ここで、p と r は同じメモリビューを記述します。

6.5.4. スウィズルビュー型

スウィズルビューは、 メモリ内のベクトルの成分の一部へアクセスし、 読み取り時にはそれらを並べ替え、書き込み時にはそれらを分散させるために使用できます。

スウィズルビューは、swizzle_assignment 言語拡張によって有効になります。

アルゴリズム： SwizzleViewRead

ポインター p を介して読み取ったベクトルの成分を選択し、 必要に応じて並べ替えて形成したベクトルを生成します。

注： スウィズルビューを介した読み取りでは、 一部のベクトル成分が結果に現れない場合でも、ベクトル全体をメモリから読み取ります。

入力：型 swizzle<AS,S,N,K> のスウィズル ビュー (p, IndexList)

出力：型 vecK<S> のベクトル値 v。 (p, IndexList) を読み取った結果です。

手順：

1. 慣例により、IndexList = « Idx₀, ..., Idx_K−1 » とします

2. p が参照するメモリからベクトル u を読み取ります。 u の型は vecN<S> です。

3. 次の条件を満たす、型 vecK<S> の値 v を形成します：

   • v の成分 i は、 u の成分 Idx_i の値に等しくなります。 インデックス構文を使用すると： v[i] = u[Idx_i]

アルゴリズム： SwizzleViewWrite

update ベクトルの成分を、ポインター p が参照する メモリ内のベクトルの指定された成分へ書き込みます。

注： スウィズルビューを介した書き込みでは、処理によって成分値が変化しない場合でも、 メモリ内のベクトル全体を書き込みます。

スウィズルビューへの書き込みと一様性解析およびメモリモデルとの相互作用については、 以下の説明を参照してください。

入力：

• 型 swizzle<AS,S,N,K> のスウィズルビュー (p, IndexList)

• 型 vecN<S> のベクトル old_contents

  • old_contents は、過去のある時点で p が参照するメモリに 格納されていたベクトルであることを意図しています。

• 型 vecK<S> のベクトル update

IndexList 内のすべてのインデックスは、互いに異なっていなければなりません。 この要件は K ≤ N を含意します。

変数：

• 型 vecN<S> の new

手順：

1. 慣例により、IndexList = « Idx₀, ..., Idx_K−1 » とします

2. 変数 new を old_contents で初期化します。

3. 0..K-1 内の各 i について：

   • new の成分 Idx_i を、 update の成分 i の値に設定します。 インデックス構文を使用すると： new[Idx_i] = update[i]。

4. new を p が参照するメモリへ書き込みます。

注： すべての Idx_i が異なることを要求することで、 ステップ3が new の各成分を最大1回だけ更新することが保証されます。

注： ステップ2と3は、次の宣言的な規則で置き換えることができます：

型 vecN<S> のベクトル new を形成します。 new の成分 i は、次のとおりです：

• 0...K−1 内のいずれかの j について i = Idx_j である場合、 update の成分 j。

• それ以外の場合、old_contents の成分 i。

スウィズルビューはスウィズルビュー型を持ちます：

スウィズルビューは、次の方法で形成されます：

• read_write アクセスモードを持ち、 格納型がベクトルである参照値またはポインター値へ、 複数文字のスウィズル名を適用する、または

• スウィズルビューへ複数文字のスウィズル名を適用する。

これらの規則により、スウィズルビューの IndexList 部分は、 シェーダー作成時に完全に決定されます。

詳細については、§ 8.6 スウィズルビュー式を参照してください。

fn swizzle_read_and_write() {
  var v: vec4u;

  // v.y = 1; v.z = 2; と同じ。
  // ただし、ベクトルのメモリからの読み取りとメモリへの書き込みは、それぞれ正確に1回だけ行われる。
  v.yz = vec2u(1,2);

  // let u = vec3(v.a, v.g, v.b); と同じ。
  // 式 v.agb は型 swizzle<function,u32,4,3> のスウィズルビューである。
  // let 宣言の実効値型は、具象で構築可能な型または
  // ポインター型でなければならない。そのため、スウィズルビューのロード規則を呼び出すことにより、
  // スウィズルビューは自動的に vec3u へ変換される。
  let u = v.agb;

  // スウィズルは連鎖できる。
  // v.zy = vec2(99,100); と同じ。
  v.yz.yx = vec2(99,100);

  // スウィズルビューへ1文字を適用すると、基となるベクトルの
  // スカラー成分への参照が得られる。
  // v.z = 99; と同じ。
  v.yz.y = 99;

  // スウィズルビューへインデックスを付けると、ベクトルの成分の1つへの参照が得られる。
  // これは1文字のベクトルアクセスを形成するかのように動作するが、
  // インデックスによって、スウィズル名のどの文字を使用するかが選択される。
  v.zy[1] = 50; // v.y = 50; と同じ。
}

// この例では、swizzle_assignment に加えて pointer_composite_access のサポートを前提とする。
requires pointer_composite_access;

fn swizzle_read_and_write_via_pointer(p: ptr<function,vec4u>) {
  // (*p).y = 1; (*p).z = 2; と同じ。
  p.yz = vec2u(1,2);

  // let u = vec3((*p).a, (*p).g, (*p).b); と同じ。
  let u = p.agb;

  // スウィズルは連鎖できる。
  // p.zy = vec2(99,100); と同じ。
  p.yz.yx = vec2(99,100);

  // ポインターからスウィズルビューを構築できる。
  // スウィズルビューへ1文字を適用すると、基となるベクトルの
  // スカラー成分への参照が得られる。
  // (*p).z = 99; と同じ。
  p.yz.y = 99;

  // スウィズルビューへインデックスを付けると、ベクトルの成分の1つへの参照が得られる。
  // これは1文字のベクトルアクセスを形成するかのように動作するが、
  // インデックスによって、スウィズル名のどの文字を使用するかが選択される。
  p.zy[1] = 50; // (*p).y = 50; と同じ。
}

fn invalid_swizzle_cases() {
  var v: vec2u;

  // 無効：成分を繰り返すスウィズルには代入できない
  v.xx = vec2u(1,2);

  // 無効：'z' は対象ベクトルの範囲外。
  v.xz = vec2u(1,2);
  let u = v.xz;

  // 無効：文字体系 xyzw と rgba を混在させてはならない
  v.xr = vec2u(1,2);

  // スウィズルビューのアドレスを取得することはできない。
  // ここで、v.xy はスウィズルビュー (&v,`01`) である
  // & 演算子はスウィズルビューに適用できないため、型検査は失敗する。
  let p = &v.xy;
}