OpenCLプログラミング#1

■ このスレッドは過去ログ倉庫に格納されています
1a36 ◆K0BqlCB3.k
垢版 |
2008/12/10(水) 15:38:25
さてついにOpenCLの仕様が公開されました。

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

公式ページにはAPIのヘッダファイルが公開されており、
まだ実際に動かす事はできないもののプログラミングすることは可能となっています。
ということで、公開に先んじてプログラミングを始めてしまいましょう。
2008/12/13(土) 06:17:58
>>24
ありうるけど、まだ高価すぎる。
PIC や DSP なみにコモディティ化したら、みんなが使うだろう。
組み込みにとっては、CUDA か CL かというのは、次かその次の世代の話だろう。

ま、現場はアレもコレも知っとかないとねｗ
2008/12/13(土) 08:55:49
これれは今出てるiPhoneでも使えるのかね
2008/12/13(土) 10:14:46
>>26
ARMはSIMDらしいよな。
Appleがやってくれるかもしれん。
2008/12/15(月) 02:44:31
DsPICってのも有るし、しかも最近clockがどんどん上がってる。
このPICに載ってるDSPの数が増えたら8bitのGPGPUって感じじゃね?
2008/12/15(月) 09:32:57
dsPIC m9（＾Д＾）ﾌﾟｷﾞｬｰｰｰｯ
2008/12/17(水) 03:23:32
なんでこのスレでdsPICの名前が
CLで叩く意味はちょっと見出せないw
2008/12/18(木) 03:06:23
これは楽しみだわ
2008/12/22(月) 21:22:09
spec読んだけどcudaに毛が生えたようなもんだね
メモリ階層もモデル化したと言うけど、ほぼ現行のGPUが前提。
興味なくなった。
2008/12/22(月) 21:51:48
1.0だからな・・・
Intel VTと同じで2.0からが本気なんだよｗｗｗ
2008/12/23(火) 14:09:23
Open CLって結局なんなんだよ
2008/12/23(火) 19:27:26
http://journal.mycom.co.jp/column/osx/305/index.html
2009/02/15(日) 19:12:01
2009年，本格始動するGPGPUの世界・後編〜GPGPUのプラットフォーム動向
http://www.4gamer.net/games/076/G007660/20090206031/
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とは似て非なるものだといえる。
2009/02/15(日) 20:17:07
>>37
大丈夫、DSPがOpenCLに対応する可能性は限りなく低いから。
まして、x86プロセッサでOpenCL対応するくらいならCt使う方が遥かにまし。
2009/02/15(日) 22:24:19
つーかOpenCLってとりあえずMac用でしょ
40デフォルトの名無しさん
垢版 |
2009/02/15(日) 22:27:21
なんで？
2009/02/15(日) 22:30:45
OpenCLの規格化作業を猛烈に推し進めたのがアップルだから
2009/02/15(日) 22:42:22
だからMac用？
どうして？
2009/02/15(日) 22:42:47
>>38
なんか理解できてないようだけど、
こいつの価値は並列処理にあると思う。
要するに今までのGPGPUは、GPUによる高速化
というのがメインだったけど、OpenCLの場合は、
CPUとGPUで並列処理が可能になる。

元々はAppleとNVIDIAが協力して、CUDAを基礎に
した（と思われる）ものを、さらに標準化の過程で
より汎用性を重視して、GPUに依存しないよう設計
にしたものがOpenCL。
2009/02/15(日) 22:48:46
>>42
大丈夫、Mac専用じゃないよ。
Appleが規格の孤立化を避けるのが目的だと思うけど、
最初からオープン標準化にこだわって作られた規格。

規格の策定作業のメンバーにはIntelやAMD、NVIDIA、
ソニーなど、MSを除く主要企業は全て参加しているし、
OpenGL（ES）との連携やスマートフォンへの対応もあるし、
これから先、携帯端末全盛の時代の最有力候補でもある。
2009/02/15(日) 22:50:10
>>44
あんたに聞いてないんだよ
2009/02/15(日) 23:06:31
>>45
あうごめんｗでも答えちゃうよ？

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

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

