t_wの輪郭

goから越境してrustやるの嫌じゃな～～～。

そもそも、wgpuのレポジトリ見てても動かし方がよくわからん。

なんとなくIssueをcompute shaderで検索して眺めてみる。すでにIssueが出てれば幸甚。

なかったわ。一般的には巨大シェーダーを動かす動機がないらしい。

wgpuのレポジトリにExampleを発見したので動かしてみる。

wgpuでboidsが動いた。やったねたえちゃん！

巨大シェーダー実証の元としてhello-computeが良さそう。コードが簡単。見覚えもある。

サクッとシェーダーを書き換えてみたら動いた。いいぞ。

条件分岐が1万行の巨大シェーダーを試してみた結果、wgpuにおいてはそんなに時間がかからない。500msとかそんなもん。じゃあRustでwgpu使って遺伝的プログラミングすればええやんという判断が浮かび上がってくるが、Rust難しすぎてあれなのであれ。覚悟を決めるのに1週間ぐらいかかるやつ。

とはいえ現状は wgpu → wgpu-native → go-webgpu という依存をしており、wgpuを直接ぶったたくよりも隔靴搔痒となる。依存しているコードがどこでどう変わるかもわからない。wgpuはブラウザでも使われているらしいので、多分大丈夫だろう。

本丸の遺伝的プログラミングのコードは2000行程度なので、1週間もあれば行ける気がする。Rustを理解できれば。

その前にgo-webgpuをアップデートすべく、go get -uを叩く。よし、最新版でも直ってない。wgpuに乗り換えだ。

遺伝的プログラミングのコード全部を書き換えるのは骨が折れる。泣く。なので、wgpuを叩く部分だけRustで書けばええんちゃうんかという判断が生えてくる。『wgpu-go』や。

念のためにgoでもrustで動かしたのとまったく同じシェーダーを実行してみる。いや、普通に動く。先生……！これは……！条件分岐の数がCreateComputePipelineの処理時間に影響していると思われていたが、実はそうではなかった可能性が高い。Rustのwgpuで行った検証も不十分だった可能性が高い。

配列アクセスが悪いのではないかと思い至り、配列利用型巨大WGSLシェーダーを動かしてみたが普通に動く。機序がわからん。キショい。

関数実行が悪いのではないかと思い至り、配列及関数利用型巨大WGSLシェーダーを動かしてみたが普通に動く。静的だと最適化してないかこいつ。

関数がインライン展開されている気がしてきた。多分。わからんけど。そう考えると、関数の再起呼び出しができないのも、配列の添え字に変数が使えないのもしっくりくる。

「気晴らしにcompute.toysとか言うので遊んでみるかぁ」つって、何気なく配列の添え字に変数を入れてみたところ、なんと動いた。はぁ？じゃあっつって、最新版のgo-webgpuだとどうなんのよって試したら配列の添え字に変数を入れても動く。CreatePipelineも300ms以内に終わる。はぁ？？？今までの苦労は何だったんだ。3日返してほしい。

なお、最新版が出てきたのは5 days agoである。タイムリー。

cargo run --bin boidsを実行

WGSLのコード内の条件分岐の数が2倍になると、compute pipelineの作成にかかる時間が10倍になった現象は、Macにおいてのみ低速な可能性がある。
MTLCompilerServiceがCPU100%に張り付いている。
WGSL → SRIP−V → Metal Shading Languageと変換される部分の、SRIP−V → Metal Shading Language が時間を取っている、ような気がする。

Windowsでも再現することが確認できた。
200個の条件分岐があるとpipelineの作成が200秒程度かかる。

WGPUの中に以下のコードがあり、このCodeとしてSPIR-Vのコードを渡せば、動かせる予感がする。

type ShaderModuleSPIRVDescriptor struct {
	Code []byte
}

が、『Possibility of SPIR-V and/or GLSL as a WebGPU extension?』とかを読んでる感じでは、WGSLに変換してるだけな気がする。