2011年4月23日土曜日

4/22 Error Message

OpenCLのエラーは種類が多々あるが非常にわかりにくい。
数字とエラーの対応付けも面倒。

先人が残してくれたコードがあるので活用すべき。


今回遭遇したエラー:-55
コンパイルしたコードで実行してみると、
CL_INVALID_WORK_ITEM_SIZEというエラーらしい。
(利用したコード:http://opencl-percipere.blogspot.com/)

エラーの定義名さえわかれば、リファレンスからググれば一発。
(KhronosのPDF:http://www.khronos.org/registry/cl/specs/opencl-1.x-latest.pdf)

数字との対応関係を見たいならこのようなページも存在。
(http://blog.s21g.com/articles/1647)


こうしてエラーの詳細はわかったが、どういうエラーで何が原因なのかはまだ不明。
明日以降にどうにかする予定。

2011年4月22日金曜日

4/22 実験



レイテンシとスループットを測定
それぞれ順番に、
CL_MEM_ALLOC_HOST_PTR
CL_MEM_USE_HOST_PTR
CL_MEM_USE_PERSISTENT_MEM_AMD
でメモリオブジェクトを確保した場合の実行結果。
他の条件は全く同じ。

使い方が間違っている可能性もあるが、
CL_MEM_USE_PERSISTENT_MEM_AMDが微妙。

CL_MEM_ALLOC_HOST_PTRはZero Copyの恩恵なのか、
Map/Unmapが速く、いい感じだと思う。

ただ、全体的にCPUと比べて高レイテンシすぎて心配になる。

4/22 Zero Copy

*最近OpenCL関係で検索すると自分のページがよく出てきますが、
*このブログはあくまでもただの学生の作業メモ日記なので、
*勘違いや嘘が多々含まれているかもしれません ご注意を

*致命的なミスなどがあったらご一報をお願いします



・AMD APUでZero Copyを使うには
AMDの4月発表の最新のAMD APP OpenCLプログラミングガイドの4.4を見るとよいそうだ。


・OpenCLのメモリオブジェクト
5種類に分けられるようだ。
1.Host Memory
2.Pinned Host Memory
3.Device-Visible Host Memory
4.Device Memory
5.Host-Visible Device Memory

詳細はAMDのガイドを参照すべきだが、簡単にまとめると、
Host/Device Memoryは名を冠するデバイス以外は直接参照不可能で、
一度Pinned Memory領域かホストのBufferにコピーしないと参照できない。

Pinned Host Memoryは物理メモリと直接対応付けされているので、
デバイスとのDMA通信が可能。領域サイズにより挙動は多少異なる。

Device-Visible Host MemoryはCPUのキャッシュを無効にした領域。
デバイスからのアクセスは早いが、CPUからのアクセス速度は低下。

Device Memoryはデバイス側のメモリ。アクセスはHostメモリの逆。
要はCUDAのGlobal Memory。
APUではDevice-Visible Host Memoryをこれとして扱うらしい。

Host-Visible Device MemoryはGlobal Memoryの一部で割り当て可能。
CPUからはPCIeを通したキャッシュ不可能なメモリ領域としてアクセス。速度は遅い。


・メモリオブジェクトの確保・アクセス
clCreateBufferで確保、clEnqueueReadBuffer / clEnqueueWriteBufferでアクセス。
clCreateImageなんてやつもあるらしい。

確保したオブジェクトを実際に配置するにはMappingを行う。
これはclEnqueueMapBufferで行う。
消す前にはclEnqueueUnmapMemObjectが必要で、clReleaseMemObjectで消し去れる。

オブジェクトの確保の際に、定数を引き渡すことでオブジェクトの性質?を決める。
これも色々あって複雑。WindowsかLinuxかでも動作が変わる。
1.Default(no flags)
2.CL_MEM_ALLOC_HOST_PTR
3.CL_MEM_USE_HOST_PTR
4.CL_MEM_USE_PERSISTENT_MEM_AMD

OpenCLプログラムの実行元がGPUか、APUのGPUか、CPUかで配置が変わるが、
CPUの場合は今回は無視。Windows以外の場合も無視。

デフォルトだとAPUではDevice-Visible Host Memory、
GPUではHostかDeviceのメモリを文脈に応じて選択。

CL_MEM_ALLOC_HOST_PTRではPinned Host MemoryでZero Copy。

CL_MEM_USE_HOST_PTRではデフォルトと同様になり、Copyされる。

CL_MEM_USE_PERSISTENT_MEM_AMDとCL_MEM_ALLOC_HOST_PTRの挙動の違いが謎だが、
Map Locationの説明が異なっている。
前者では異なるメモリエリアの割り当てがなされるが、
後者ではそれぞれのメモリマップに同一のメモリエリアが割り当てられるらしい。
どういった差異が発生するかはわからない。。。
4.4.3.1に書かれているようだがよくわからなかった。
どちらもWindows Vista/7環境ならZero Copyは可能なようだ。


・速度計測
clEnqueue系の命令にはイベント情報の格納先を指定することができるので、
そのイベント情報をclWaitForEventに引き渡せば実行を待つことが可能。
この時間を計測すれば各イベントの実行時間がわかる。便利。
使ったイベント情報はclReleaseEventで開放してあげよう。


・リモートデスクトップ
VNCなら大丈夫らしい。NVIDIA GPUでも同様の事例はあるらしく、
Windowsのリモートデスクトップの実装に起因しているらしい。MS頑張れ。

2011年4月21日木曜日

4/21 リモートデスクトップの功罪

測定結果が意味不明だったので色々調べてみると、
リモートデスクトップ利用時にはGPUがうまく利用できないらしい。

あと、SDK 2.4にはCatalyst 11.4が必要らしい。
これも正しくインストールされていなかった。愚かだ。

両方直して測定してみると、非常に空しい結果だった。
前回の異常な結果はさすがにブログから削除した。
正しい結果についての考察と対処が必要だが、
今日は完全に心が折れてしまったので明日頑張る。



デバイスの確認に使ったソースはこちら。
[参考文献] Percipereさん, clGetDeviceInfo でデバイス固有情報の取得
[URL] http://opencl-percipere.blogspot.com/2009/09/clgetdeviceinfo.html

これはGPU非依存なので、一度コンパイルしておくとすぐにチェックできて便利。

4/21 APUとGPU

ある程度OpenCLにも慣れてきたので、今度はGPUとの比較を行うための環境構築に手を出す。
シームレスにAPUとGPUを切り替えて実行できればよいのだが、
現状ハードウェア構成やBIOSの設定まで変更しないとうまく動かすことができなかった。

[APU実行時]
GPUは物理的に取り外す
BIOSでIGPXをAuto or Force(共有メモリ量も手動設定)
M/B側にDisplayを接続

[GPU実行時]
GPUは物理的に接続する
BIOSでIGPXをOFF
GPU側にDisplayを接続

ドライバ関連はCatalystが自動で設定してくれるようだが、
今の状態だと手元にマシンがないと構成変更ができない。

何かいい方法はないのだろうか。



実験の自動化のためにバッチファイルを覚えた。
・変数の設定
set VAL_NAME=VALUE

・変数の参照
echo %VAL_NAME%
(VALUEが表示される)

・リダイレクトによるファイル書き込み
SOME_EXEC >> FILE
(FILEに表示内容が格納される)

・日付、時間を表示
echo %date%
echo %time%

Linuxのシェルと似た部分もあるが違いもあるので注意が必要だ。
また、Windows同士でもバージョンが違うと微妙に差異がある模様。

2011年4月19日火曜日

4/19 OpenCL雑感

CUDAと比べるとやはり面倒。
これはマルチデバイスへの対応と動的コンパイルのため仕方がないのだろう。

CUDAだと、
1.デバイスのメモリ確保
2.デバイスへのメモリ転送
3.デバイス関数の実行
4.デバイスからのメモリ転送
で済むのだが、

OpenCLだと、
1.デバイスの情報取得
2.デバイスコンテキストなどの設定
3.デバイス関数のコンパイル(もしくはロード)
4.デバイスのメモリ確保と転送
5.デバイス関数のキューの確保とエンキュー(実行)
6.デバイスからのメモリ転送
となり非常に面倒。

文章だけではわからないだろうが、コンテキストやIDあたりが非常に煩雑だ。
メモリの確保と転送も、CUDAと比べると記述が多い。
デバッグが大変だった。


慣れの問題もあると思うが、早く使いこなせるようになりたい。
このままだとマイクロベンチを書くのも危うい。


Visual StudioはI君、U君や隣の研究室のS君の助けもあり何とか使えるようになった。
次はOpenCLとCALをどうにかしなければ。

4/19

「OpenCL入門」という秀和システムの本を読み、サンプルプログラムを書いて学習している。


OpenCL自体は本を読めばある程度はわかるが、Visual Studioまわりで色々苦戦中。

・ソリューションの追加
Visual Studio 2010ではプロジェクトを作成するときにソリューションを選ぶか
追加できるので、ソリューションの追加みたいなメニューがないようだ。

・ソリューション内での構成のプラットフォームの選択
64bit用のデバイスドライバが入っているのでx64でコンパイルしたいのだが、
複数のプロジェクトで同じプラットフォーム(x64)を追加したい場合は
「新規作成」したときに「新しいソリューションプラットフォームを作成する」の
チェックボックスをはずさないとエラーが出る。

・実行結果のDOS窓(コマンドプロンプト)がすぐ閉じて悲しいことに
Ctrl+F5でコンパイル+実行すれば結果の窓が残る

など、VSを使い慣れている人からすると衝撃的なのかもしれない内容で戸惑ってしまった。


Visual Studio 2010でのOpenCLのコンパイル自体は、
1.ソリューションプラットフォームをx64にし、
2.VC++ディレクトリのインクルードディレクトリに「C:\Program Files (x86)\AMD APP\include」を追加、
3.同所のライブラリディレクトリに「C:\Program Files (x86)\AMD APP\lib\x86_64」を追加、
4.「リンカ」の「入力」の「追加の依存ファイル」に「OpenCL.lib」を追加すればOK。

Visual Studio 2010とAMD APP SDK 2.4さえちゃんと入っていればこれで全て動く。
これは64bit Windows 7とAMD GPUの組み合わせのみに当てはまると思うが、
32bitの場合でも(x86)の部分とソリューションプラットフォームの変更を除けばだいたいいけると思う。

2011年4月18日月曜日

4/18

隣の研究室からOpenCLの本を貸していただけた。
入門用の情報が少ないので渡りに舟だ。

就活関係の書類も一段落ついたので、
ようやく落ち着いて取り組むことができそうだ。

2011年4月15日金曜日

4/15

OpenCLのコンパイルがとうとう通った。
環境構築のアドバイスをしてくれたI君、ありがとう。

歓迎会がはじまるので、詳細は後ほど。

4/14

咄嗟のときに欲しい英単語が出てこず、もどかしいことが多い。
契約書を丸々翻訳(超訳?)する必要があったのだが、かなり体力を消費した。

日本人が外国のサイトを見るのは簡単だが、外国人が日本のサイトを見る場合、
特に文字列の入力が必要な場合は多くの困難があることを思い知った。
全角英数字を強要するのはさすがにやめるべきだと思う。

Windows上でOpenCL開発環境を構築したいのだが、
64bitのコンパイルの部分で大きく躓いてしまった。
Visual Studio 2010でもWindows SDK 7.1を指定しないと
うまくいかないことに気づくまで多くの時間を費やしてしまった。

2011年4月14日木曜日

4/13

今日はお隣さんと合同で歓送迎会を行った。
久々に会う人や新顔とも話せて色々楽しかった。


・OpenCL関係
VC++ Express版では64bitのコンパイルがうまく通らず、
DreamSparkのlicenseを見つけたので昨日の作業ログから多少変更が。

1.Windows 7インストール、LANなどの設定
2.AMD APP SDK 2.4をインストール(AMD-APP-SDK-v2.4-Windows-64.exe )
3.Visual Studio C++ 2010をインストール

Visual Studioはダウンロードに数時間かかり、インストールもまだ終わらない。
ISOイメージを展開しても何もファイルが現れずに焦ったが、
DVDに書き込めばちゃんとファイルを読み取れるようだった。不親切な設計だ。

終わりが見えず今日はもう眠いので、続きは明日やることに。

2011年4月11日月曜日

4/12 OpenCL作業ログ

Windows 7上に開発環境を構築。
APP SDK 2.4でAPU上でCPU-GPU間ゼロコピーがサポートされたため、
急遽CentOSからWindows 7へ鞍替えすることに。

1.Windows 7インストール、LANなどの設定
2.Visual C++ Expressをインストール
3.Windows SDK for Windows 7 and .NET Framework 4をインストール(AMD64対応のため)
4.AMD APP SDK 2.4をインストール(AMD-APP-SDK-v2.4-Windows-64.exe )

SDKをインストールすると、自動でドライバのインストールも開始する。



参考URL
http://www.02.246.ne.jp/~torutk/cxx/opencl/windows7_vc2010express_atistreamsdk.html

環境
[OS] Windows 7

2011年4月10日日曜日

4/10

APUノードだが、CentOS 5.6にしたところ、無事にインストールできた。
次はOpenCLプログラミング環境をセットアップする。
嵌らないことを願いたい。

[OS] CnetOS 5.6
[MB] E35M1-I DELUXE

2011年4月9日土曜日

4/8

Kernel Panic
新しく買っていただいたノードにCentOS5.4のインストールを試みたが、
Kernel Panicが多発してインストーラの起動すらできなかった。
衝撃。

PCI関連の読み込み時のようなので、APUが悪さを働いているかもしれない。
System Sは諦めて、うまくいくディストリビューションを探すしかないのか。

2011年4月8日金曜日

4/8

今日はB4が研究室にやってくる。

会津大学の研究室のAMD GPUに関する情報が得られるページ。
http://galaxy.u-aizu.ac.jp/trac/note/