フォト

Google AdSense


  • AdSense
無料ブログはココログ

« 今年は・・・ | トップページ | ノルマ »

2004.06.21

GPUの汎用SIMDプロセッサへの道

現状のGPUが3DCGを研究領域にしない人たちから扱いにくいと思われる理由がおそらくあくまでもそこへのアクセスが3D APIを経由した使い方になっていることであると考えられます。

こうした問題というのを解決に導ける可能性の一つが個人的にはOpenGL 2.0などで言われてるスーパーバッファ(DirectXでも同様の仕組みは用意されるとは思いますが、名称は不明)の存在のような気がします。

たとえば、現在のテクスチャというのはあくまでも画像的なフォーマットですから幅とか高さという部分でGPU上のドライバの制約がありますが、例えば(実際に私はスーパーバッファの仕様なんて読んでないので想像で書きますが)、例えば、16bit要素の適当なバッファを用意してあげるとお16bitの音声データなどをお互いロックしてそのまま送っちゃうなんてことができますね。

これがテクスチャならもともとの解像度のしがらみがあるんでそのあたり(例えば、256×256の場合に音声のバッファが必ずしも256の長さとは限らないしね)で調整が必要ですが音声のバッファのような1次元のデータなんかが送りやすくなりますね。

それとテクスチャという概念を捨てればピクセルシェーダにバッファを送る際の用法を3D 的なAPIに縛られることも無いように思います。

あと、出力結果をテクスチャにレンダリングするということも3DCGを専門としない開発者からするとクセがありますね。

そう考えると3Dプログラマ以外のプログラマに扱いやすいラッパーライブラリや上位シェーダ言語やそのためのAPIの設計は意義があるのかもしませんが、私がやってもスタンダードにはならないでしょうねぇ。なんだかんだハードウェアメーカーでないなかなかこういう点でデファクトは取れないし、ドライバ最適化が出来ませんね。

« 今年は・・・ | トップページ | ノルマ »

Programming」カテゴリの記事

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/2210/813460

この記事へのトラックバック一覧です: GPUの汎用SIMDプロセッサへの道:

« 今年は・・・ | トップページ | ノルマ »