5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

OpenCLプログラミング#1

1 :a36 ◆K0BqlCB3.k :2008/12/10(水) 15:38:25
さてついにOpenCLの仕様が公開されました。

http://www.khronos.org/opencl/

公式ページにはAPIのヘッダファイルが公開されており、
まだ実際に動かす事はできないもののプログラミングすることは可能となっています。
ということで、公開に先んじてプログラミングを始めてしまいましょう。

2 :デフォルトの名無しさん:2008/12/10(水) 15:57:47
ひとまずwgetじゃなくて2get
Mac界隈ではCore Imageみたいにかなり使われそうだけど他のプラットフォームではどうなるかな?

3 :デフォルトの名無しさん:2008/12/10(水) 19:55:47
仕様策定にあたり、国内メーカはほとんどなし?

NやFなどのスパコンメーカは入っていてもよさそうなのに…

4 :デフォルトの名無しさん:2008/12/10(水) 20:08:08
イマイチだなこりゃ
極一部で流行って終了の予感

5 :a36 ◆K0BqlCB3.k :2008/12/10(水) 20:10:45
>>2
まだGPGPUでどんな事ができるのか模索している段階ですので、
キラーアプリが早い段階で出てこないとOpenCLを標準化するのは
難しくなっていくと思います。
Microsoftや他の団体が別の標準を作ってしまってからでは
OpenGLとDirectXのような亀裂を生んでしまうでしょう。

6 :a36 ◆K0BqlCB3.k :2008/12/10(水) 20:12:58
とりあえず、仕様書の翻訳を始めるために許可とってきます。

7 :デフォルトの名無しさん:2008/12/10(水) 20:27:22
SpursEngineが対応しそう。
ttp://www.watch.impress.co.jp/akiba/hotline/20081206/etc_toshibaev0.html