もちろんマルチプラットフォーム化を重視して、Windows環境下でも
OpenCLを採用する企業も当然存在するとは思うけど。
2009/02/15(日) 23:13:48
>>46
お前の意見なんてどうでもいい
マジで黙ってろクソ野郎
2009/02/15(日) 23:18:30
>>47
あうごめんｗでも答えちゃったよ？
2009/02/16(月) 18:57:22
で、まだかね？
2009/02/17(火) 11:40:11
マルチコア動作版くらいそろそろ出せよ　ｶﾞｵｰ
2009/02/17(火) 11:44:25
てかDirectXは独自に実装するみたいだが
MSは意地でも標準化を妨害したいらしいｗ
2009/02/17(火) 12:35:14
妨害つーか、OpenCLはOpenGLとは連携するが
Direct3Dとは連携しないので、MSが自前で作るしかない。
2009/02/21(土) 19:01:40
MSはどっちかっていうとマルチCore CPUをグラフィックに活かそうとしているよね。
逆。
2009/02/21(土) 19:03:43
>>52
MSはCompute Shaderを準備中。
2009/02/26(木) 00:45:30
言語はC99ベースだからいいかと思ったけど、再帰が使えないのは痛いな。
Cで書いてコンパイルしたバイナリと、OpenCLで書いてコンパイルしたバイナリを
リンクできればいいな。

2009/02/26(木) 11:20:43
.objが中間コード的なものだったら出来たかもね。
2009/02/28(土) 03:39:12
再帰なんていらね
2009/04/02(木) 08:17:35
並列化しやすい問題で結構使うぞ、再帰探索は
こっち方面はIntelに期待するしかないかもね
2009/04/02(木) 23:41:47
時間とメモリの使用量が不定になるからねぇ。
OpenCLの主戦場を考えるとどうなんでしょうか。
2009/04/03(金) 01:52:09
再帰するようなアルゴリズムの場合、命令ポインタの動きに一意性がないし
決してデータレベル並列ではないんだよな。
SIMDでは命令ポインタが要素ごとに独立、というわけにはいかない。
プレディケートをやるのは逆に言うと自由に分岐ができないことの現れだし。
2009/04/11(土) 13:13:33
ほしゅ
2009/05/03(日) 23:04:11
まだ？
2009/06/14(日) 18:31:47
>>55
残念だが OpenCL C は Java や .NET のような中間コードで
OS 上のドライバがリアルタイム翻訳するからリンクは無理。

だが OpenCL を利用する本体は何でもいいから
C や C++、Objective-C なんかで再帰検索すればいい。
64デフォルトの名無しさん
垢版 |
2009/06/20(土) 18:47:32
企画書ってどこで読めるの？
2009/06/20(土) 20:41:46
>>64
OpenCL 1.0 仕様書
ttp://www.khronos.org/registry/cl/specs/opencl-1.0.43.pdf
2009/06/21(日) 04:07:00
Appleが用意したOpenCLの技術解説のpdfのリンク貼っとく
http://images.apple.com/macosx/technology/docs/OpenCL_TB_brief_20090608.pdf
2009/06/29(月) 13:32:04
OpenCLのCPU動作版って公式で作るのか？
それとも誰か作ってる人が居る？
2009/06/30(火) 20:18:36
Intel か Apple が CPU 用 OpenCL ドライバを作成すれば問題ない。

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

個人で Java VM や GPU Direct3D/OpenGL ドライバを
作ってしまえる人が興味を持ってくれたら話は別だけど。
2009/06/30(火) 20:23:54
スノレパにはCPU用ドライバが付いてくるでしょ

GPUよりも数十倍から100倍以上は処理が遅いCPUで
Open CLを動かす価値が有るかはわからないけれど
2009/06/30(火) 20:34:15
>GPUよりも数十倍から100倍以上は処理が遅いCPU
という夢を見ている
2009/06/30(火) 20:46:55
Core 2 Quad QX9775： 102.4 GFLOPS
Radeon HD4870：1.2 TFLOPS（1200 GFLOPS）

一桁余分だな。
2009/06/30(火) 23:19:38
このスレで言うのもなんだが並列処理って知ってる？
2009/07/01(水) 00:44:41
CPU と GPU を並列に走らせて 10 が 11 になるよりも、
その１をUIやGPUが苦手な処理を与えたほうがいいんじゃね？

