ARM GPUセミナー中級編

kinneko @kinneko

#armjp 処理はパイプラインになっている。CPUとGPUもパイプライン的に動いている。CPUではコマンド発行、3Dのシーンの前処理。

kinneko @kinneko

#armjp 初期化からの動作イメージ。フレームバッファの初期化(カラー、デプス、ステンシル。毎フレームごとにやっている。初期化したことにするという省略する手も。)。ステートのレジスタ設定。アプリで頂点データとテクスチャデータ。

koba @tetsu_koba

#armjp を見てる。GPUのこともいつか勉強しないとなー。

kinneko @kinneko

#armjp GPUで頂点読み出し。座標変換とライティングの計算。トライアングルセットアップ、ラスタライザ、フラグメントシェーダー。ここで、テクスチャデータのキャッシュのミスヒットが致命的。テクスチャ以外でも作ったシェーダーもビルド。オフラインコンパイルでサイクル数がわかる。

kinneko @kinneko

#armjp シェーダーでは複雑な処理を書き過ぎない。ボトルネックになる。

kinneko @kinneko

#armjp CPUとGPUが離れていて、それぞれにメモリがある場合。メーカーから問い合わせある例。メモリバスが遅くなりボトルネックになる。工夫すれば性能改善ができる。頂点とテクスチャをGPUメモリに置いてしまう。

kinneko @kinneko

#armjp 次にフラグメント処理-ブレンディング。Read Mod Wirteで重い。バッファにキャッシュしても意味はない。再利用はあまりない。メモリ帯域を圧迫する。必要最低限に。

kinneko @kinneko

#armjp 最終画面の生成。FBに絵を描く。マルチバッファでも、GPUは１フレームの絵を書き出すだけ。

kinneko @kinneko

#armjp 性能向上のために。

kinneko @kinneko

#armjp ボトルネックの発見。CPU?GPU?ネックはどこ？ サイクルに遅れるのはどこか？ CPU処理がボトルネックの場合もあり。CPUはディレイ入れる。GPUでシェーダーコアの数を減らす、解像度変える、GPU処理を簡単化。メモリ帯域を絞ってみる。

kinneko @kinneko

#armjp GPUネックだった場合は、どのブロックか？ 頂点処理；光源、頂点、VBO使う。ラスタライズ：解像度小さく。テクスチャ：テクスチャの解像度を小さく。フラグメント処理：半透明処理をやめる、シェーダープログラムを簡素化。

kinneko @kinneko

#armjp メモリ帯域。テクスチャ圧縮、MIPMAP。RMWを減らす。メモリ帯域のおおまかな計算は、アプリ依存でなんとも。ざっくり、頂点データ＋テクスチャデータ＋フレームバッファ＋コマンド(影響小さい)。フレームバッファは、縦x横xFPSx複雑度=Mpix/s->MB/s変換。

kinneko @kinneko

#armjp バス・インターコネクト。(ちゃんとあとでやるのね) 多段的なインターコネクトになっているので、一箇所で問題があるとGPUは遅れる。優先度制御が必要。GPUは1fps内に描画が終わればよい。ちびちびでもつながればいい。CPUはレイテンシに敏感で性能がかわる。

kinneko @kinneko

#armjp しかし、単純な優先度制御では最適化が難しくなっている。マスタの特異性を生かした優先度制御がARMのバスではできますよ〜

kinneko @kinneko

#armjp 最適化にはツールを活用。GPUのパフォーマンスカウンタを見られる。Streamlineというツール。CPUも見られる。いまはできないが、インターコネクトの情報も出せるようになる予定。APIのトレースもできる。ハード屋が期待する粒度は出ないが、ソフトでネックを見る。

kinneko @kinneko

#armjp GPUの選択時には、性能も重要だが、デバッグソリューションにどのようなものがあるのかが半分くらいは重要。

kinneko @kinneko

#armjp GPUについては、ここでおわり。質疑。

kinneko @kinneko

@tetsu_koba すいません。気合入ってないので、読んでてもわかんないかも…

kinneko @kinneko

#armjp GPGPU。

kinneko @kinneko

#armjp フローティングが得意で、並列化できる。イメージプロセッシングからGPUで処理しようという動き。GPUを一般的な用途で使う。いろいろなプラットホームがある。OpenCL, RenderScript(Google)、MSも。ARMはOpenCLに力を入れている。

kinneko @kinneko

#armjp OpenCL。並列コンピューティングのためのフレームワーク。冗長でプログラムがめんどくさい。汎用性を意識している。CUDAを使うと、GPUの選択肢が限られる。OpenCLは、ローレベルのAPI。プログラマが投げる相手を制御する必要ある。

kinneko @kinneko

#armjp この上にミドルウエアとしてHSAなどが乗っていくる。

kinneko @kinneko

#armjp 文法はC言語。コンパイルが必要。基本はシェーダーと同じで、オンラインコンパイルとオフ来院コンパイルになる。OpenCL的にはターゲットはGPUと限らない。ヘテロジニアスな環境でも実行できる。

kinneko @kinneko

#armjp OpenCLのプラットホームモデル。ホスト(CPUとは限らない)でアプリが動く。各コンピュートデバイスにタスクを投げる。アプリで投げ先を指定する。自動割り振りではない。シェーダープログラム相当はOpenCL kernelと呼ばれる。(ややこしい)

kinneko @kinneko

#armjp ホストは、各デバイスのキューに投げていく。前後関係のバリア命令も使える。