8 :デフォルトの名無しさん:2008/12/10(水) 20:49:11
>汎用API「Open CL」への対応も「好きな奴がいて、
>仕事の合間にやっている」(同氏)とのこと。これが実現すると、
>「同じプログラムがCPUでもGPUでもSpursでも動く」
>という環境になるが、進行状況については「上司からお金が
>もらえなくても、コツコツと(笑」なのだとか。

期待できるのかなw

9 :デフォルトの名無しさん:2008/12/10(水) 21:27:51
金出してやれよ

10 :デフォルトの名無しさん:2008/12/10(水) 22:04:54
Pixelmatorとか対応しそうじゃないか?
したらPhotoshopを超える最強アプリになる予感。

11 :デフォルトの名無しさん:2008/12/10(水) 22:25:22
いまいち分からん。
CUDAとOpenCLって何が違うんだ?
誰か詳しい人説明頼む。
http://www.nvidia.com/object/io_1228825271885.html

12 :デフォルトの名無しさん:2008/12/10(水) 22:29:24
簡単に言うと、NVIDIAが独自にGPU用に作ったのがCUDAで、
GPU以外のデバイスも視野に入れられて作られようとしているのがOpenCL。

13 :デフォルトの名無しさん:2008/12/10(水) 22:33:06
寿命短そうだな

14 :デフォルトの名無しさん:2008/12/10(水) 22:34:08
>12
thx
GPU以外ってことはLarrabee(これでスペルあってる?)や>>7の言うようにCellか?

15 :デフォルトの名無しさん:2008/12/10(水) 22:43:28
想像だけど、ClearCaseやTerareconのようなデバイスメーカも対応せざるを得なくなるかもね。
CPUでも実装可能だし、当然ララビーも対応してくるんじゃない?

16 :デフォルトの名無しさん:2008/12/10(水) 22:52:56
iPhoneの例のスレと似たふいんき・・・何なの

17 :a36 ◆K0BqlCB3.k :2008/12/10(水) 23:17:58
■Khronos Group発表ニュースリリースの抄訳
http://www.khronos.org/news/articles/20081209-OpenCL-1-0-jp.pdf

■OpenCL 1.0 仕様書(英語)
http://www.khronos.org/registry/cl/specs/opencl-1.0.29.pdf

■cl.h - OpenCL 1.0 ヘッダファイル
http://www.khronos.org/registry/cl/api/1.0/cl.h

■cl_gl.h - OpenCL 1.0 OpenGLインテグレーションヘッダファイル
http://www.khronos.org/registry/cl/api/1.0/cl_gl.h

■cl_platform.h - OpenCL 1.0 環境依存マクロ
http://www.khronos.org/registry/cl/api/1.0/cl_platform.h

※まだ OpenCL 1.0 ツールキットはリリースされていません

18 :デフォルトの名無しさん:2008/12/10(水) 23:30:05
さらっとサンプルソース見たけど
clCreateProgramWithSourceに渡すのはソースのテキストそのままだけど、
clCreateProgramWithBinaryに渡すバイナリって何だろ、
そのバイナリってデバイス間で互換性あんの?

19 :デフォルトの名無しさん:2008/12/10(水) 23:36:32
CUDA向けに書いて少しいじればOpenCLでも動くのかな?
http://www.appleinsider.com/articles/08/12/10/nvidia_pioneering_opencl_support_on_top_of_cuda.html

20 :デフォルトの名無しさん:2008/12/11(木) 00:25:28
少々スレ違いだけどKhnoros Groupって他の標準化もやってたのか。
OpenVG(オープンなベクターグラフィックスAPI)
http://journal.mycom.co.jp/news/2008/12/10/073/index.html


21 :デフォルトの名無しさん:2008/12/11(木) 00:49:08
なんなのこのふざけた名前

22 :デフォルトの名無しさん:2008/12/11(木) 03:46:32
>>14
重箱隅ですがspursはCell規格じゃないですよ。PPEねーし。

PS3以外のCellにOpenうんちゃらみたいな標準規格って需要あんのかな?
IBMのCellスパコンとかは、素人目には専門家がカリカリチューニングしてそうな印象あるし

OpenGL以外におけるKhronosをどこまで信用して良いのかもいまいち。
COLLADAとか半端仕事な印象拭えないんだよな……。使ってるとこは使ってんだろか?

23 :デフォルトの名無しさん:2008/12/11(木) 21:38:21
>>22
PS3 みたいなガチガチに決まってる奴にこそ不要だろ。

例えばこういうの
http://www.hirax.net/dekirukana8/bijin2/
こそ、OpenCL的なものが実力を発揮しやすい。
で、この機能がDVカムとかに普及したとしよう。
OpenCL で実装しておけば、次のバージョンの製品の該当部分を、OpenCL 対応の別のチップに変更することも出来る。Cell から nVidia へというように。

これは一例だが、要するに標準規格への需要はある。
だけど、汎用性は効率とのトレードオフでもあるし、ネガティブな要素を数え上げればきりがない。

現段階で普及するかどうかを予測するのは無意味に近いが、今なら先行者利益に預かれるかも知れない。

24 :デフォルトの名無しさん:2008/12/12(金) 21:58:03
組み込み関連の所が多いって所にやっぱメディア系の家電とかへの需要が期待されてるのかね
車載とか携帯電話もありうるのかな

25 :デフォルトの名無しさん:2008/12/13(土) 06:17:58
>>24
ありうるけど、まだ高価すぎる。
PIC や DSP なみにコモディティ化したら、みんなが使うだろう。
組み込みにとっては、CUDA か CL かというのは、次かその次の世代の話だろう。

ま、現場はアレもコレも知っとかないとねw

26 :デフォルトの名無しさん:2008/12/13(土) 08:55:49
これれは今出てるiPhoneでも使えるのかね

27 :デフォルトの名無しさん:2008/12/13(土) 10:14:46
>>26
ARMはSIMDらしいよな。
Appleがやってくれるかもしれん。

28 :デフォルトの名無しさん:2008/12/15(月) 02:44:31
DsPICってのも有るし、しかも最近clockがどんどん上がってる。
このPICに載ってるDSPの数が増えたら8bitのGPGPUって感じじゃね?

29 :デフォルトの名無しさん:2008/12/15(月) 09:32:57
dsPIC m9(^Д^)プギャーーーッ

30 :デフォルトの名無しさん:2008/12/17(水) 03:23:32
なんでこのスレでdsPICの名前が
CLで叩く意味はちょっと見出せないw

31 :デフォルトの名無しさん:2008/12/18(木) 03:06:23
これは楽しみだわ

32 :デフォルトの名無しさん:2008/12/22(月) 21:22:09
spec読んだけどcudaに毛が生えたようなもんだね
メモリ階層もモデル化したと言うけど、ほぼ現行のGPUが前提。
興味なくなった。

33 :デフォルトの名無しさん:2008/12/22(月) 21:51:48
1.0だからな・・・
Intel VTと同じで2.0からが本気なんだよwww

34 :デフォルトの名無しさん:2008/12/23(火) 14:09:23
Open CLって結局なんなんだよ

35 :デフォルトの名無しさん:2008/12/23(火) 19:27:26
http://journal.mycom.co.jp/column/osx/305/index.html

36 :デフォルトの名無しさん:2009/02/15(日) 19:12:01
2009年,本格始動するGPGPUの世界・後編〜GPGPUのプラットフォーム動向
http://www.4gamer.net/games/076/G007660/20090206031/

37 :デフォルトの名無しさん:2009/02/15(日) 19:15:04
>>32
>OpenCLについて,「Direct3DにおけるDirectX Compute Shaderのようなもの?」
>というイメージを抱くかもしれないが,コンセプトや実現様式が微妙に違う。
>
>最大の違いは,OpenCLが,GPUだけを対象としているわけではないということだ。
>x86プロセッサやCellプロセッサといったCPU,あるいは DSP(Digital Signal Processor)
>のようなメディアプロセッサなどのプログラミングに対応するコンセプトを持っており,
>GPUに特化したDirectX Compute Shaderとは似て非なるものだといえる。

38 :デフォルトの名無しさん:2009/02/15(日) 20:17:07
>>37
大丈夫、DSPがOpenCLに対応する可能性は限りなく低いから。
まして、x86プロセッサでOpenCL対応するくらいならCt使う方が遥かにまし。

39 :デフォルトの名無しさん:2009/02/15(日) 22:24:19
つーかOpenCLってとりあえずMac用でしょ

40 :デフォルトの名無しさん:2009/02/15(日) 22:27:21
なんで?

41 :デフォルトの名無しさん:2009/02/15(日) 22:30:45
OpenCLの規格化作業を猛烈に推し進めたのがアップルだから

42 :デフォルトの名無しさん:2009/02/15(日) 22:42:22
だからMac用?
どうして?

43 :デフォルトの名無しさん:2009/02/15(日) 22:42:47
>>38
なんか理解できてないようだけど、
こいつの価値は並列処理にあると思う。
要するに今までのGPGPUは、GPUによる高速化
というのがメインだったけど、OpenCLの場合は、
CPUとGPUで並列処理が可能になる。

元々はAppleとNVIDIAが協力して、CUDAを基礎に
した(と思われる)ものを、さらに標準化の過程で
より汎用性を重視して、GPUに依存しないよう設計
にしたものがOpenCL。

44 :デフォルトの名無しさん:2009/02/15(日) 22:48:46
>>42
大丈夫、Mac専用じゃないよ。
Appleが規格の孤立化を避けるのが目的だと思うけど、
最初からオープン標準化にこだわって作られた規格。

規格の策定作業のメンバーにはIntelやAMD、NVIDIA、
ソニーなど、MSを除く主要企業は全て参加しているし、
OpenGL(ES)との連携やスマートフォンへの対応もあるし、
これから先、携帯端末全盛の時代の最有力候補でもある。

45 :デフォルトの名無しさん:2009/02/15(日) 22:50:10
>>44
あんたに聞いてないんだよ

46 :デフォルトの名無しさん:2009/02/15(日) 23:06:31
>>45
あうごめんwでも答えちゃうよ?

Mac OS X Snow Leopardに実装されるのがOpenCLで、
Windows7/vistaに実装されるのがDirectX Compute Shader。
どちらのGPGPU技術もまあ競合するものだわさ。

スマートフォンへの実装は別にして、DirectX系技術はWindows限定だし、
OpenCLにはオープンな技術というメリットがある。ただし、Windowsが市場を
ほぼ独占してるPC業界にとって、有力なのはやはりDirectX Compute Shader
の方になる。だから当面、OpenCLの主要プラットフォームがとりあえず
Macなのは致し方ない現実、という考え方じゃないのかな?

もちろんマルチプラットフォーム化を重視して、Windows環境下でも
OpenCLを採用する企業も当然存在するとは思うけど。

47 :デフォルトの名無しさん:2009/02/15(日) 23:13:48
>>46
お前の意見なんてどうでもいい
マジで黙ってろクソ野郎

48 :デフォルトの名無しさん:2009/02/15(日) 23:18:30
>>47
あうごめんwでも答えちゃったよ?

49 :デフォルトの名無しさん:2009/02/16(月) 18:57:22
で、まだかね?

50 :デフォルトの名無しさん:2009/02/17(火) 11:40:11
マルチコア動作版くらいそろそろ出せよ ガオー

51 :デフォルトの名無しさん:2009/02/17(火) 11:44:25
てかDirectXは独自に実装するみたいだが
MSは意地でも標準化を妨害したいらしいw

52 :デフォルトの名無しさん:2009/02/17(火) 12:35:14
妨害つーか、OpenCLはOpenGLとは連携するが
Direct3Dとは連携しないので、MSが自前で作るしかない。

53 :デフォルトの名無しさん:2009/02/21(土) 19:01:40
MSはどっちかっていうとマルチCore CPUをグラフィックに活かそうとしているよね。
逆。

54 :デフォルトの名無しさん:2009/02/21(土) 19:03:43
>>52
MSはCompute Shaderを準備中。

55 :デフォルトの名無しさん:2009/02/26(木) 00:45:30
言語はC99ベースだからいいかと思ったけど、再帰が使えないのは痛いな。
Cで書いてコンパイルしたバイナリと、OpenCLで書いてコンパイルしたバイナリを
リンクできればいいな。



56 :デフォルトの名無しさん:2009/02/26(木) 11:20:43
.objが中間コード的なものだったら出来たかもね。

57 :デフォルトの名無しさん:2009/02/28(土) 03:39:12
再帰なんていらね

58 :デフォルトの名無しさん:2009/04/02(木) 08:17:35
並列化しやすい問題で結構使うぞ、再帰探索は
こっち方面はIntelに期待するしかないかもね

59 :デフォルトの名無しさん:2009/04/02(木) 23:41:47
時間とメモリの使用量が不定になるからねぇ。
OpenCLの主戦場を考えるとどうなんでしょうか。

60 :デフォルトの名無しさん:2009/04/03(金) 01:52:09
再帰するようなアルゴリズムの場合、命令ポインタの動きに一意性がないし
決してデータレベル並列ではないんだよな。
SIMDでは命令ポインタが要素ごとに独立、というわけにはいかない。
プレディケートをやるのは逆に言うと自由に分岐ができないことの現れだし。

61 :デフォルトの名無しさん:2009/04/11(土) 13:13:33
ほしゅ

62 :デフォルトの名無しさん:2009/05/03(日) 23:04:11
まだ?

63 :デフォルトの名無しさん:2009/06/14(日) 18:31:47
>>55
残念だが OpenCL C は Java や .NET のような中間コードで
OS 上のドライバがリアルタイム翻訳するからリンクは無理。

だが OpenCL を利用する本体は何でもいいから
C や C++、Objective-C なんかで再帰検索すればいい。

64 :デフォルトの名無しさん:2009/06/20(土) 18:47:32
企画書ってどこで読めるの?

65 :デフォルトの名無しさん:2009/06/20(土) 20:41:46
>>64
OpenCL 1.0 仕様書
ttp://www.khronos.org/registry/cl/specs/opencl-1.0.43.pdf

66 :デフォルトの名無しさん:2009/06/21(日) 04:07:00
Appleが用意したOpenCLの技術解説のpdfのリンク貼っとく
http://images.apple.com/macosx/technology/docs/OpenCL_TB_brief_20090608.pdf

67 :デフォルトの名無しさん:2009/06/29(月) 13:32:04
OpenCLのCPU動作版って公式で作るのか?
それとも誰か作ってる人が居る?

68 :デフォルトの名無しさん:2009/06/30(火) 20:18:36
Intel か Apple が CPU 用 OpenCL ドライバを作成すれば問題ない。

Windows や Linux の他社 OS や
AMD などの他社 CPU などで動作するドライバは
やっぱり公式待ちかな。

個人で Java VM や GPU Direct3D/OpenGL ドライバを
作ってしまえる人が興味を持ってくれたら話は別だけど。

69 :デフォルトの名無しさん:2009/06/30(火) 20:23:54
スノレパにはCPU用ドライバが付いてくるでしょ

GPUよりも数十倍から100倍以上は処理が遅いCPUで
Open CLを動かす価値が有るかはわからないけれど

70 :デフォルトの名無しさん:2009/06/30(火) 20:34:15
>GPUよりも数十倍から100倍以上は処理が遅いCPU
という夢を見ている

71 :デフォルトの名無しさん:2009/06/30(火) 20:46:55
Core 2 Quad QX9775: 102.4 GFLOPS
Radeon HD4870:1.2 TFLOPS(1200 GFLOPS)

一桁余分だな。

72 :デフォルトの名無しさん:2009/06/30(火) 23:19:38
このスレで言うのもなんだが並列処理って知ってる?

73 :デフォルトの名無しさん:2009/07/01(水) 00:44:41
CPU と GPU を並列に走らせて 10 が 11 になるよりも、
その1をUIやGPUが苦手な処理を与えたほうがいいんじゃね?

マルチタスク(プロセス)的にも CPU は空けておきたいかも

74 :デフォルトの名無しさん:2009/07/01(水) 02:58:17
CPUよりGPUのが早いってことになってるけど
それは実は大嘘でちゃんとマルチコアで作りこんだらスピードは大差ない
GPUメーカー製のドライバはCPUでも動くような振りだけは実装するだろうけど
絶対にまともな実装はしない、ばれるから
だからちゃんとしたCPUメーカーか第三者が作ったものが必要

75 :デフォルトの名無しさん:2009/07/01(水) 03:05:43
>>71
それは理論的な演算速度だけだとそうだけど
メインメモリからデータを取り出して結果を戻すのに要する時間で計算すると
遥かにCPUの方が早い

76 :デフォルトの名無しさん:2009/07/01(水) 06:44:02
結局ワークロード次第なのだがGPUが明らかに速い分野なんて非常に限定的で馬鹿にされまくっているのが実情
GPGPUは過去のEPICと被るな

77 :デフォルトの名無しさん:2009/07/01(水) 11:17:39
>>74
なんでGPUメーカーがCPU用ドライバを作るんだよ。
DirectXですらCPU用ドライバはMSが作ってるんだぜ?

>>75
特定分野に関してならメモリアクセスは速いでしょ。
じゃないと3Dレンダリングが使い物にならないものになる。

結局プログラマがどれだけ局所化を行えるかだろうね

78 :デフォルトの名無しさん:2009/07/01(水) 14:42:50
>>77
3Dは転送する情報量は頂点座標だけなんだからCPUより早いのは当たり前でしょ
CPUのネックはメモリ転送速度だって言ってるでしょ
大量のデータを計算するような用途ではどんな工夫をしようがCPUには勝てない

79 :デフォルトの名無しさん:2009/07/01(水) 14:45:50
しかも分散処理する部分は複雑に作りこんでないから
計算してる間は描画が止まるからな
計算してる間は文句なしに画面描画が止まる
CPUだと計算負荷に応じて外も動くけど

80 :デフォルトの名無しさん:2009/07/01(水) 14:51:59
>>78
だからそのCPUでは勝てない分野でGPUを有効活用しようっていうのがGPGPUでしょ

映像のエンコードしかり、ゲノムの解析しかり超大量のデータ処理を肩代わりしたり、
またはAIなどの人工知能やMSのProject Natalみたいなものを実現するため、とか

81 :デフォルトの名無しさん:2009/07/01(水) 14:57:20
>>79
だからGPUの仮想化とかマルチタスク処理とかがあるんでしょう

3Dゲームとかでもない限り 1/60 秒毎に画面描画を
挟むのはたいした負荷でもないレベルだし。

GPUでは小回りが利かない部分を管理するのがCPUの得意分野

82 :デフォルトの名無しさん:2009/07/01(水) 17:58:11
>>80
だから今の構造だとCPUでは勝てない分野が3Dポリゴンの描画しかないのw

83 :デフォルトの名無しさん:2009/07/01(水) 17:59:09
>>81
>>GPUでは小回りが利かない部分を管理するのがCPUの得意分野

現状と何も変わらない

84 :デフォルトの名無しさん:2009/07/01(水) 18:03:26
本来ならGPUの機能はCPU内部にあるべきだが、
IBMやINTELはサーバとか大規模計算方面ばかり気にして3Dとかグラフィックとかを軽視していたから、
見るに見かねた人がGPUなんてものを作ったんだよね。

85 :デフォルトの名無しさん:2009/07/01(水) 18:04:59
GPUって、本質的に見たらやってることはCPUと変わらないのに、
CPUとバスを経由して通信している分無駄があるんだよね。
だから将来的にGPUはCPUに飲み込まれるのが健全だと思うね。

86 :デフォルトの名無しさん:2009/07/01(水) 18:11:33
行列積とか倍精度でもGPUの方が速いだろ。


87 :デフォルトの名無しさん:2009/07/01(水) 18:23:10
>>86
そういう処理をするCPUの命令の一つにしてしまえば良い。

88 :デフォルトの名無しさん:2009/07/01(水) 18:44:55
>>86
だから計算対象のデータをGPU側に引き渡してる間にCPUで計算出来るっつー話だわな

89 :デフォルトの名無しさん:2009/07/01(水) 18:47:34
>>88
いや、まぁ実際にそういうことが多いわけだけど、俺が言いたいのそうじゃなくて、
GPUをCPUに統合するのが健全だと言っているだけであって・・
夢見がちな俺の願望でしかないわけだが。

90 :デフォルトの名無しさん:2009/07/01(水) 21:55:32
>>89
今その方向に向かっているな。
AMDそのためにATIを買ったんだし、GPU専業のNvidiaは焦っている。

91 :デフォルトの名無しさん:2009/07/01(水) 22:00:36
ハードだけ買ってもOpenCLはじめソフトがgdgd
このままだとIntel最強ってゆー何時もの結論で終了する

92 :デフォルトの名無しさん:2009/07/02(木) 01:07:12
マカーとして言わせてもらえばQuickTimeとAdobe CSくらいが対応してくれれば対応アプリとしては十分な気がするんだよな
OpenCLが一番活用できそうなのって結局画像動画関連だし
それにCoreImageやCoreVideoがCPUでも動いたようにOpenCLもCPU上で動かせるから未来がどっちに転んでも技術としては問題ないと思う

93 :デフォルトの名無しさん:2009/07/02(木) 01:20:12
夜のお供に漫画ビューアにもな。

94 :デフォルトの名無しさん:2009/07/02(木) 10:11:18
画像ビューアはCPUで処理したほうが速いだろ

>>89
Intel Larrabee というGPUは Pentium MMX というCPUに
GPU用のベクタプロセッサを沢山積んだモノになるよ。

で、そこで培った技術で後々 CPU 命令に GPU 命令が内蔵される。

>>92
Adobe CS4 はすでに CUDA や ATI Stream に対応しているから
下位互換でしかない OpenCL に対応する意味は余り無い。

95 :デフォルトの名無しさん:2009/07/02(木) 12:51:12
DCのデモでも、CPUより早く動かすの苦労してたよ。
データ数が半端無く多くないとCPUを上回れない。

96 :デフォルトの名無しさん:2009/07/02(木) 12:56:37
茸の左をひょいひょい躱した粟生と
リナレスの鬼速ジャブ…

この対決は興味深いぜ

97 :デフォルトの名無しさん:2009/07/02(木) 16:12:28
CPUとは別に画像処理などに有用なコプロセッサが1つ
PCやMacで眠っているからそれも使おうって方向でいい。

98 :デフォルトの名無しさん:2009/07/02(木) 19:12:15
昔はコプロって別売りだったな。

99 :デフォルトの名無しさん:2009/07/02(木) 20:12:40
GPUの得意分野は浮動小数点数のベクタ演算だからなおさらコプロちっく

100 :,,・´∀`・,,)っ-○○○:2009/07/02(木) 20:52:46
Larrabeeって次世代の8087って位置づけなんだろうな

101 :デフォルトの名無しさん:2009/07/03(金) 02:14:02
数年後にはCPUに統合されるのがわかりきっているけどな

102 :デフォルトの名無しさん:2009/07/03(金) 02:15:26
そのさらに数年後には独立されるだろう

103 :デフォルトの名無しさん:2009/07/03(金) 02:58:35
CPUだけじゃ最先端3Dレンダリングを処理しきれないwって理由で、か

104 :デフォルトの名無しさん:2009/07/03(金) 04:19:19
画期的なメモリバス技術でも開発されれば統合プロセッサのまま進化を続けるんじゃないかな

105 :デフォルトの名無しさん:2009/07/03(金) 06:38:34
ワイドテレビでこんなに広く!→縦が伸びてこんなに広く!→ワイドになって(ry

106 :デフォルトの名無しさん:2009/07/03(金) 22:50:21
CPUはある意味CELLの行く道が正しかったのか?

107 :デフォルトの名無しさん:2009/07/03(金) 22:56:22
>>105
ますます家が狭くなるがな

108 :デフォルトの名無しさん:2009/07/04(土) 15:37:52
OpenCL自体は普通にマルチスレッドのフレームワークに使えるから期待してるんだけど
出来ればクラスタリングとかにも対応して欲しいが

109 :デフォルトの名無しさん:2009/07/04(土) 17:43:55
OpenCL って Direct3D のシェーダ言語同様にドライバによる
インタプリタだと認識しているけど並列計算のフレームワークとして使えるの?

OpenMP や Grand Central Dispatch じゃダメなのだろうか

110 :デフォルトの名無しさん:2009/07/04(土) 18:47:02
演算シェーダ相当の抽象化レイヤと考えて問題ないよ
汎用的な並列計算はOpenMPやGCDの方が適切。そのままマルチコアCPUをターゲットにした方がいい
OpenCL適用できる分野は「並列計算」の中のさらに「GPUに適した」特殊なアルゴリズム分野になる
とにかくデータを小さなブロックに小分けして、延々と同じ処理繰り返すようなの

111 :デフォルトの名無しさん:2009/07/04(土) 19:29:33
標準化されてることに意味がある

112 :デフォルトの名無しさん:2009/08/06(木) 17:03:14
AMD、業界初のx86 CPU対応OpenCLソフト開発プラットフォームを無償提供
ttp://pc.watch.impress.co.jp/docs/news/20090806_307447.html

米AMDは5日(現地時間)、ATI Stream SDK v2.0 Beta Programの一環として、
新たに「OpenCL for CPU Beta」を無償で提供開始すると発表した。

x86 CPUに対応する業界初のOpenCLソフト開発プラットフォーム。
これを利用することにより、GPUとマルチコアCPUの両方を活用した並列プログラムの開発が容易になるという。

OpenCLは、Khronos Groupが提供するパラレルコンピューティング用オープンスタンダード。
同グループにはNVIDIA、Intel、Appleなども加盟している。



113 :デフォルトの名無しさん:2009/08/07(金) 13:07:44
やっと動きが

114 :デフォルトの名無しさん:2009/08/08(土) 11:10:40
これRADONには対応しとらんのん?

115 :デフォルトの名無しさん:2009/08/08(土) 11:13:29
ラドン…だと?新手の北朝鮮ミサイルか?

116 :デフォルトの名無しさん:2009/08/08(土) 12:03:20
恐竜だろ

117 :デフォルトの名無しさん:2009/08/08(土) 15:02:36
風呂かとおもった

118 :デフォルトの名無しさん:2009/08/08(土) 19:53:25
サンプル動かしてもGPU全然関係ないな(´・ω・`)
ATI StreamなのになんでCPUだけなんだよ

