ブラウザ向け3Dは現在WebGLが使われていますが,WebKitやMozillaやGoogleなど様々な次世代APIが検討されています.
そこで使うシェーダ言語の１つとしてHLSLをベースにしたWHLSLの開発が進んでいますが,その詳細を解説した記事があります
Web High Level Shading Language
https://webkit.org/blog/8482/web-high-level-shading-language/
WHLSLに関しては,SIGGRAPH 2018のBoFのHLSL Realtime Shading Languageで知りました.BoFの説明ではW3Cというのがありますね.
SIGGRAPH 2018のBoFリスト
https://s2018.siggraph.org/conference/conference-overview/birds-of-a-feather/
さて,今回は,WebKitの話ですが,WebKitではAppleを中心にWebGPUというAPIが提案され現在開発が進んでいます.
WebGLはOpenGLをベースにしていましたが,WebGPUはMetal, Direct3D12, VulkanなどのAPIの設計をWebに持ってくるようなイメージですね.
AppleはWebGPUの実装をMetalベースで提案していましたが,他のOS環境に関してはDirect3D12やVulkanでの実装を行ってよいようでした.シェーダ言語に関しては,Metal Shadering Laungage(MSL)で提案していましたが,今回の記事を見ているとMSLはなくなったように思えます.
プロポーザル
https://webkit.org/wp-content/uploads/webgpu-api-proposal.html#shadinglanguage
今回の記事では,HLSLの構文を参考にしたWHLSLが説明されています.HLSLを参考にしているのはシェーダプログラマの人口が多いというところになりそうです(MSLやGLSLやSPIR-Vなど採用されなかったものについては記事に書いてあります).
ここで注意しないといけないのがWHLSLはHLSLと単語が共通ですが,HLSLの仕様がまるまる採用されておらず,言語仕様的には別な言語になっているようですね.Web High Level Shading Launguageということです.
ベクトル型や組み込み関数などは共通するようですが,HLSLでサポートする仕様とはいくつかの点が違いますがそれを挙げていきます(順不同.これが全部ではないです).
- Cスタイルの暗黙の型変換はサポートしない
- エラーの原因.Swiftなどと近いアプローチ
- enumのサポート
- 実行時のコストがかからず便利だから
- 構造体
- HLSLやCと一緒
- 継承,virtual,アクセス制御,privateはサポートしない
- プリプロセッサはサポートしない
- 理由：プリプロセッサでシェーダのバリエーションを増やす手法はHLSLでは使われるが保守性が悪い
- セーフポインタ
- 既存のCPUコードの移植しやすさを考えて
- 機械学習やComputer Vision,信号処理の人たちがコードをもっていきやすいように
- 既存のCPUコードの移植しやすさを考えて
- 配列の参照
- プロパティ
- プリプロセッサの未サポート
- HLSLでは1つのシェーダコードのバリエーションを増やすために使われるが保守性の悪さ
- シェーダ読み出しの仕組みが違うのではサポートしない
- 代わりにSPIR-Vのspecialization constantsにあたるものがある
- セマンティクスのサポート
- シェーダステージ間をやりとりするためにHLSLと同じくある
- ただし,グローバル変数ではなく関数のパラメータ入力と出力の形式になる
- シェーダステージ間をやりとりするためにHLSLと同じくある
だいぶ作業が進んでるなという印象ではありますが,ブラウザ上での実装はセキュリティの問題など配慮すべきことが多いためまだまだ時間がかかりそうではありますが,WebGLよりもよりパフォーマンスを引き出せるものというのを期待したいところですね.