マルチタスク（プロセス）的にも CPU は空けておきたいかも
2009/07/01(水) 02:58:17
CPUよりGPUのが早いってことになってるけど
それは実は大嘘でちゃんとマルチコアで作りこんだらスピードは大差ない
GPUメーカー製のドライバはCPUでも動くような振りだけは実装するだろうけど
絶対にまともな実装はしない、ばれるから
だからちゃんとしたCPUメーカーか第三者が作ったものが必要
2009/07/01(水) 03:05:43
>>71
それは理論的な演算速度だけだとそうだけど
メインメモリからデータを取り出して結果を戻すのに要する時間で計算すると
遥かにCPUの方が早い
2009/07/01(水) 06:44:02
結局ワークロード次第なのだがGPUが明らかに速い分野なんて非常に限定的で馬鹿にされまくっているのが実情
GPGPUは過去のEPICと被るな
2009/07/01(水) 11:17:39
>>74
なんでGPUメーカーがCPU用ドライバを作るんだよ。
DirectXですらCPU用ドライバはＭＳが作ってるんだぜ？

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

結局プログラマがどれだけ局所化を行えるかだろうね
2009/07/01(水) 14:42:50
>>77
３Dは転送する情報量は頂点座標だけなんだからCPUより早いのは当たり前でしょ
CPUのネックはメモリ転送速度だって言ってるでしょ
大量のデータを計算するような用途ではどんな工夫をしようがCPUには勝てない
2009/07/01(水) 14:45:50
しかも分散処理する部分は複雑に作りこんでないから
計算してる間は描画が止まるからな
計算してる間は文句なしに画面描画が止まる
CPUだと計算負荷に応じて外も動くけど
2009/07/01(水) 14:51:59
>>78
だからそのCPUでは勝てない分野でGPUを有効活用しようっていうのがGPGPUでしょ

映像のエンコードしかり、ゲノムの解析しかり超大量のデータ処理を肩代わりしたり、
またはAIなどの人工知能やMSのProject Natalみたいなものを実現するため、とか
2009/07/01(水) 14:57:20
>>79
だからGPUの仮想化とかマルチタスク処理とかがあるんでしょう

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

GPUでは小回りが利かない部分を管理するのがCPUの得意分野
2009/07/01(水) 17:58:11
>>80
だから今の構造だとCPUでは勝てない分野が３Dポリゴンの描画しかないのｗ
2009/07/01(水) 17:59:09
>>81
>>GPUでは小回りが利かない部分を管理するのがCPUの得意分野

現状と何も変わらない
2009/07/01(水) 18:03:26
本来ならGPUの機能はCPU内部にあるべきだが、
IBMやINTELはサーバとか大規模計算方面ばかり気にして3Dとかグラフィックとかを軽視していたから、
見るに見かねた人がGPUなんてものを作ったんだよね。
2009/07/01(水) 18:04:59
GPUって、本質的に見たらやってることはCPUと変わらないのに、
CPUとバスを経由して通信している分無駄があるんだよね。
だから将来的にGPUはCPUに飲み込まれるのが健全だと思うね。
2009/07/01(水) 18:11:33
行列積とか倍精度でもGPUの方が速いだろ。
2009/07/01(水) 18:23:10
>>86
そういう処理をするCPUの命令の一つにしてしまえば良い。
2009/07/01(水) 18:44:55
>>86
だから計算対象のデータをGPU側に引き渡してる間にCPUで計算出来るっつー話だわな
2009/07/01(水) 18:47:34
>>88
いや、まぁ実際にそういうことが多いわけだけど、俺が言いたいのそうじゃなくて、
GPUをCPUに統合するのが健全だと言っているだけであって・・
夢見がちな俺の願望でしかないわけだが。
2009/07/01(水) 21:55:32
>>89
今その方向に向かっているな。
AMDそのためにATIを買ったんだし、GPU専業のNvidiaは焦っている。
2009/07/01(水) 22:00:36
ハードだけ買ってもOpenCLはじめソフトがｇｄｇｄ
このままだとIntel最強ってゆー何時もの結論で終了する
2009/07/02(木) 01:07:12
マカーとして言わせてもらえばQuickTimeとAdobe CSくらいが対応してくれれば対応アプリとしては十分な気がするんだよな
OpenCLが一番活用できそうなのって結局画像動画関連だし
それにCoreImageやCoreVideoがCPUでも動いたようにOpenCLもCPU上で動かせるから未来がどっちに転んでも技術としては問題ないと思う
2009/07/02(木) 01:20:12
夜のお供に漫画ビューアにもな。
2009/07/02(木) 10:11:18
画像ビューアはCPUで処理したほうが速いだろ

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

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