119 :デフォルトの名無しさん:2009/08/08(土) 22:02:49
AMDの対応がまだなんじゃね。

120 :デフォルトの名無しさん:2009/08/08(土) 23:16:43
ていうか Radeon の OpenCL ランタイムドライバが出来ていないとか?

121 :デフォルトの名無しさん:2009/08/11(火) 09:48:44
CPU対応は優先度が一番高いんだろう
GPUはチップ毎に対応しないといけないし

CPUとGPUの比較をしたり両方使って同時処理するのにも必要

122 :デフォルトの名無しさん:2009/08/15(土) 07:49:11
俺予想
OpenCLが動くということはnVidiaと同じ土俵でパフォーマンスが比較できるようになる。
現行のRADEONだとOpenCLでパフォーマンスが出ない。
nVidiaと比較されるのがいやなので今はドライバを出さずに
次のGPU(OpenCL向け機能拡張入り)を出すタイミングでドライバを出す。


123 :デフォルトの名無しさん:2009/08/15(土) 19:05:49
>>122
萩原Obj-C(1.0のやつ)をみながらやっているもので。
Tiger使っているので2.0へはまだいけない。

124 :デフォルトの名無しさん:2009/08/15(土) 19:07:04
ごめん間違えた。

125 :デフォルトの名無しさん:2009/08/17(月) 10:37:46
>>122
DX11 Compute Shaderなら(機能は限定されるだろうけど)DX10以降のGPUで動くよ

