日曜研究室 LLVMによるプログラミング言語の実装 xv6ソースコードリーディング 技術 日記
日曜研究室

日曜研究室

まだ庭の小石の数を数え終わっていない

技術

CUDAにおけるテクスチャリファレンスとテクスチャオブジェクトの違い

投稿日
2013/5/25 土曜日
カテゴリー
技術
タグ
著者
Take it easy!

どちらもGPUのテクスチャフェッチ機能を利用してデータにアクセスするためのもので、概念的には同じものと言える。
しかし詳細に踏み込むとかなり違いがある。
（以下はDriver APIの利用を想定したものだけど、Runtime APIでも大部分はそのまま当てはまると思う。）

使える環境

テクスチャリファレンス（以降TR）は、CUDAが使えるなら必ず使える。
テクスチャオブジェクト（以降TO）は、Compute capability（以降CC）3.0以上に対応したデバイスでしか使えない。

使い方

生成方法

TRは、カーネルモジュールにTR型のグローバル変数を宣言することによって暗黙的に生成される。（つまりコンパイル時に生成される。）
なので、ホストコード側で生成するのではなく、TRの変数名をAPIで指定して参照を得る。
TOは、ホストコード側でAPIを使って明示的に生成する。（つまり実行時に生成される。）

設定方法（例えばCLAMPにするかWARPにするか等）

TRの場合。APIを使う。ただし、設定項目ごとに関数が別。
TOの場合。こちらもAPIを使う。ただし、設定項目をまとめた構造体を生成時に渡す。
なのでAPIの数はTOの方が圧倒的に少なくてスッキリしている。
ただしTOの方は、設定項目を生成時に渡すため、途中で変更することが出来ない。

データの受け渡し方法

どちらもバックエンド（テクスチャデータ）として線形メモリやCUDA Arrayを利用するので、それらに対して普通にcuMemcpy系で読み書きすればいい。

カーネルへの渡し方

TRの場合は、カーネル側に実体があるので引き渡しは必要ない。（ホストコードからTRの参照を取得してそれに対して操作していく感じ。）
TOの場合は、普通の線形メモリをカーネルの引数に引き渡すのと同じやり方で引き渡す。

制限

オフィシャルのCUDA C Programming Guideでは、TRよりTOの方が基本的に制限がゆるいとされている。
しかし制限がどういった種類のものか、制限にどう違いがあるのかは明記されていない。
設定可能な項目に違いは無さそうだから、取り回しが楽とか解像度の上限とかそっち方面かな？

速度

オフィシャルの情報では、8GPU以上の場合、TOを使うことでかなりパフォーマンスが上がるらしい。

まとめ

デバイスメモリもテクスチャメモリも概念上は似たようなものなのに、実際の線形メモリとTRの宣言の仕方・使い方はかなり差があり、最初TRを見たときは分かりづらい・めんどくさいと思った記憶がある。
今では慣れたのでTRでも特に問題はないが、TOを使えばその分かりづらさ・めんどくささもかなり解消されると思う。
またTOならAPIの数も少ないので覚えやすい。
設定用の構造体に関する知識は新たに必要にはなるが、構造体にまとまってれば調べ易いし、設定情報の取り回しも楽だし、関数がバラバラに分かれてるよりははるかにマシだろう。

問題はTOがCC3.0以上じゃないと使えない事だが、CC3.0以上というとKepler以降で、Geforceでいうと確実なのはGTX 650以上という事になる。
GT 640近辺はKeplerベースとFermiベースのものがあるので注意が必要。
GT 610-620辺りは多分Fermiベースのみ。
FermiベースのものはCC3.0には対応していない。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です



※画像をクリックして別の画像を表示

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。