cusp

何度かダウンロードに挑戦しているが、未だEclipseがマーケットに繋がらない。
SpMVのコードもcusp以外に生きているプロジェクトはなさそうで、
cuspの結構長いコードをcuda-gdbで追うとすると結構骨が折れそうな作業であるため、
どうにかならないものか考えている途中です。

Eclipseのプラグイン導入がうまくいかない

AMDのOpenCLソフトウェア環境が不完全であるため、
TSUBAME上でCUDAを用いた実験で代替する予定なのだが、
CUDAコードをLinux環境上で楽に行う環境構築を行いたい。

そこで、Fixstars社が開発し、オープンソースで公開している
Eclipse用のCUDAプラグインを用いることを画策していた。
しかしながら、Eclipse Marketから当該のプラグインを落とそうとしても、
そもそもマーケット自体に接続できない。

何が起きているのかよくわからないので、一度Windows環境上で追試してみる予定だ。

AMD Radeon HD7970 & APP SDK v2.6

待望の新アーキテクチャのGPUが登場。
より汎用計算向きの構成が取られており、非常に楽しみ。
特にSM単位で命令発行でき、L1などの容量も大幅に改善されているのが気になる。
あとは性能とソフトウェア環境の整備次第なのか。
http://pc.watch.impress.co.jp/docs/column/kaigai/20111222_501138.html

APP SDK 2.6ではOpenCL 1.2の仕様の一部が利用可能になっており、
特にカーネルコードでC++98の一部が記述可能になったそうだ。
具体的には、ホストで作ったクラスをカーネルに転送し、
カーネル関数でアクセスするなどかなり自由度が上がっている。
また、カーネル関数のオーバーロードやテンプレートも作成できる。

そのほかの改善としては、APUでのAtomicカウンタの対応と、
非同期メモリコピーの実現が挙げられる。
もちろんRadeon HD79xx対応も行われている。
http://developer.amd.com/sdks/AMDAPPSDK/assets/AMD_APP_SDK_Release_Notes_Developer.pdf

ただし、未だにLinuxでのZero Copyには対応できていない。
現状、自分の研究にはOpenCL + AMD APUは利用できなさそうだ。

CUDA to OpenCL

AMDのページにもっと詳細な移植用のメモがあった。
しかし今後移植を行う可能性は低い。
http://developer.amd.com/zones/OpenCLZone/programming/pages/portingcudatoopencl.aspx

Tesla C1060でOpenCLを実行できるよう環境整備したが、
何かNVIDIA環境でもOpenCLだとメモリコピーなどが非常に遅い気がする。
面白いデータが取れそうなので、間に合えば論文にも載せる予定。

OpenCL C++ bindingでException

#define __CL_ENABLE_EXCEPTIONS

これがないとコンパイラにぐだぐだ言われます。注意！

こんな感じのよくわからないエラーが出て凹みます。
mem.cpp:40: error: expected type-specifier
mem.cpp:40: error: expected unqualified-id before ‘status’
mem.cpp:40: error: expected ‘)’ before ‘status’
mem.cpp:40: error: expected ‘{’ before ‘status’
mem.cpp:40: error: expected ‘;’ before ‘)’ token

キャッシュミス測定

いいコマンドを知った

% valgrind --tool=cachegrind ./test

さよならMars

Marsから離れることができた。よかった。

修士論文に向けて、ようやく全体の構成がまとまってきたので一安心だ。
新しいアプリケーションの実装は必要だが、研究室の他の学生も似た処理を実装しているのでどうにかなるのではないかと思っている。

Marsの移植が終わらない

Mars自体の処理の流れは掴めており、後はOpenCLとCUDAで差異がある部分だけを書き直せばいいのだが、
どのようなやり方で書き直すのが最適な手法なのか判断が付かず、そのたびに作業が迷走してしまう。

OpenCLではコンテキストやキュー、カーネルなどのオブジェクトを明示的に作成し、
メモリの転送やカーネルの実行時にそれらを指定してやる必要がある。

CUDAではこうした要素がプログラム実行時に暗に設定されるため、
ユーザはこれらを意識することなくプログラムを書いて実行することができる。

現在のMarsの実装だと、OpenCLではこうしたオブジェクトを利用する場面が
ソース内で関数を跨いで不規則に離散して存在しており、移植が非常に大変になっている。
特に関数呼出部分が辛く、OpenCLではカーネル関数ごとにクラスやオブジェクトを作って保持する必要があるため、
Marsで使われる多くのカーネル関数をどうにかしなければならない。

今までは何とかグローバル変数を使わずに済ませる方法を考えていたが、
このままではどうしようもなさそうなのでグローバル変数でオブジェクトを宣言するしかないのだろうか。

C++を使いだしてOpenCL関連のコードはかなり綺麗になったのだが、
またごちゃごちゃしてきそうで憂鬱だ。

OpenCL C++ bindingで複数の.clファイルを扱う

C++を使い慣れている人には常識的なことなのかもしれないが、
OpenCLをC++で使うときにやり方が見つからなかったのでメモ。

OpenCLをC++から叩くとソースが非常に短くなって生産性、可読性がかなり高まり便利。
しかしながら、使用者が少ないので情報があまりなく、その点では面倒。

標題の件だが、C++からは以下のようにしてソースをコンパイルする。
（srcに.clファイルのソースが含まれているとする。）
cl::Program::Sources source(1, std::make_pair(src, strlen(src) ));
cl::Program program_ = cl::Program(context, source);
program_.build(devices);

単一のソースのみをコンパイルする場合はこれでいいのだが、
複数のソースを扱う場合の情報は検索しても見つけられず、四苦八苦した。
しかし、あるサイトで先にsourceを宣言し、コンストラクタを使わずにpush_backを使うものを発見。
cl::Program::Sources source(1, std::make_pair(src, strlen(src) ));
↓
cl::Program::Sources source;
source.push_back(std::make_pair(src, strlen(src));

これと同じように、複数のファイルをpush_backしてやればそのままコンパイルが通る。