126 :デフォルトの名無しさん:2009/08/18(火) 00:53:33
はやくCLとDX10こねーかなー

127 :デフォルトの名無しさん:2009/08/18(火) 00:54:40
11だった どんだけwktkして待ってるとおもってんだ

128 :デフォルトの名無しさん:2009/08/24(月) 13:36:00
http://pc.watch.impress.co.jp/docs/news/20090824_310402.html
先にDirectComputeの方がきちまった

129 :デフォルトの名無しさん:2009/08/25(火) 01:30:39
AMD DX11 Cypress is Radeon HD 5870 & HD 5850
ttp://vr-zone.com/articles/-rumour-amd-dx11-cypress-is-radeon-hd-5870--hd-5850/7469.html?doc=7469

・1GB GDDR5 memory
・ATI Eyefinity technology with support for up to three displays
・ATI Stream technology,
・Designed for DirectCompute 5.0 and OpenCL
・Accelerated Video Transcoding (AVT)
・Compliant with DirectX 11 and earlier revisions
・Supports OpenGL 3.1
・ATI CrossFireX multi-GPU support for highly scalable performance6
・ATI Avivo HD video and display technology
・Dynamic power management with ATI PowerPlay? technology
・DL-DVI, DL-DVI, DisplayPort, HDMI
・PCI Express 2.0 support

130 :デフォルトの名無しさん:2009/08/25(火) 07:51:29
AMDの場合、1月頃に出したGPUにも"OpenCL ready"ってスペック表にあったんだよな・・・(遠い目)

131 :デフォルトの名無しさん:2009/08/25(火) 07:54:26
実際出してもまともに動かないATI

132 :デフォルトの名無しさん:2009/08/25(火) 11:24:47
Snow Leopard(10.6)が28日に出るらしいぞ。
技術仕様の中に
「OpenCL
以下のグラフィックカードまたはグラフィックプロセッサのうち、いずれかひとつが必要です。
# ATI Radeon 4850、Radeon 4870」
ってあったから、こっち優先して他のは後回しにされてんじゃね?

133 :デフォルトの名無しさん:2009/08/25(火) 11:52:01
AMDのOpenCL入門記事「Introductory Tutorial to OpenCL」
ttp://developer.amd.com/gpu/ATIStreamSDK/pages/TutorialOpenCL.aspx

134 :デフォルトの名無しさん:2009/08/25(火) 21:19:55
>>132
ないない。
ATIのMac版は常に後。再生支援すらまともじゃない笑えない現実がある。

135 :デフォルトの名無しさん:2009/08/25(火) 21:55:12
再生支援とは別としてOpenCLは力を入れてくるんじゃないか

136 :デフォルトの名無しさん:2009/08/26(水) 08:51:22
>>135
ATIのOpenCL対応GPUが>>132の二つだけということからも極めて怪しい。

137 :デフォルトの名無しさん:2009/08/26(水) 23:19:23
? よくわからんが後回しどころか4800シリーズの二つは既に対応してるんだよな?

138 :デフォルトの名無しさん:2009/08/27(木) 00:17:44
後一両日中には分かることさ

139 :デフォルトの名無しさん:2009/08/27(木) 11:05:51
>>137
nVidiaに比べてしょぼしょぼ。

http://netkas.org/?p=164
>Radeond OpenCL support is very poor, only few of many apple’s opencl
>demo run on it


140 :デフォルトの名無しさん:2009/08/28(金) 20:25:46
だれかOSXで試してみたやつおる?

141 :デフォルトの名無しさん:2009/08/29(土) 07:02:33
OSXでOpenCL使っているアプリが無い

142 :デフォルトの名無しさん:2009/08/29(土) 08:49:38
ATIは宣伝文句ばっかりでやることはごみ
まさかこんな最新技術を扱うスレでRADEONなんて買ってる情弱はいないと思うが

143 :デフォルトの名無しさん:2009/08/29(土) 10:25:26
>>141
そっちは今からじゃね?
次のiLife系列で対応してきそうだし

144 :デフォルトの名無しさん:2009/08/29(土) 14:00:11
QTXがたいおうしていなかったっけ?

145 :デフォルトの名無しさん:2009/09/05(土) 03:48:17
対応したところで現在のところ95%のMacに載ってるGPUは使い物にならない性能
Mac ProですらGT120 (9500GT相当) だからな

146 :デフォルトの名無しさん:2009/09/11(金) 08:23:44
>ATI StreamSDK 2.0 beta(Windows, CPU 利用)の
>OpenCL 実装だと、8 秒近くもかかってとてつもなく遅い!
>(SnowLeopard だと 0.0001 秒なのに…)
http://lucille.atso-net.jp/blog/?p=907

そもそもAMDの実装が糞という話が・・・

147 :デフォルトの名無しさん:2009/09/12(土) 22:51:30
>>146
世に出すってレベルじゃねーな。何かの間違いだとは思うが。

148 :デフォルトの名無しさん:2009/09/13(日) 02:25:23
つ AMD StreamSDK v.20 「ベータ」

149 :デフォルトの名無しさん:2009/09/13(日) 10:34:43
1.0すらβな件

αの間違いじゃねーのか?w

150 :デフォルトの名無しさん:2009/09/13(日) 14:21:31
γはまだ〜?

151 :デフォルトの名無しさん:2009/09/13(日) 18:38:32
>>146
OpenCLって単に実行ファイルを一つにできるというだけで
結局各社のCPUなりGPUなりの特性にあったコードを別々に書かなくちゃ性能出ないの?

152 :デフォルトの名無しさん:2009/09/13(日) 22:39:40
うん
CPUでも性能出そうと思ったら、CPUごとに最適化しないと駄目だし、しょうがないんじゃね

153 :,,・´∀`・,,)っ-○○○:2009/09/13(日) 22:44:14
曲がりなりにもC/C++が使えるCellがあんなことになってたりするけど
ハードウェアの特性の違いまでは言語・フレームワークで吸収できるものではありません。
OpenCLの実態も、まあお察し下さい。


154 :,,・´∀`・,,)っ-○○○:2009/09/13(日) 22:47:13
あと、Appleの実装はともかくAppleの力の及ばないWindowsやLinuxまで
NVIDIAとATIのOpenCLコードにバイナリレベルの互換性があるとは限らないぞ
OpenGLが各社独自拡張によってカオスなことになってるようにね。

155 :デフォルトの名無しさん:2009/09/13(日) 22:51:24
OpenCLの互換性はソースレベルだろ。
それも最低限の仕様だけを使ったものなら
どれでも動くというレベル

ハードの特性を取得して、場合わけするなど
OpenGLとほぼ一緒

156 :デフォルトの名無しさん:2009/09/13(日) 23:09:02
それじゃ結局各社が出してるGPGPU環境使ってそれぞれに開発した方が効率よくない・・・?

157 :デフォルトの名無しさん:2009/09/13(日) 23:21:12
それでも同じコードで動くかどうかは重要だよ。
必ずしも全部を最適化する必要なんてないんだし。


158 :デフォルトの名無しさん:2009/09/13(日) 23:57:09
でもカーネルのソース読み込んでオンライン・ビルドってのがなー
この仕様だと製品版でOpenCL対応しましたーって会社でないんじゃないかな??

159 :デフォルトの名無しさん:2009/09/14(月) 10:56:56
とりあえず標準仕様に合わせて書いておけば動くというのは心強いぞ。
現状Intelコンパイラの自動ベクトル化とか糞過ぎるから、今後こういうところで頑張らないと計算分野でGPUに水をあけられる可能性がある。
AMDは…お察し下さい。

160 :デフォルトの名無しさん:2009/09/14(月) 17:57:33
将来のハードの進歩でって投げ技が使えていいんじゃないか?

161 :デフォルトの名無しさん:2009/09/14(月) 21:00:45
>>155
>ハードの特性を取得して、場合わけするなど
そういった特性とか最適化を担っているのがLLVM。

OpenCL→LLVM→

162 :,,・´∀`・,,)っ-○○○:2009/09/14(月) 21:30:32
LLVM(笑)

そりゃそんな物に頼ってるからGPUに対応できないわけだ

LLVMは魔法のソフトじゃない。
未知のアーキテクチャに対応できるのはハードを知り尽くした人間だけだ。
ハード作った人間が対応投げてたら世話無いわ。



163 :デフォルトの名無しさん:2009/09/15(火) 00:12:47
何でもいいからWindowsで動く処理系きてくれー

164 :デフォルトの名無しさん:2009/09/15(火) 00:33:45
何でもいいなら半年ほど前からNVIDIAが出してる

165 :デフォルトの名無しさん:2009/09/15(火) 00:52:23
>>162
> 未知のアーキテクチャに対応できるのはハードを知り尽くした人間だけだ。
> ハード作った人間が対応投げてたら世話無いわ。

あり得ない。コンパイラ技術を知らないアセンブラ人間?

166 :デフォルトの名無しさん:2009/09/15(火) 01:14:34
団子には何言っても主張を曲げないよ
無駄な煽りでスレが荒れるだけ、NG推奨

167 :デフォルトの名無しさん:2009/09/15(火) 01:47:02
両方とも言ってる事がおかしい

168 :デフォルトの名無しさん:2009/09/15(火) 03:56:13
OS X ハッキング! 335 ついに姿を現した「OpenCL」、その実力
http://journal.mycom.co.jp/column/osx/335/index.html

169 :,,・´∀`・,,)っ-○○○:2009/09/16(水) 00:55:52
>>165
コンパイラはどうやってコード吐くんですか?
どの命令とどの命令が並列実行出来るとかって情報は誰が持ってるんですか?

