DirectX10世代のGPUが登場 - matsui899の日記

G80シリーズのアーキテクチャ、ベンチマーク、それと消費電力が公開された。
後藤弘茂のWeekly海外ニュース
 PINUPS - 上田新聞 blog版あちこちの記事のリンク
ダイサイズは500平方mmで90nmプロセスであるにしても非常に大きい。シェーダー、その他もユニット化されているので、不具合のユニットを使わない形でローエンド(GTX→GTS)に回していけば、これまでと同じ値段で採算が採れるのかもしれない。消費電力は、まぁ思っていたとおりだ。

メモリ帯域は256-bit+128-bitなどと意味深なのことが噂されていたのでデータと命令を分離したのかとおもったのだけど、64bitのユニットが均一に6個ある。768MBもメモリが乗っていて、プログラムに使って下さいと言わんばかりだ。

アーキテクチャは変わっていて、シェーダー側にL1$を持ち、その他演算器側にL2が存在する。L1, L2というよりはそれぞれの機能で使い分けているのだろう。シェーダーを利用する128個以上のスレッドをL2$に溜め込んでおくのだろうか？そのため、L1, L2と名前がついているのかもしれない。

それと128個のシェーダーが、加算と乗算のパイプラインを持つスカラ型の演算器らしい。SIMDの方がトランジスタあたりの演算力を上げられるけど、レジスタやキャッシュ(その上プログラムも)が大きくなるのを避けたのだろうか。シェーダーを直接利用できるように内部をある程度公開するらしいので、ベクトル型とスカラ型ほどの違いは隠蔽できないし、互換性を持ってこれからも利用していかなければならなくなる。

多分、ATIはSIMDなので互換性が取れないのでGPUを利用する商用プログラムは作りにくい。MSは後追いでAPIに互換性を持たせてきたけど、これではさすがに互換性をもたせられない。どちらかが一般化すれば、もう片方はGPU製造から撤退するしかない。完全にGPUを支配するか死かの戦略に入ってしまった。

今回、プログラムしがいのあるGPUを登場させたことでGPUプログラムの研究が本格化するだろう。nVidiaが隠していたのも、先手をとることがとても重要なのを良く知っているからだろう。

追記

GPUの使用方法に標準ができず、停滞する可能性を指摘している。
http://rblog-tech.japan.cnet.com/0061/2006/11/amd_stream_proc_5fa0.html

うーん、いくらグラフィック以外の処理にするにしても、トランジスタの利用効率を考えるとスカラ型を利用する利点が見えない。ベクタ型の演算器にくらべて演算能力が半分程度に落ちているはずだ。これだと半分がスカラ型データ処理にならないと元が取れない。つまり、データ型に依存した演算効率の問題では説明がつかない。

やっぱり、データの粒度を下げられる利点だろうか。利点は分岐のペナルティを最小限に抑えられる事とロード完了までの時間を短縮できる事だろうか。後者は、Cellのような構造になっていれば隠蔽できるけど、G80では演算器を128個も載せられるあたり単純制御になっているはずだ。どんな風にデータをロードしているかによって影響が違うのでわからない。それ以上に前者の影響が強そうだ。

将来まで利用する命令セットとして考えているのであれば、CPUでベクトルプロセッサが減少した事がGPUでも起こるだろうと考えているのかもしれない。プログラム制御構造が複雑になってベクトルプロセッサで効率が低下してしまうのか。
http://grape.astron.s.u-tokyo.ac.jp/~makino/articles/future_sc/note004.html#rdocsect3

後藤さんの記事よると分岐のペナルティを減らすためのようだ。分岐制御機構を増やすくらいならスカラプロセッサでもよいかも。
http://pc.watch.impress.co.jp/docs/2006/1127/kaigai321.htm
それ以外に、以前はメモリアクセスのレイテンシを隠蔽するためにデータをまとめて処理したらしいが、その役割はスレッドに移っている。機能は単純化してデータに依存性を隠蔽できる程度で十分になっているのでないだろうか。レジスタと内部メモリという構造でもないらしいからレジスタへデータを供給するれレイテンシを隠蔽するひつようもなく、カスケードにする意味があるかもわからない。データの最小単位はどんどん下がっていきそう。
それにしても、仕事の管理に3つのまとまりを作っているあたりで管理が大変そうだ。プログラマからは見えなくする必要があるけど、グラフィックに使うならともかく他では自分で管理する必要がでるのだろうな。

更に追記

西川善司さんのDavid Kirk氏インタビュー記事がでている。
http://journal.mycom.co.jp/articles/2006/12/19/cuda/
16個のPUと一次キャッシュを単位として利用するらしい。Runtimeを利用することでGPUの差異を吸収するらしいが、どの程度吸収できるかやってみないとわからない。
単純に計算をPUに、プログラムの整合性を管理をThread Processorにやらせると、とんでもなく負荷がかかってしまう。スレッド内の構文はPUにやらせると思うのだけど詳細は不明。
SIMDでなく16PUを組んだことが疑問だけど、16PUで計算パイプラインを組んで利用するのかな。各PUに配給する命令を減らして固定できるし、データの最小単位を減らせるから１次キャッシュが小さくても何とかなる。PUに対して処理が少ない場合、逆に多い場合にどうしているのか気になる。たぶん、PUがあまった場合は使わない、一度外部に出力して再度続けるのが単純で良いだろう。演算能力あまってるし。この辺の思想がCellとは違いそう。

20070117追記

G80がスカラ型演算器であっても、16演算器ごとに同じ処理を同時に行ったらSIMD演算器とスレッド粒度が変わらないのでないかと考えていた。そこで、どうやったら効率よく計算できるか考えた。

16演算器でパイプライン処理するとスレッドの粒度を極端に小さく出来る。少ないデータに多くの処理が行えるので外部メモリとのやり取りの負担が少ない。でも、演算器に均等に仕事を割り振ることが難しい。また共有レジスタを持ち、同期をとる必要がでるので複雑になってしまう。それに演算器の個数がGPUのアーキに含まれることになり将来問題。この方法じゃない。

同じ処理16スレッドをまとめて16個の演算器で処理する。これならスレッド粒度を小さくして分岐ミスを減らせる。また各演算器に同じ命令を送り込めるので命令ロードの負担が少ない。16スレッドをまとめる処理、各演算器に分配する処理が含まれるので、特殊な命令形をもつ強力な管理機構が必要になる。スレッドをあわせるのでデータがロードされるタイミングがずれるので、一度集めてから演算器に入れるのだろう(レイテンシ数百クロック, 処理も同じ程度?)。同時に演算器に入れようとすると412bitで接続することになり、これ以上演算力をあげるのが大変そうだ。