OpenCLプログラミング#1
■ このスレッドは過去ログ倉庫に格納されています
さてついにOpenCLの仕様が公開されました。
http://www.khronos.org/opencl/
公式ページにはAPIのヘッダファイルが公開されており、
まだ実際に動かす事はできないもののプログラミングすることは可能となっています。
ということで、公開に先んじてプログラミングを始めてしまいましょう。 ふう・・・ついに完成しました
ちまちま25%使うよりフルロードはいいですね
ただ、オーバーヘッドがいくらあるからはわかりませんが・・・ 256MBの制限に引っかかって処理が止まるorz
これの上限増やせないのか? >>549
グローバルメモリが足りない・・・のかな?
ttp://www.ozone3d.net/gpu_caps_viewer/
これで確認してみて
それかワークスレッドの設定が悪いのかも >>550
なんでダメか分かった、ありがとう
ローカルメモリ32kbしかないのに2mb使おうとしてたwww >>551
使い捨てる変数の宣言くらいがちょうどいいよ
NVIDIAはローカルメモリ使わないと倍ぐらい遅くなるけど
他はそうでもないから(OpenCL入門に比較があったよ)
グローバルで問題ないと思うよ CUDAはGPUしかできないけど一度により多くの処理ができる
OpenCLはCPUとGPUを同時並列処理ができるのが魅力
どっちにも特化した特性があるからプログラムしだいだよ もうGPU固有じゃなくなってきたのね・・・
カーネル丸出しのCLは論文すら少ない・・・ 引数の渡し方が面倒なんだよなー
思わぬところでバグが出たりする openclを実用的に使うにはどんな環境がおすすめでしょうか グラフィックボードは倍精度不動小数点数(cl_amd_fp64)が利用可能な
Radeon HD 7900、6900、5900/5800 シリーズがおすすめ
http://blog.tommy6.net/archives/74
どうせおまえらめんどくさい組み込み関数なんか使わないだろってことか? GCNでアセンブリが変わったのか、動かなくなってしまった・・・ 変わる以前にGCN対応ドライバ&ランタイムまだ出てないでしょ
CCC12.1Previewが出回ってるからそれ付属のSDKランタイムなら動くんじゃないの Kernel AnalyzerもTahiti対応版出てないしな RADEONとGeforce、ガチンコ対決ではごっちが速いの? そもそもガチンコな応用でOpenCLってまともに実績あるの? とりあえず齧る分には公式のプログラミングガイド買っとけばおk? サブルーチンみたいにカーネルに直接引数渡して処理できればなぁ
アドレスを渡す時とかすげえ面倒。 そんな気軽にあちこちで使うようなもんじゃないっしょ カーネルソース丸出しか
特定デバイス用にコンパイルしておかないと
いけないのがなあ BOINC的なもので使うと不正対策必要で、既知の答えも一緒に計算させたりして対策するんだけどエコじゃないて悩ましいよ それなら同じWU他のやつに配って結果一致したやつだけ採用、
合わなかったら更に配布して一致した方採用でいいんでないかね
どのみち普通にやったって計算エラーになるのもいるし つーかカーネルがソースコードだから
改竄される恐れがなんて懸念するような
プログラムなら、どんな形態で配るにせよ
ディスアセンブルされりゃ同じだって。 10TFLOPSっていうと10年前のスパコンの性能と同じくらいだな 10年後に京の性能がご家庭に来るかというと、さすがにそうでもない感。 物理的限界が近づいてきたからこれまでとは事情が違うよね。
無知な人は技術でなんとかなるって言っちゃうだろうけどw 一般家庭にベクトル演算ってそんなに必要ない気が。。。 O(n^2)の直接法のN体とか本当にベンチマーク以上の意味はないんだがな
実用コードはツリー法やFMM法を使う O(n^2)がツリー法だとO(n logn)に、FMMだとO(n)になるそうだ
www.kurims.kyoto-u.ac.jp/~kyodo/kokyuroku/contents/pdf/1084-12.pdf AdobeのCS6でOpenCLが使われているという噂を聞いたんだが、カーネルのソースコードとかどうやってるんだろうか >>589
Adobeのライセンス認証部分のコードだって、一緒にディスクに入ってるわけですよ。
どうにでもなる。 Intel OpenCL SDKを使って開発をしようとしているのですが、CPUとGPUを非同期で
走らせる方法が分かりません。
サンプルなどないでしょうか? >>587
必ずしもそうでもない。もちろん限られたケースだが、空間ごとに時間刻みを変えたい場合とか、ツリー方とかだと複雑になりすぎてまだまだ難しい場合も多い。
そもそも、ツリーやFMMでも近傍場の計算は直接法だし、サンプルコードとして無意味ではない。
>>591
CPU側を並列化してGPUを扱うスレッド/プロセスとCPU側の計算をするものに分ける
並列化、同期はお好みの方法で 質問なんだけど今はAMD/nVidia/IntelどのSDKでビルドしても
AMD/nVidiaのドライバが入っている環境ならGPUが利用できるって理解でok? >>594
理論上は合っているよ。
まあ、微妙に非互換だったり、ランタイムの
インストール方法など気を使わざるを得ないのが現実だが。 GT440でclinfoしたら
Max compute units: 2
と出たんだけど、この2とGT440のCUDAコア96とはどういう関係にあるの? NVIDIAの場合
Max Compute unit = Streaming Multiprocessor(SM) = Streaming Multiprocessor eXtreme(SMX) CPUデバイスのランタイムを有効にするにはAMDかインテルのSDKをインストールしてもらうしかないの?
ランタイムだけのパッケージってある? >>601
Intel の Windows 用ならあるね。
AMD は知らん。 http://software.intel.com/en-us/articles/vcsource-tools-opencl-sdk/
のダウンロードリストボックスのOpenCL CPU only runtime(Windows* OS)ってやつか。
見落としてた。ありがとう。 >>604
どんなプログラムなのかしらないけど、ボクが試したのは充分速かったけどなぁ。
いやまあ、GPUと絶対値を比べればもちろん遅いけど。w CPUでOpenCL使うとお手軽にSIMD+マルチコア使えるな。 ベンチと言えば Intel と AMD で比べてみたら、Intel のほうがかなり速かった。
いやまあ、その PC の CPU は Intel だったんだけど。w
AMD な CPU だと逆転したりするのかなぁ。 >>606
お手軽じゃねーっつの。
CPUでSIMDとマルチコアを使いたいためだけにOpenCLを使つかうならアホだわ。
phoronixのベンチ見る限りだとAMDのSDKの方が速そうだったけど 少なくともカーネル部分はお手軽だよ。
素のCで使うと準備が面倒だが
C++のラッパーなら大した事は無い。
OpenCL以外でSIMDに自動で対応してくれるのってなにかあるの? インテルコンパイラ使っとけ。
それかFortranだな。 simdと言っているのがSSEのパックドなインストラクションのことでいいならgccでもOK。 ちょっと前までSSEwとか思ってたけど
これだけ並列プログラミングが普及してきてAVX2とかみると考え変わる >>611
んなアホな
CL用のメモリとのやり取りが発生するだけ無駄だよ
正直、マルチコアを使いたいならMPIが一番速い。
通信含めても。
OpenMPもなんだかんだであまり速くないな。
>>612
PGI はあまりコードの品質よくなかったな
>>617
なんか解釈に誤解があるようだが。
マルチコアのどんなプログラムでもOpenCLで書けという話ではない。
OpenCLのカーネルとして記述できるような問題に
適用すれば、なんも考えずにSIMDもマルチコアも
使えるようになるし、そういう用途に限れば
OpenMPやMPIもしくはPOSIX threadとかで
真面目に書くよりお手軽だし、余程の玄人が
書くのでない限り素早く、速いコードが書ける。
CL用のメモリ云々言っておきながら、速度面で
マルチスレッドなOpenMPでなくマルチプロセスになる
MPIをすすめるあたり根本的に理解に問題があるような。
まあ、通信部分はintel MPIとかなら共有メモリ使うから
極端に不利にはならないけど、少なくともこれが最速とは行かない。 てかさ、CL 用のメモリとのやりとりなんかしないよね?
いや、しないようにつくるよね????
>CPUでSIMDとマルチコアを使いたいためだけにOpenCLを使つかうならアホだわ。
うわ、アホって言われちゃった。てへ。 OpenCLとMPIの並列化は全く別もんだし、
OpenCLとOpenMPの並列化もちょっと違う。
正直OpenCLのカーネルを書くくらいなら、
OpenMPを使った並列化の方が圧倒的に楽だわ。
OpenCLを使うメリットは複数のプラットフォームで動かすためだけだろ。
>>619
CLデバイスとCPUは論理的に別物なんだからメモリ転送はいるだろ。
>>620
GPUがなければOpenMPなりMPIなりで並列動作しているというプログラムを作ればよい。
CPUの並列も面倒くさいのでCLでってのは手抜き杉 >>622
CLで書くほうが手間がかかると思うが。。。
CPU用のコードとNVIDIA用のコード、ATI用のコードを用意するのはかなり大変だし。だからOpenCLが生まれたわけで。
>>623
GPUがあればそっちをつかいたいのならCLを書くこと自体が手間とか言ってる場合じゃないだろ。
それ一本で済まそうというのが手抜きだっての。
CPUでCLつかっても無駄なオーバーヘッドが出るだけだし 論理的に別なのはわかるけど
対象がCPUの時にはメモリコピーしないような実装になっててもおかしくないような気もする まあ、小さい規模のコードしか書いてない奴には分からんかもしれんが、
複数のハードウェアプラットフォームをそれぞれメンテしないといけなのは、
かなりの工数がかかるからな。
多少のパフォーマンスを犠牲にしても良いことなんて沢山あるんだよ。
えぇ〜・・・・・・。
キミタチは実際につかったことないんだね?
ttp://software.intel.com/sites/landingpage/opencl/optimization-guide/index.htm
の Sharing Resources Efficiently とか読んでごらんよ。 >>630
> 、99割
0.99 割? 990% ?
どのスレに書こうとしてたの? OpenCLハードル高いなぁ
どの機材構成でどのプラットフォームでどう書けば速くなるか
検証すべき項目が多すぎる 週あすwでAPUの記事載ってて、OpenCLで何でも高速に出来るように書いてたなぁw write once, tune everywhere OpenCL1.2ではデバイス分割ができるみたいだけど
それまでってどうやって並列化してたの?
コマンドキューをCompute Unit分生成してたの?
それともclEnqueueNDRangeKernelがいい感じに並列化してくれてたの? でっかく突っ込んだら普通にデスクトップがフリーズしてた。 >>642
Radeon の一番高いヤツをさせるだけさす。w ■ このスレッドは過去ログ倉庫に格納されています