ああ、今時Javaでもx86のJITフレームワーク触れますよ

170 :,,・´∀`・,,)っ-○○○:2009/09/16(水) 01:03:34
オープンソースの力を借りるのはある程度動くものができてからの話よ。
CPUだととんでもなく遅いです、GPUだと動きません、じゃ、話にならないでしょ。
そもそもStream 1.0の正式版を出さないうちに2.0のβ(笑)をでっちあげる神経を疑う。

ハードだけ出してソフト丸投げでは、どっかのCell(笑)と同じじゃないの。
それより更に悪い。

171 :デフォルトの名無しさん:2009/09/16(水) 08:56:27
OpenCLもOSS化されたGrand Central Dispatch(Cへのブロック追加+OSでの対応+LLVM/Clang)も、
LLVM/Clangが鍵になってるけど、これは言語に対する低レベルなVMであって、
別にJavaなんかと同一視してVMだからどうこうと言っても理解できないかも。

因みにNvidiaもOpenCl実装にLLVM/Clangを利用してるし(今後その実装で続くのかは不明)、
GPU非依存化にはこういう仕組みは不可欠じゃね。

172 :デフォルトの名無しさん:2009/09/16(水) 11:02:06
中間コードに落とし込むまではどうでもいいんだよ
実際にターゲットハードウェアで走るコード生成機
GNU開発ツールでいうところのbinutilsみたいなのは
ハードごとに用意しないといけない

それすら満足に作らないまま大風呂敷だけ広げてるから
馬鹿にされるんだって

173 :デフォルトの名無しさん:2009/09/17(木) 01:35:08
はあ?

174 :デフォルトの名無しさん:2009/09/17(木) 01:41:05
はぁ・・・

175 :デフォルトの名無しさん:2009/09/18(金) 00:20:38
はぁ…っ

176 :デフォルトの名無しさん:2009/09/19(土) 00:31:25
物分りが悪すぎるぞ
お前のパソコンでLLVMが動くのはLLVMにx86のコードジェネレータが組み込まれてるからであって
コードジェネレータが用意されてなければ動かしようが無い。

コードジェネレータが用意されて無いなら、0からでもそれを作らないと話にならんのよ。
AMDは用意して無い。
だからGPUで動かない。
当然の話だ。


177 :デフォルトの名無しさん:2009/09/19(土) 00:39:22
してないの?
Q3中にGPU対応バージョン公開
Q4に正式版公開と公言しているのに。

178 :デフォルトの名無しさん:2009/09/19(土) 03:27:54
当然もなにも、当たり前過ぎて。

179 :デフォルトの名無しさん:2009/09/19(土) 09:38:17
この馬鹿は俺らを笑い殺すつもりか?

180 :デフォルトの名無しさん:2009/09/23(水) 08:36:49
つまりベンダーは OpenCL ランタイムが載ったドライバ開発を急げと?

181 :デフォルトの名無しさん:2009/09/24(木) 12:51:14
GPUメーカーに作らせたものなど性能を良く見せるためにCPUが遅くなるように細工してるに決まってるだろ

182 :デフォルトの名無しさん:2009/09/24(木) 17:48:12
細工っていうか手を抜く

183 :デフォルトの名無しさん:2009/09/25(金) 10:43:31
Khronos groupのOpenCL公式フォーラム
http://www.khronos.org/message_boards/viewforum.php?f=28

184 :デフォルトの名無しさん:2009/09/29(火) 21:30:53
OpenCL Download Page
http://developer.nvidia.com/object/opencl-download.htm

185 :デフォルトの名無しさん:2009/09/29(火) 23:02:32
>>184
CUDAより数倍遅いんだけど

186 :デフォルトの名無しさん:2009/09/29(火) 23:03:22
俺に言われてもしらんがな

187 :デフォルトの名無しさん:2009/09/29(火) 23:05:19
と思ったがN-Bodyのパーティクル数が違っただけだった

188 :デフォルトの名無しさん:2009/09/30(水) 01:07:29
SDKぶっこんでみたら、DirectCompute用も入ってた

189 :デフォルトの名無しさん:2009/09/30(水) 06:28:55
今OpenCLに対応してるのはヌビディアだけか

190 :デフォルトの名無しさん:2009/09/30(水) 07:41:20
まあいつも通りの事だ
AMDは毎回ポーズだけ

191 :デフォルトの名無しさん:2009/09/30(水) 12:47:44
openclって標準化されてるとはいうけど
NVIDIAでコンパイルしたバイナリをCPUやATIで動かせるようになるんかな?
それぞれ別々にバイナリを作って配布することになるんかな?

192 :デフォルトの名無しさん:2009/09/30(水) 13:41:09
>>191
デバイス毎に定数を調整するとか実装を調整するとか必要になる希ガス。
なので、仮に一つのバイナリだとしても中身は別物になりそう。

193 :デフォルトの名無しさん:2009/09/30(水) 20:31:44
>>191
だから無理だって

194 :デフォルトの名無しさん:2009/09/30(水) 23:24:46
>>191
バイナリファイルにコンパイルできるのか
ずっとHLSLみたいに実行時コンパイルだと思っていた

195 :デフォルトの名無しさん:2009/10/01(木) 00:23:16
>>194
どうもそうらしい


196 :デフォルトの名無しさん:2009/10/01(木) 01:06:26
バイナリ状態でロードして実行も出来るし、実行環境で実行直前にコンパイルすることもできるよ。

197 :デフォルトの名無しさん:2009/10/01(木) 10:06:41
>>196
そのバイナリってのは中間コードみたいなものなの?
それともハードウェア依存の完全なバイナリなの?

198 :デフォルトの名無しさん:2009/10/01(木) 21:15:46
EarFluid: Experimental QC OpenCL iTunes visualizer
ttp://www.mutantquartz.com/?p=40

199 :デフォルトの名無しさん:2009/10/01(木) 23:39:11
>>197
バイナリはハード依存でしょ。
Nvidiaが内部的に中間コード使ってるらしい?
でも当然AMDと互換性はない。

200 :デフォルトの名無しさん:2009/10/02(金) 10:33:36
CUDAとOpenCL、言語によってパフォーマンスに差は出ますか?


201 :デフォルトの名無しさん:2009/10/02(金) 19:20:28
>>200
現状OpenCLが桁違いに遅い。。。

202 :デフォルトの名無しさん:2009/10/02(金) 21:15:18
>>199
llvmの中間コードを使っているのであれば
ポータブルではない。


203 :デフォルトの名無しさん:2009/10/03(土) 00:38:14
>>200
最終的には同じになる、ってOpenCLプログラミングセミナーでnvidiaの偉い人が言ってた。


204 :デフォルトの名無しさん:2009/10/03(土) 02:31:57
NVIDIAのOpenCLドライバ使ってるんだけど、カーネル実行って同期処理になってない??
キューに入れてから戻るまで時間がかかりすぎで、マルチタスク的な動作が出来ないんですが。。。

>>203曰く、ちゃんと対応されるのかな?
それとも、俺がOpenCLの仕様を読み間違えてるだけ?(汗

205 :デフォルトの名無しさん:2009/10/03(土) 13:40:35
>>198
GeForce9400だと5fpsくらいしか出ないけど面白いね
CPU負荷が全く上がらない

206 :デフォルトの名無しさん:2009/10/06(火) 11:00:59
OpenCLはサザビーでも使えるの?

207 :デフォルトの名無しさん:2009/10/06(火) 11:25:46
エゴだよそれは

208 :デフォルトの名無しさん:2009/10/08(木) 03:02:00
>>204
内部でCUDAを使ってるだけだろうし原理としてはそうなる
基本的に同期処理が原則
だからカーネル実行は細分化してやらないとだめ
画像を処理するなら1行処理する関数をカーネル化してCPU側でループするみたいな
やりかたじゃないとだめ

209 :デフォルトの名無しさん:2009/10/10(土) 03:43:44
SDK 2.3b released
OpenCL Download Page
ttp://developer.nvidia.com/object/opencl-download.html


210 :デフォルトの名無しさん:2009/10/10(土) 06:42:05
そのうちオライリーが一冊本を書くんじゃなかろうか
日本語翻訳版が出るかどうかは知らないけど

211 :デフォルトの名無しさん:2009/10/10(土) 11:48:34
CUDAとATI Stream SDKとOpenCLの関係がいまいち分からんけど、
OpenCLの中のオプションとしてCUDAとかATI Stream SDKとか位置づけされるってことなのかな。

今CUDA用に記述してあるソースコードも、OpenCL用にちょこっと書き換えればAMDのGPUでも、
他のOpenCLに対応したGPGPUでも動作するってこと?

212 :デフォルトの名無しさん:2009/10/11(日) 03:22:25
>>208
いやいや、CUDAの動作はそれであってるのけど、それはOpenCLの仕様違反だろ?
それに画像処理するならカーネルループとかあり得ないし。カーネル実行のオーバーヘッドの事を理解していないとしか思えないな。

213 :デフォルトの名無しさん:2009/10/11(日) 10:06:30
OpenCL Tutorial - Shared Memory Kernel Optimization
http://www.macresearch.org/opencl_episode6
OpenCL Tutorials
http://www.macresearch.org/opencl
OpenCL Programming Guide for Mac OS X
http://developer.apple.com/mac/library/documentation/Performance/Conceptual/OpenCL_MacProgGuide/Introduction/Introduction.html

214 :デフォルトの名無しさん:2009/10/11(日) 18:47:07
>>212
物理的にGPUがマルチタスクに対応してないんだからどうしようもないな
オーバーヘッドも含めてGPU処理の性能の限界が現時点でそうなんだからしょうがない

215 :デフォルトの名無しさん:2009/10/19(月) 21:09:31
>>213
思ったんだけど、もろにNVIDIA寄りの内容だよね

216 :デフォルトの名無しさん:2009/10/19(月) 21:58:59
2009 LLVM Developers' Meeting
http://llvm.org/devmtg/2009-10/
↑OpenCLなどApple社員系の情報が非公開なのは残念だが参考に。

http://llvm.org/docs/ReleaseNotes-2.6.html

217 :デフォルトの名無しさん:2009/10/22(木) 01:41:00
>>211
違う。

C と C++ と Java みたいなモンで3つとも同じように
CPU 上で動くが各言語間でソースコードの互換性は……だろ?

CUDA は like C、ATI Stream は Book+、OpenCL は OpenCL C という別言語になる。
プログラマは自分の開発環境などに合わせた好きな言語が選べるってだけだ。

218 :デフォルトの名無しさん:2009/10/22(木) 12:21:11
新iMacのGPUがRadeonなんだが、OpenCLの対応はどうなの?
SDKあるんだっけ?


219 :デフォルトの名無しさん:2009/10/29(木) 23:09:47
なんか在庫買いあさったらしいからこれから最適化進めてくるんじゃない

220 :デフォルトの名無しさん:2009/10/31(土) 11:17:42
誰かこの前、秋葉原で開催されたOpenCLセミナー行った人いる?
いたら、簡単な感想聞きたいです。

221 :デフォルトの名無しさん:2009/11/01(日) 01:05:25
>>220
いったよ
・nVIDIAの人「Fermiアーキテクチャは凄いぞ!」まぁ凄いけどさ。
・FIXSTARSの人のプログラミング入門は参考になったけどあの内容だけだと即書くのはキツイ。
 最後には「ちゃんとやりたい人向けに終日の有料教室やってるよ!」だったしw
・Appleの話はOpenCLじゃなくて殆どCocoaの話…
・Dellは殆ど営業トーク

内容的にはそんなに深くなかったかなー…って感じ。

222 :デフォルトの名無しさん:2009/11/03(火) 04:42:31
オープンクルとオープングルって何か共通点はあるの?

223 :デフォルトの名無しさん:2009/11/03(火) 08:17:17
釣られないぞとつぶやいたそこのあなた。
既に釣られてますよ。

224 :デフォルトの名無しさん:2009/11/05(木) 12:25:52
OpenCLはCPUのSIMD命令を置き換えられるようなものになるといいな
そのうちCPUにGPUも統合するんだからさ

225 :デフォルトの名無しさん:2009/11/05(木) 19:47:54
バイナリが環境依存なのがなあ。
CUDAみたいに、中間コードがあればいいのに。

226 :デフォルトの名無しさん:2009/11/05(木) 19:57:30
>>220
基本は221の通りだが、フィックスターズの人が1月に本来出すとか言ってた

227 :デフォルトの名無しさん:2009/11/23(月) 18:23:10
ttp://www.alphaworks.ibm.com/tech/opencl

228 :デフォルトの名無しさん:2009/11/23(月) 18:28:39
POWER6とcellもopenCLに対応

229 :デフォルトの名無しさん:2009/11/23(月) 19:06:30
いろいろ対応してくれるのはいいけど、カーネル・ソースが第三者に丸見えなのは何とかならないの?

230 :デフォルトの名無しさん:2009/11/23(月) 23:57:57
暗号化すればいいじゃない

231 :デフォルトの名無しさん:2009/11/24(火) 05:03:17
見られて困るほど複雑なアルゴリズムはカーネルだけじゃ作れないから大丈夫だw

232 :デフォルトの名無しさん:2009/11/27(金) 22:27:11
ATI Streamを落としてきたけどマニュアルないのな。
KronosにはCのはあるけどC++のはないね。
せっかくStreamにC++のサンプルがあって便利そうなのに。

233 :デフォルトの名無しさん:2009/11/27(金) 23:31:48
とりあえず今持ってるコードを

FORTRAN→C→OpenCL C

って感じで進めてみるかなー


234 :デフォルトの名無しさん:2009/11/27(金) 23:35:20
独り言は壁に向かってしてくれ

235 :デフォルトの名無しさん:2009/11/28(土) 17:26:06
(´・ω・`)ショボーン

