複数のプラットフォーム用のコンピュートシェーダーの記述

クロスプラットフォームでの最良の実践法

DirectX 11 (DX11) は、他のプラットフォーム (Metal や OpenGL ES など) ではサポートされていない多くの操作をサポートしています。したがって、DX11 だけの環境を考えるより、サポートが少ないプラットフォームで、シェーダーの動作を明確に定義する必要があります。考慮すべき点は以下のとおりです。

• アウトオブバンドのメモリアクセスが悪い点。DX11 は、読み込み時に常にゼロを返し、問題なくデータの一部を読み込むかもしれませんが、サポートが少ないプラットフォームでは、これを行う際に GPU がクラッシュする可能性があります。DX11 特有のハック、スレッドグループサイズの倍数と一致しないバッファサイズ、バッファの先頭や末尾から隣接するデータ要素を読み取ろうとすること、などの同様の非互換性に注意してください。

• リソースを初期化する点。新しいバッファとテクスチャの内容は未定義です。プラットフォームの中にはすべてゼロを示すものもありますが、そうでないものでは、NaN を含めどんな値になることもありえます。

• コンピュートシェーダーが宣言するすべてのリソースをバインドします。シェーダーが分岐のために現在の状態でリソースを使用しないことが確実にわかっていても、リソースがバインドされていることを確認する必要があります。

# プラットフォーム特有の相違

• Metal (iOS と tvOS プラットフォーム用) は、テクスチャのアトミック操作をサポートしません。Metal は、バッファの GetDimensions クエリもサポートしません。必要な場合は、バッファサイズの情報を定数としてシェーダーに渡します。
• OpenGL ES 3.1 (Android、iOS、tvOS プラットフォーム用) は、一度に 4 つのコンピュートバッファしかサポートしません。実際の実装では、より多くをサポートすることもありますが、一般的には OpenGL ES 用に開発する場合は、それぞれのバッファに各データを格納するよりも、関連するデータを構造体でグループ化することを検討する必要があります。
• OpenGL (ES) および Vulkan では、書き込み専用ではない RWTextures<T> の画像形式修飾子が必要です。
  Unity は、この修飾子を山括弧内の型 T から派生させます。形式修飾子は、RWTexture にバインドされている RenderTexture の GraphicsFormat/RenderTextureFormat と一致する必要があります。以下の表は、Unity RenderTexture の GraphicsFormat と RenderTextureFormat を、対応する HLSL 型と画像形式修飾子にマップしたものです。