MiniGPU: GLES3の仕様を眺める会
okuokuその辺から買ってきたDSPをGPUにできないか問題がある。いやまぁ効率を無視すればできるんだけど限度ってもんがあるので。。
一旦ふつうのGPUシェーダーでエミュレーターを書いて実用性を検討したい。
WebGPU Compatibility Mode
ターゲットとしてはWebGPUのCompatibility Modeを目指したい。要はOpenGL ES3.1くらいの仕様ということになる。
okuokuGLES2(WebGL1) はARB Assemblyで大体十分
前のQiitaの記事では否定的に書いたけど、逆に言えばVertex Texture Fetchとか OES_standard_derivatives のようなSpecial Functionが実装できれば特に問題無いんではないか説。
okuokuGLES3(WebGL2)は整数の導入がでかい
... Copilotはかなり嘘入ってるな。。
↑ 全体的に間違っている(ESSLとGLESを混同している)。
GLES2では、抽象化された内部精度の浮動小数点、つまり float 演算のみがサポートされていた。更に追加の型として float のvectorと boolがあった。
GLES3では、32bit(Highp時)の整数型が追加され、テクスチャサンプラ等も用意された。
また、WebGL1と比べた場合、 制御フローが自由になった 点も大きい。逆方向の分岐が可能になったため、ARB Assemblyのような分岐命令無しのデザインは取れなくなった。
okuokuCompute
WebGPUの出現によって放棄されたWebGL2-Compute提案がある。これも取り込みたいが結構内容が難しい。
Compute Shader
仕様の説明(17章)は8段落しかない。。
要はラスタライザとかを駆動しない、 "生" のプロセッサ機能を使用できるものとして用意されている。が、テクスチャのフェッチやストアは依然可能となっている。
Indirect Draw
これ描画機能だと思うんだけど、まぁそもそもGPUでbufferを生成するところにComputeの存在意義があるので。。というわけで、WebGL2 Computeにも drawElementsIndirect 等が提案されている。
メモリ上の構造体で各種パラメタを供給するが、 drawElements 等と異なりいわゆるclient sideに構造体を置けないという特徴がある。WebGLではそもそもclient sideのバッファでGPUを駆動する方法が無いため大きな違いではないが。。
シェーダー自体の機能拡張
なかなか難しいのが揃っている
local size, group size, group ID, invocation ID and so on for compute shader
image
shared memory
barriers
shader storage buffer
atomics
multisample texture
new qualifier like coherent, volatile, restrict, readonly, writeonly, std430, early_fragment_test, etc
new math built-ins
array of arrays
texture gather