236 :デフォルトの名無しさん:2009/12/05(土) 23:25:28
最初の世代のLarrabeeは一般には降りてずにHPC専業でいくようだ
たのしみにしてたのに(´・ω・`)

237 :デフォルトの名無しさん:2009/12/13(日) 19:17:07
S3のGPUでOpenCL開発するためのSDKってどこ?

238 :デフォルトの名無しさん:2009/12/17(木) 16:18:02
質問です

OpenCLを使ったプログラムのバイナリはRadeonでもGeForceでも使えますか?

239 :デフォルトの名無しさん:2009/12/17(木) 17:35:20
まずは実際にやる事だ

240 :デフォルトの名無しさん:2009/12/18(金) 00:39:28
ソースでも中間コードでもない、ただのバイナリをなんだと思っているんだ

241 :デフォルトの名無しさん:2009/12/23(水) 20:27:30
フィックスターズから本出るよ
http://www.amazon.co.jp/dp/484432814X

242 :,,・´∀`・,,)っ-○○○:2009/12/23(水) 20:55:25
三木聡しゃちょはんて何処担当してるの?

243 :デフォルトの名無しさん:2009/12/24(木) 20:20:23
>>241
>著者からのコメント
>"The free lunch is over."

そんなこといわれてもな・・・

244 :デフォルトの名無しさん:2009/12/26(土) 01:03:24
>>238
ソースレベルの互換性しかないので、バイナリは非互換。
ただしランタイムにカーネルのソースをコンパイル出来るので、恰もバイナリ互換があるかのようにコーディング出来る。
とはいえ、そうするとCELLみたいに特殊な構造だとパフォーマンスを発揮するようにコードを書くのがたいへんだろうけど。

245 :デフォルトの名無しさん:2009/12/26(土) 13:46:36
Radeonの4650で遊んだ感じでいうとCellのが楽だな

246 :デフォルトの名無しさん:2009/12/28(月) 09:34:55
>>242
そこには触れてやるな。みんなおかしいとは思っているがしゃちょーには逆らえない

247 :デフォルトの名無しさん:2009/12/28(月) 19:37:20
>>245
http://techreport.com/discussions.x/18201

