BroadcomのOpenGL ESスタックとGPUレジスタ仕様が公開された
- prev: http://d.hatena.ne.jp/mjt/20130707/p2
- モバイルGPUの解析状況
RaspberryPiに搭載されているVideoCore IV用のOpenGL ESスタックがBroadcomによってBSDLで公開された。
これは直接現状のRPiでは使用できないが、RPi財団は移植に対して1万ドルの懸賞を提供している。
... つまり、これはRPiで動作しているコードを完全に再現するものでない。BroadcomはVideoCore DSP用のツールチェイン等は依然提供していないため、DSPで動作している現状のGLスタックを生成することはできない。なので、懸賞はARM11への移植(と、いくつかのstubライブラリの作成)に対して出ることになるだろう。
ハードウェア
ハードウェアはあまり特殊な内容では無い。普通のTBR(Tile based rendering)であり、early-Zのような普通のテクニックが適用されている。
Broadcomは既存のGPUを持っていないので、ベンダ固有の圧縮テクスチャなどのサポートも無い(他のGPUにおいては、IMGならPVRTC等、GPUベンダ固有のテクスチャ圧縮が大抵は有る)。
頂点キャッシュメモリは12.4固定小数点データを消費するなどかなり突っ込んだ内容にも触れられている。というのも、GPUは頂点シェーディングをバイパスして直接レンダリングするモードをサポートしている。
レンダリングは2pass - binning(頂点データのタイルへのアサイン)とrendering(実際の描画処理)の2つに分かれている。binningされたデータは一旦メモリに戻され、そのリストを更にrenderingステージに渡す形になっている。 もったいないように見えるが、例えばPowerVRも同様の方式(タイルに割り当てられるプリミティブのパラメタをチップ外のストレージに持つ)を取っている。
いわゆる統合シェーダアーキテクチャを取り、QPUと呼ばれるプロセサで両方の仕事を行う。QPUはVideoCoreに搭載されているDSPとはまた別のプロセサであり、RTOSを動作させているDSPと異なり大きなファームウェアは動作していないように見受けられる。頂点シェーダはbinningの前に動作させる必要があり、フラグメントシェーダはbinningの後に動作させることになるので、動作はオーバーラップしない。ここを並列化できるかどうかはドキュメントからはあまり明らかでない。
ソフトウェア - ESSLフロントエンド
OpenGL ES2実装が興味深いのは、ESSLの言語処理系を含むことだろう。既にいくつかオープンソースのESSL処理系が存在するが、Broadcomの実装はポータブルで、.cで書かれているという微妙な特徴がある。
既存のものを含めて並べると:
- Angle
- https://chromium.googlesource.com/angle/angle/+/master/src/compiler/
- Googleなどによる。Google ChromeでのGLES2実装に使用され、HLSLへのトランスレータやGLSLへのトランスレータが有る。
- Mesa
- https://github.com/aras-p/glsl-optimizer/tree/master/src/glsl
- 主にIntelによる。リポジトリはUnityのGLSLオプティマイザのもの。本家はMesa。
- Broadcom
- https://github.com/shacharr/videocoreiv-qpu-driver/tree/master/brcm_usrlib/dag/vmcsx/middleware/khronos/glsl
- 今回公開されたもの。他のものと異なりPlain-Cで書かれている。IRが無く、AST書き換えで動作する。
もちろん、ソースコードを観察することも興味深いが、Broadcomはオフラインコンパイラを提供していないので、実用的価値もある。ESSLシェーダを書いても、いちいち実機に転送せずに実機同様のフロントエンドで検証できるようになる可能性がある。
本来のBroadcom実装では、この規模のコードがDSP側で動いているわけで、CPUが何のために存在するのかという非常に哲学的な疑問が生じる。