>>92
Adobe CS4 はすでに CUDA や ATI Stream に対応しているから
下位互換でしかない OpenCL に対応する意味は余り無い。
2009/07/02(木) 12:51:12
DCのデモでも、CPUより早く動かすの苦労してたよ。
データ数が半端無く多くないとCPUを上回れない。
96デフォルトの名無しさん
垢版 |
2009/07/02(木) 12:56:37
茸の左をひょいひょい躱した粟生と
リナレスの鬼速ジャブ…

この対決は興味深いぜ
2009/07/02(木) 16:12:28
CPUとは別に画像処理などに有用なコプロセッサが１つ
PCやMacで眠っているからそれも使おうって方向でいい。
2009/07/02(木) 19:12:15
昔はコプロって別売りだったな。
2009/07/02(木) 20:12:40
GPUの得意分野は浮動小数点数のベクタ演算だからなおさらコプロちっく
2009/07/02(木) 20:52:46
Larrabeeって次世代の8087って位置づけなんだろうな
2009/07/03(金) 02:14:02
数年後にはCPUに統合されるのがわかりきっているけどな
2009/07/03(金) 02:15:26
そのさらに数年後には独立されるだろう
2009/07/03(金) 02:58:35
CPUだけじゃ最先端3Dレンダリングを処理しきれないｗって理由で、か
2009/07/03(金) 04:19:19
画期的なメモリバス技術でも開発されれば統合プロセッサのまま進化を続けるんじゃないかな
2009/07/03(金) 06:38:34
ワイドテレビでこんなに広く！→縦が伸びてこんなに広く！→ワイドになって（ｒｙ
2009/07/03(金) 22:50:21
CPUはある意味CELLの行く道が正しかったのか？
2009/07/03(金) 22:56:22
>>105
ますます家が狭くなるがな
2009/07/04(土) 15:37:52
OpenCL自体は普通にマルチスレッドのフレームワークに使えるから期待してるんだけど
出来ればクラスタリングとかにも対応して欲しいが
2009/07/04(土) 17:43:55
OpenCL って Direct3D のシェーダ言語同様にドライバによる
インタプリタだと認識しているけど並列計算のフレームワークとして使えるの？

OpenMP や Grand Central Dispatch じゃダメなのだろうか
2009/07/04(土) 18:47:02
演算シェーダ相当の抽象化レイヤと考えて問題ないよ
汎用的な並列計算はOpenMPやGCDの方が適切。そのままマルチコアCPUをターゲットにした方がいい
OpenCL適用できる分野は「並列計算」の中のさらに「GPUに適した」特殊なアルゴリズム分野になる
とにかくデータを小さなブロックに小分けして、延々と同じ処理繰り返すようなの
2009/07/04(土) 19:29:33
標準化されてることに意味がある
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なども加盟している。

2009/08/07(金) 13:07:44
やっと動きが
2009/08/08(土) 11:10:40
これRADONには対応しとらんのん？
2009/08/08(土) 11:13:29
ラドン…だと？新手の北朝鮮ミサイルか？
2009/08/08(土) 12:03:20
恐竜だろ
2009/08/08(土) 15:02:36
風呂かとおもった
2009/08/08(土) 19:53:25
サンプル動かしてもGPU全然関係ないな(´・ω・｀)
ATI StreamなのになんでCPUだけなんだよ
2009/08/08(土) 22:02:49
AMDの対応がまだなんじゃね。
2009/08/08(土) 23:16:43
ていうか Radeon の OpenCL ランタイムドライバが出来ていないとか？
2009/08/11(火) 09:48:44
CPU対応は優先度が一番高いんだろう
GPUはチップ毎に対応しないといけないし

CPUとGPUの比較をしたり両方使って同時処理するのにも必要
2009/08/15(土) 07:49:11
俺予想
OpenCLが動くということはnVidiaと同じ土俵でパフォーマンスが比較できるようになる。
現行のRADEONだとOpenCLでパフォーマンスが出ない。
nVidiaと比較されるのがいやなので今はドライバを出さずに
次のGPU(OpenCL向け機能拡張入り)を出すタイミングでドライバを出す。
2009/08/15(土) 19:05:49
>>122
萩原Obj-C(1.0のやつ)をみながらやっているもので。
Tiger使っているので2.0へはまだいけない。
2009/08/15(土) 19:07:04
ごめん間違えた。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況