248 :,,・´∀`・,,)っ-○○○:2009/12/30(水) 03:30:14
今年(来年?)はプログラミングコンテスト開かないの?


249 :デフォルトの名無しさん:2010/01/01(金) 10:53:23
うっせー糞して寝ろ

250 :デフォルトの名無しさん:2010/01/05(火) 20:45:23
どっちかっていうと、OpenGL内部のメモリ内容を直接書き換えれるのが大きいな。
描画内容に変更加えて再描画とか、データの高速可視化とか。

個人的にCPUに付加かけずにリアルタイム可視化ができるのがいいな。

251 :デフォルトの名無しさん:2010/01/18(月) 19:22:26
OpenCL並列プログラミングって本が25日に出るみたい。

252 :デフォルトの名無しさん:2010/01/18(月) 22:04:56
しってるしってる、と思ったらフィクスターズのやつとは別か
ソースキボンヌ

253 :デフォルトの名無しさん:2010/01/18(月) 22:14:14
>>252
今日の日経の朝刊1面下の広告

254 :デフォルトの名無しさん:2010/01/18(月) 22:18:22
出版社:カットシステム
著者:池田成樹
http://www.cutt.co.jp

255 :デフォルトの名無しさん:2010/01/18(月) 22:19:55
JAL株5円まで来たか
いよいよ明日はクライマックス

256 :デフォルトの名無しさん:2010/01/18(月) 23:48:45
うっせー糞して寝ろ

257 :デフォルトの名無しさん:2010/01/19(火) 00:15:14
便秘で出ないっす

258 :デフォルトの名無しさん:2010/01/19(火) 20:00:15
ケツに目薬をさすと便秘が治るという噂を聞いたことがある

259 :デフォルトの名無しさん:2010/01/21(木) 15:08:18
最近GPGPUを始めようと調べ始めたのですが、
cudaとCLの違いって、CUDAはCPU部分もカーネル部分も混在したプログラムを書いてnvccが両者を分離してくれる、
CLはプログラマ自身が最初からCPU用とカーネル用とを分けてプログラムを書く
という認識でよいですか。

カーネルとかグローバルメモリとかの概念はほぼ一緒と考えてよいのでしょうか。
CLの方が拡張言語っぽくないのと共通規格な分気持ちがいいですが、カーネルのコンパイルとか引数設定を明示的にしないといけない分どんくさい感じですね。


260 :デフォルトの名無しさん:2010/01/21(木) 15:14:41
OpenCLはまだまともに動かないからCUDAにしとけ

261 :250:2010/01/21(木) 18:20:06
cudaとopenclの決定的な違い?

cudaはGPGPU
openclは計算機資源API
GPUに限らず、CPU,(故)Cell/BE,DSPチップ等の演算装置を汎用的な計算機資源として使うためのAPIがCL
GPUを使うならメモリ概念はCUDAとだいたい同じ。

完全にホストプログラムとカーネルプログラムおよび両者間通信を手作業で作らないといけないどんくささ(?)はあるものの
「メインプログラムはホスト実行で,計算機資源だけ別のハードウェアを使う」設計APIなので自由度はかなり高い

ただOpen○○のくせにMac10.6以外はまともに動く環境が少ないとか
JITコンパイルなので実行するまでソースのバグがわからない上に資料がまだ充実してないとか、
けっこうまだまだ問題も多い。
>>260の言う通り今やるならCUDAが良いと思うぞ。

262 :259:2010/01/21(木) 18:49:08
セルとかララビーとかアムドが本気を出すとか色々可能性があるからCLの方がいいかなと思ってたけど
CUDAの方がいいのかな。
拡張言語ってのが言語仕様的にOpenMPあたりと干渉しそうなのもCLを考えていた要素なんだけど。

263 :デフォルトの名無しさん:2010/01/21(木) 22:57:22
どっちもたいして変わらん どっちもやれ

264 :デフォルトの名無しさん:2010/01/22(金) 18:58:59
OpenMPとOpenCLが干渉?
ホスト管理スケジューリングぐらいじゃねーの?

265 :デフォルトの名無しさん:2010/01/22(金) 23:44:42
radeonでCUDAって出来ないの?

266 :デフォルトの名無しさん:2010/01/23(土) 01:25:03
無理。Stream使え。
でも、技術デモ程度ではなく実用したいならゲフォ使え。

267 :デフォルトの名無しさん:2010/01/23(土) 10:59:33
スレ違い

268 :デフォルトの名無しさん:2010/01/26(火) 01:24:10
ふぃくすたのOpenCL入門買ったぞ、LinuxでSDKについてきたサンプルコードがコンパイルできなくて死んだ
っていうか普通にアルゴリズムの勉強してからやれクズ

269 :デフォルトの名無しさん:2010/01/26(火) 01:27:54
二行目どういう意味?

270 :デフォルトの名無しさん:2010/01/26(火) 05:29:18
268 said s/he was kuzu.

271 :デフォルトの名無しさん:2010/03/10(水) 22:33:57
>>266
GPGPU目的だと、ATI<nVidiaなの?

272 :デフォルトの名無しさん:2010/03/10(水) 22:52:32


273 :デフォルトの名無しさん:2010/03/11(木) 20:16:16
CUDA(nVIDIA)/Stream(AMD) = GPGPU環境
OpenCL = 計算資源利用API ≠ GPGPU

GPGPUのみのなら別スレへ。
とりあえずOpenCL<CUDA(nVIDIA)/Stream(AMD)
かつ開発環境の整備具や資料面ではGPGPUでもnVIDIAに軍配が上がるのが一般論

274 :デフォルトの名無しさん:2010/03/12(金) 01:13:55
CUDAを使った実績はかなりあるけど、
OpenCLをつかってパフォーマンスが上がるって結果はあるのか?


275 :デフォルトの名無しさん:2010/03/12(金) 13:56:03
FLOPSのベンチとか調べればちらほら(程度は)ある。ただFLOPSが高くても転送コストが重かったりする。
実行結果をそのままOpenGLとかで可視化するとか転送コストを挟まない場合には向いてる。レイトレとか。
ただ開発/デバグにかかる時間と労力はCUDAと比較にならないと思うぐらい悪い。慣れれば別。

俺はOpenCL好きだけどね。

276 :デフォルトの名無しさん:2010/03/13(土) 13:19:47
昔の超不安定なRadeonのせいでRadeonを買うことにトラウマがあるから
GPGPUもGeForceしかしたくない

277 :デフォルトの名無しさん:2010/03/13(土) 21:40:13
いまノートPCでRadeonHD3200
OpenCL使ってみたいけど、使える環境にするにはPC一式を新しく買うしかないよね?orz

278 :デフォルトの名無しさん:2010/03/13(土) 22:12:04
ATIStream版OpenCLのCPUデバイスで我慢すれば

279 :デフォルトの名無しさん:2010/03/14(日) 04:36:42
ATI、各GPUのドライバまで手が廻らな過ぎ。

280 :デフォルトの名無しさん:2010/03/14(日) 10:20:38
正直どこのベンダもOpenCLにそんなに力入れてない気がしてきた。。。

281 :デフォルトの名無しさん:2010/03/14(日) 12:58:43
いつまでnVidiaに夢見てんだよ

282 :デフォルトの名無しさん:2010/03/14(日) 15:29:40
GeForce GT 240 でOpenCL SDK V2.3のサンプルが動かない。
というかSDKでビルドは成功するが全然動かない。
ドラバは最新の 196.21
GPU-Z.0.3.9で確認するとOpenCLはチェックが入っている。


283 :デフォルトの名無しさん:2010/03/14(日) 15:41:44
現状CUDAで十分な気がする

284 :デフォルトの名無しさん:2010/03/14(日) 18:08:04
CUDAもOpenCLもこのまま消えそうだね

285 :デフォルトの名無しさん:2010/03/14(日) 21:15:50
ほかで何が残りそうなの

286 :デフォルトの名無しさん:2010/03/14(日) 23:21:11
調べてないけど、OpenGL 4は、OpenCLと連携するようになってるらしいから
徐々にOpenCLも使われるようになっていくんじゃない

287 :デフォルトの名無しさん:2010/03/15(月) 18:48:08
POWERVR SGX545を採用したモバイル機器での普及の方が先かも知れない。

288 :デフォルトの名無しさん:2010/03/15(月) 20:09:26
>>286
既にOpenGLと連携できるよ。頂点バッファとかテクスチャとかだからGL2.x以降とかな?

289 :デフォルトの名無しさん:2010/03/18(木) 17:36:26
NVIDIAのOpenCLのダウンロードから一通りダウンロードしてきたけど、
コンパイルとかは、どのコマンドを使うの?
OSはLinuxです。

290 :デフォルトの名無しさん:2010/03/18(木) 19:40:13
何のコンパイル?

291 :デフォルトの名無しさん:2010/03/20(土) 03:12:14
>>290
OpenCL file

292 :デフォルトの名無しさん:2010/03/20(土) 05:50:48
nvcc

293 :290:2010/03/20(土) 08:02:27
fileてのが何かよくわからんが
NVIDIAサンプルに含まれるホスト側のCソースなら/OpenCL/makeでいけるかと。
カーネル用のCLソースならclBuildProgram()関数でどうぞ。

294 :デフォルトの名無しさん:2010/03/20(土) 17:29:53
CUDA 3.0 Downloads
http://developer.nvidia.com/object/cuda_3_0_downloads.html


295 :デフォルトの名無しさん:2010/03/20(土) 18:17:46
Mac OS X 10.6を手に入れたんだけど、OpenCLの使い方を教えてください
とりあえず、ドライバだけは入れました。

296 :デフォルトの名無しさん:2010/03/20(土) 19:11:03
ソース書く→コンパイル→実行→happy

297 :デフォルトの名無しさん:2010/03/20(土) 20:03:11
>>295
ttp://developer.apple.com/

298 :デフォルトの名無しさん:2010/03/20(土) 20:08:14
あと
ttp://developer.apple.com/mac/library/navigation/index.html?section=Resource+Types&topic=Sample+Code#section=Frameworks&topic=OpenCL

299 :デフォルトの名無しさん:2010/03/21(日) 13:14:54
LinuxでOpenCLやってるんだけど、倍精度は使えへんの?

300 :デフォルトの名無しさん:2010/03/21(日) 14:28:18
282だけど
CUDA 3.0 Downloads
で上手くいきました。
ありがとう。>294


301 :デフォルトの名無しさん:2010/03/22(月) 12:45:47
Linuxと倍精度になんの関係が

302 :デフォルトの名無しさん:2010/03/22(月) 13:16:38
CL C言語での倍精度浮動小数点はGPUベンダーにより任意サポート

303 :デフォルトの名無しさん:2010/03/26(金) 00:59:44
よくわからんけど、倍精度を有効にするスイッチとかあるの?
CUDAだとsm13だけど

304 :デフォルトの名無しさん:2010/03/26(金) 08:06:27
>>303

あるよ

対応しているかは実装依存だけど。

http://www.khronos.org/opencl/sdk/1.0/docs/man/xhtml/cl_khr_fp64.html

305 :デフォルトの名無しさん:2010/04/01(木) 22:53:00
struct {
int I;
} tA;

struct {
tA * pa;
} tB;

__kernel void Func (__global tB *b) {
int idx = get_global_id(0);

int B = b[idx].a->I;
}

みたいにすると、int B に値が入らないのってなんで?
書き方が悪いのかな?

教えてエロい人。

306 :デフォルトの名無しさん:2010/04/02(金) 00:52:35
>>305
君にOpenCLは向いてないよ。。。

ちなみに
b[idx].pa の参照先が不定もしくは管理領域外だと思われ

通常であればアクセス例外

307 :デフォルトの名無しさん:2010/04/02(金) 01:07:15
これはコンパイル通るのか?

308 :デフォルトの名無しさん:2010/04/02(金) 02:12:02
tAの実体はいずこ?
tBのメンバpaはポインタだぞ。
ポインタは実体ではないぞ。
やるなら、

__kernel void Func (__global tB *b) {
int idx = get_global_id(0);
tA C;
C.I = 1;
b[idx].pa = (tA *)(&C);
int B = b[idx].pa->C;
}

じゃないか?
OpenCLより、ポインタを先に勉強した方がいいぞ。

309 :デフォルトの名無しさん:2010/04/02(金) 02:33:18
>>308
あ、間違えた。
int B = b[idx].pa.I;
だった。
そもそも根本的におかしいね。
悪い、俺もポインタの勉強が必要だわ。
それ以前に構造体の勉強が必要だ。


310 :デフォルトの名無しさん:2010/04/02(金) 08:10:34
305だけど、306の話で知りたいことはわかった。
変な質問でごめんね。みんなありがとう。



311 :デフォルトの名無しさん:2010/04/23(金) 01:47:27
ラデですまんが、vista64でATI Stream 2.01にしたらopen CLのサンプルがVC++ Expressでコンパイルできても動かない(clGetPlatformIDsが-1001を返す)んだけど、こんなことなた人います?
2.0bだと動いたのだが。
Platform SDKの64bitコンパイラを使えばちゃんとサンプルも動かせるけど、MS流儀のコンパイルオプションやmakefileの書式が面倒くさい・・・
LinuxのCUDA機を購入する前にPCでOpen CLのお勉強をしようと思ったのにつまらんところで時間をくってしまった。

312 :デフォルトの名無しさん:2010/04/23(金) 11:34:25
SDKサンプルのoclBandWidthTestやったらホスト・デバイス間で5300MB/sくらいだったんだけど
この数値ってグラボだけじゃなくマザーとメインメモリも影響するよね?
GPGPUの処理がハードウェア的にどう依存してるのか良くイメージ出来てないんだけど
i7のQPIとかは影響するの?

313 :デフォルトの名無しさん:2010/04/23(金) 12:28:21
>>311
http://developer.amd.com/support/KnowledgeBase/Lists/KnowledgeBase/DispForm.aspx?ID=71

314 :デフォルトの名無しさん:2010/04/24(土) 00:44:55
>>313
そこを読んだけど、それにはデフォルトを呼び出すんじゃなくてclGetPlatformIDsを呼び出してセレクトしろってことでしょ。
で、2.01の64bit版にはちゃんと32bit版のOpenCL.dllが入っているのに、32bitでコンパイルしたらclGetPlatformIDsがなにやら不明なエラーを返してしまうことが問題で・・・

315 :デフォルトの名無しさん:2010/04/24(土) 01:01:40
SDKを削除>再インストールしてみたらどう?
こんな話があるし↓

ttp://absolutearea.blogspot.com/2010/04/opencl-ati-stream-sdk_05.html

316 :デフォルトの名無しさん:2010/04/24(土) 01:06:52
>>315
それはビルドができないってことでしょ。
ビルドはできるんだよねぇ。実行もできる。ただOpenCLの関数が怪しい物を返すので。
OpenCL.dllの日付は32bit版と64bit版も同じだからバージョン違いが残ってるわけでもないしなぁ。

317 :デフォルトの名無しさん:2010/04/24(土) 03:20:56
>>316
中身読んでくれてないのね…
この人も-1001 返ってるって書いてあるし、
貴方とおんなじかなって思ったんだけど

> 「デバッグ」メニューから「デバッグなしで開始」を選択
> HelloCL!
> Getting Platform Information
> Platform::get() failed (-1001)
> 続行するには何かキーを押してください . . .
> ありゃ?なんでじゃ?
>
> ATI Stream SDK をインストーラでリペアしてもだめだった。
> しかたがないので、ATI Stream SDK をアンインストール後、再びインストールした。
> サンプルをコンパイルして動作確認。うまくいった。

318 :デフォルトの名無しさん:2010/04/24(土) 03:37:42
>>317
あら、本当だ。
ごめんなさい。
ダラダラとビルドできないことが書いてあったからこれはちゃうなと。
-1001なら同じだわ。

319 :デフォルトの名無しさん:2010/04/24(土) 10:55:01
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

320 :デフォルトの名無しさん:2010/04/24(土) 15:07:22
そんなwwwとか書くなよ・・・実際のところ既にアンインストール後再インストールは試してるしなぁ。

321 :デフォルトの名無しさん:2010/04/24(土) 17:53:49
なんで出されたもの読まずにコメント出来るのか理解不能ではある

322 :デフォルトの名無しさん:2010/04/25(日) 01:04:34
>>320
後だし情報で言い訳wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

323 :デフォルトの名無しさん:2010/05/09(日) 03:00:01
>>321
出されたものを読まないでコメントするようだから
結局解決まで時間がかかる人なんだよ。理解できる。

324 :デフォルトの名無しさん:2010/05/09(日) 09:39:11
ヤギだからじゃないのか?

325 :デフォルトの名無しさん:2010/05/14(金) 23:31:43
GF9400 (CUDA 3.0)のマシンとHD4850 (ATI Stream 2.1)のマシン両方で起こっているのだけれど、
clEnqueueNDRangeKernelで実行したカーネルのイベントがclGetEventInfoで状態を見るとCL_QUEUEDのまま変わりません(queueはインオーダー実行にしてあります)。
kernel自体はきちんと実行終了して希望の結果が得られて、clEnqueueWaitForEventsにイベントを入れて待ってもきちんとCL_SUCCESSで戻ってくるのに、そのイベントの状態を見るとCL_QUEUEDのまま。
そのために、clGetEventProfilingInfoでカーネルの実行時間を調べようとしてもCL_PROFILING_INFO_NOT_AVAILABLEが返ってきて調べられない始末(CL_COMPLETEになっていない証拠)。
clEnqueueWriteBufferなどのイベントはちゃんとCL_COMPLETEになっている。

なんか再現する簡単なプログラムを付けたいけれど、OpenCLはカーネル動く例を書こうとしてもオマジナイが多すぎて改行多すぎで載せられないし・・・

・kernelは正しく実行されている
・WaitForEventも正しく戻る
・でもイベントはqueuedのまま


326 :デフォルトの名無しさん:2010/05/14(金) 23:59:03
うpろだに上げればよかろうよ

327 :デフォルトの名無しさん:2010/05/16(日) 13:46:46
並列処理の基本であるキューにためつつキューの中身を取り出して処理するみたいなことは出来るの?

328 :デフォルトの名無しさん:2010/05/16(日) 21:32:19
えっ

329 :デフォルトの名無しさん:2010/05/16(日) 22:10:17
そのためのキューです

330 :デフォルトの名無しさん:2010/05/17(月) 00:17:50
キューはCPU側で実装すればいいのか


331 :325:2010/05/17(月) 10:55:56
clEnqueueWaitForEventなんか使ってちゃダメだな。
clWaitForEventで待機したらeventがCL_COMPLETEになりました。

queueのインオーダーだと勝手にブロッキングになると勘違いしていてwaitなんて入れても入れんでも一緒ダロとか思ってました。

ところで、アウトオブオーダーの時にclEnqueueWaitForEventなんか使ったらqueue内の順序無視してwaitを先にやっちゃって止まるなんてことにはならんのだろうか・・・

332 :デフォルトの名無しさん:2010/05/17(月) 23:56:26
windowsのリモートデスクトップ経由でOpenCLのプログラムを実行するとplatformの取得に失敗するのな。
びっくりした。windows使えねぇw

333 :デフォルトの名無しさん:2010/05/18(火) 00:18:59
それはNVIDIAのドライバのせいでは?
ATIのOpenCLでもそうなる?

334 :デフォルトの名無しさん:2010/05/18(火) 00:39:34
そうなる。Windowsの仕様。
公式でもVNC使えって言ってる。
ttp://developer.amd.com/gpu_assets/App_Note-Running_ATI_Stream_Apps_Remotely.pdf

335 :デフォルトの名無しさん:2010/05/18(火) 05:11:24
NVIDIAのドライバのせいだなw

336 :デフォルトの名無しさん:2010/05/18(火) 09:44:11
VNCは遅い上にリモートの画面のロックは解除されたりキーボードやマウスでいじり放題になるので目の届かないコンピュータをいじるもんじゃないわな。
迂闊にエロサイトなんて見てしまったら・・・

337 :デフォルトの名無しさん:2010/05/18(火) 10:36:11
cygwinでsshdを起動してssh経由でやっても動かないぜ。
mpiでやっても当然ダメなんだろうな。
こんな状態でHPC市場を狙ってるんですかねマクソさんは。

338 :デフォルトの名無しさん:2010/05/19(水) 13:04:33
スクリーンセーバーにしてしまおうかと真剣に考えたw

339 :デフォルトの名無しさん:2010/05/20(木) 22:39:47
個人的な覚書

ATI Stream 2.1のcl_platform.hはこのままだとmingw-gccで使えない。
38行目の#include <stdint.h>を削除して
77行目 #else /* !_WIN32*/の次の行に入れる必要あり。

khrnosの配っているcl.hpp (\date $Date: 2010-04-23 10:16:50 -0500 (Fri, 23 Apr 2010) $は
namespace cl のなかでstd::pairと呼び出してる箇所を全て ::std::pairと修正、
#if defined(__CL_ENABVLE_EXCEPTIONS)
#include <exception>
#endif
をnamespace clの外側に移動する必要あり。


340 :デフォルトの名無しさん:2010/06/03(木) 07:06:02
ワープって何よ。
亜空間跳躍となにか関係あるのか?


341 :デフォルトの名無しさん:2010/06/03(木) 23:01:30
OpenCLはワープサイズやウェイブフロントサイズをとってこれないのが難点だな。
これが取れないとポータビリティのある最適化はできないよ〜。

342 :デフォルトの名無しさん:2010/06/04(金) 13:26:57
ワープとかの概念が無用なプラットフォームも OpenCL の対象範囲。
どうせハードウェアごとの最適化が入る部分は、CL がどうこうする部分じゃないよ。
その辺は #ifdef で。

343 :デフォルトの名無しさん:2010/06/04(金) 22:55:03
ワープサイズに依存しない機種の場合はワープサイズ1でも返してくれればいいんだけど。

344 :デフォルトの名無しさん:2010/07/01(木) 23:02:44
コードのコンパイル、デバイスの生成、データ転送に喰われてスケールしないんだが。
ありがた味のわかるサンプル教えてくれ。

345 :デフォルトの名無しさん:2010/07/01(木) 23:05:51
コンパイルやデバイスの生成やデータ転送と比べものにならないくらい長時間のデータを計算させる。


346 :デフォルトの名無しさん:2010/07/03(土) 00:48:14
openclでGPGPUするかどうかの判定ラインって何?
やってみないとわからんのか。

347 :デフォルトの名無しさん:2010/07/03(土) 12:42:13
計算量がNの3乗くらいなら有効だと思うよ。
ループが3重にネストしているような奴。

348 :デフォルトの名無しさん:2010/07/24(土) 22:38:24
水を差すようだけど,OpenCLだからと言ってO(N^3)がO(N^2)に落ちる訳ではないんだから
それだけでは何の基準にもならないよね.
滅茶重い計算だとNも単純に大きくてデバイスローカルなメモリに収まらなかったりするし
対象デバイスのwarp sizeを想定しながらブロック化とか,結局ifdef祭り.

349 :デフォルトの名無しさん:2010/07/24(土) 23:00:12
うるせえだまってろ

350 :デフォルトの名無しさん:2010/07/25(日) 08:00:33
でっていう

70 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)