生成されたSPIR-Vコードを最適化する必要がありますか？

Question

私はOpenGL/GLSLからVulkan/SPIR-Vまでのコードを移植することを検討していますが、そのコードの一部は実行時にGLSLを生成するので、代わりにSPIR-Vを生成する必要があります。私が疑問に思っているのは、生成されたSPIR-Vの最適化にどのように関連付けるべきかということです。

特に、ドライバーのコンパイラーにどのような期待を払うべきかに関する情報を見つけることができません。私はそれが積極的な最適化を単独で行うことを期待し、それでSPIR-Vコードをきれいに保ち、できるだけ多くの「オリジナルの意図」をコンパイラが見るように保つことを試みるべきですか？あるいは、私はそれがかなり単純なコード生成を行うと期待し、SPIR-Vを生成するときに可能な限り積極的な最適化を行うことを試みるべきですか？

SPIR-Vを生成するときに、これらの種類のうちのどれを実行すればよいでしょうか？

ローカル変数の重複したストアを削除しますか？

ループアンローリングまたはピーリング/関数インライン化？

定数伝搬/共通部分式消去？

ローカル変数へのロードとストアではなく、SSA形式で可能な限り保存しますか？

コンパイラは最適化パスをハードウェアの仕様に合わせたいと思っています。そのため、私のSPIR-Vコードをきれいで高レベルに保つようにしてください。ループアンローリングは情報を破壊し、ドライバが自分自身のアンローリングを決断するのを防ぎますが、実際の情報なしでは私は本当に推測しています。

Answer 1

一般に、（ドライバの中で、SPIR-Vを消費する）ランタイムコンパイラは、多くの標準的な最適化を行うと期待できます。多くの実装では、GLドライバのバックエンドと同じバックエンドであり、ほとんど同じ最適化を行います。しかし、SPIR-Vを解析し、それをドライバーの内部表現に変換するプロセスは、そこに不必要な迷惑がたくさんない場合にはより高速になります。したがって、独自のジェネレータを作成している場合は、「クリーンな」SPIR-Vを生成するために多少の努力をする価値があります。

shadercは、GLSLからSPIR-Vへの変換にglslangを使用し、最適化を実行するためにspirv-optを実行することができる、統合が容易なライブラリを対象としています。あなたは名前をつけた。 spirv-optは（アクティブな開発の下で）追加の​​最適化を取得するので、shadercはそれらを選択します。