- 1 名前：a36 ◆K0BqlCB3.k [2008/12/10(水) 15:38:25 ]
- さてついにOpenCLの仕様が公開されました。
www.khronos.org/opencl/
公式ページにはAPIのヘッダファイルが公開されており、
まだ実際に動かす事はできないもののプログラミングすることは可能となっています。
ということで、公開に先んじてプログラミングを始めてしまいましょう。
- 24 名前：デフォルトの名無しさん mailto:sage [2008/12/12(金) 21:58:03 ]
- 組み込み関連の所が多いって所にやっぱメディア系の家電とかへの需要が期待されてるのかね
車載とか携帯電話もありうるのかな
- 25 名前：デフォルトの名無しさん mailto:sage [2008/12/13(土) 06:17:58 ]
- >>24
ありうるけど、まだ高価すぎる。
PIC や DSP なみにコモディティ化したら、みんなが使うだろう。
組み込みにとっては、CUDA か CL かというのは、次かその次の世代の話だろう。
ま、現場はアレもコレも知っとかないとねｗ
- 26 名前：デフォルトの名無しさん mailto:sage [2008/12/13(土) 08:55:49 ]
- これれは今出てるiPhoneでも使えるのかね
- 27 名前：デフォルトの名無しさん mailto:sage [2008/12/13(土) 10:14:46 ]
- >>26
ARMはSIMDらしいよな。
Appleがやってくれるかもしれん。
- 28 名前：デフォルトの名無しさん mailto:sage [2008/12/15(月) 02:44:31 ]
- DsPICってのも有るし、しかも最近clockがどんどん上がってる。
このPICに載ってるDSPの数が増えたら8bitのGPGPUって感じじゃね?
- 29 名前：デフォルトの名無しさん mailto:sage [2008/12/15(月) 09:32:57 ]
- dsPIC m9（＾Д＾）ﾌﾟｷﾞｬｰｰｰｯ
- 30 名前：デフォルトの名無しさん mailto:sage [2008/12/17(水) 03:23:32 ]
- なんでこのスレでdsPICの名前が
CLで叩く意味はちょっと見出せないw
- 31 名前：デフォルトの名無しさん mailto:sage [2008/12/18(木) 03:06:23 ]
- これは楽しみだわ
- 32 名前：デフォルトの名無しさん mailto:sage [2008/12/22(月) 21:22:09 ]
- spec読んだけどcudaに毛が生えたようなもんだね
メモリ階層もモデル化したと言うけど、ほぼ現行のGPUが前提。
興味なくなった。
- 33 名前：デフォルトの名無しさん mailto:sage [2008/12/22(月) 21:51:48 ]
- 1.0だからな・・・
Intel VTと同じで2.0からが本気なんだよｗｗｗ
- 34 名前：デフォルトの名無しさん mailto:sage [2008/12/23(火) 14:09:23 ]
- Open CLって結局なんなんだよ
- 35 名前：デフォルトの名無しさん mailto:sage [2008/12/23(火) 19:27:26 ]
- journal.mycom.co.jp/column/osx/305/index.html
- 36 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 19:12:01 ]
- 2009年，本格始動するGPGPUの世界・後編〜GPGPUのプラットフォーム動向
www.4gamer.net/games/076/G007660/20090206031/
- 37 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 20:17:07 ]
- >>37
大丈夫、DSPがOpenCLに対応する可能性は限りなく低いから。
まして、x86プロセッサでOpenCL対応するくらいならCt使う方が遥かにまし。
- 39 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 22:24:19 ]
- つーかOpenCLってとりあえずMac用でしょ
- 40 名前：デフォルトの名無しさん [2009/02/15(日) 22:27:21 ]
- なんで？
- 41 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 22:30:45 ]
- OpenCLの規格化作業を猛烈に推し進めたのがアップルだから
- 42 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 22:42:22 ]
- だからMac用？
どうして？
- 43 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 22:42:47 ]
- >>38
なんか理解できてないようだけど、
こいつの価値は並列処理にあると思う。
要するに今までのGPGPUは、GPUによる高速化
というのがメインだったけど、OpenCLの場合は、
CPUとGPUで並列処理が可能になる。
元々はAppleとNVIDIAが協力して、CUDAを基礎に
した（と思われる）ものを、さらに標準化の過程で
より汎用性を重視して、GPUに依存しないよう設計
にしたものがOpenCL。
- 44 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 22:48:46 ]
- >>42
大丈夫、Mac専用じゃないよ。
Appleが規格の孤立化を避けるのが目的だと思うけど、
最初からオープン標準化にこだわって作られた規格。
規格の策定作業のメンバーにはIntelやAMD、NVIDIA、
ソニーなど、MSを除く主要企業は全て参加しているし、
OpenGL（ES）との連携やスマートフォンへの対応もあるし、
これから先、携帯端末全盛の時代の最有力候補でもある。
- 45 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 22:50:10 ]
- >>44
あんたに聞いてないんだよ
- 46 名前：デフォルトの名無しさん mailto:sage [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を採用する企業も当然存在するとは思うけど。
- 47 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 23:13:48 ]
- >>46
お前の意見なんてどうでもいい
マジで黙ってろクソ野郎
- 48 名前：デフォルトの名無しさん mailto:sage [2009/02/15(日) 23:18:30 ]
- >>47
あうごめんｗでも答えちゃったよ？
- 49 名前：デフォルトの名無しさん mailto:sage [2009/02/16(月) 18:57:22 ]
- で、まだかね？
- 50 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 11:40:11 ]
- マルチコア動作版くらいそろそろ出せよ ｶﾞｵｰ
- 51 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 11:44:25 ]
- てかDirectXは独自に実装するみたいだが
MSは意地でも標準化を妨害したいらしいｗ
- 52 名前：デフォルトの名無しさん mailto:sage [2009/02/17(火) 12:35:14 ]
- 妨害つーか、OpenCLはOpenGLとは連携するが
Direct3Dとは連携しないので、MSが自前で作るしかない。
- 53 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 19:01:40 ]
- MSはどっちかっていうとマルチCore CPUをグラフィックに活かそうとしているよね。
逆。
- 54 名前：デフォルトの名無しさん mailto:sage [2009/02/21(土) 19:03:43 ]
- >>52
MSはCompute Shaderを準備中。
- 55 名前：デフォルトの名無しさん mailto:sage [2009/02/26(木) 00:45:30 ]
- 言語はC99ベースだからいいかと思ったけど、再帰が使えないのは痛いな。
Cで書いてコンパイルしたバイナリと、OpenCLで書いてコンパイルしたバイナリを
リンクできればいいな。
- 56 名前：デフォルトの名無しさん mailto:sage [2009/02/26(木) 11:20:43 ]
- .objが中間コード的なものだったら出来たかもね。
- 57 名前：デフォルトの名無しさん mailto:sage [2009/02/28(土) 03:39:12 ]
- 再帰なんていらね
- 58 名前：デフォルトの名無しさん mailto:sage [2009/04/02(木) 08:17:35 ]
- 並列化しやすい問題で結構使うぞ、再帰探索は
こっち方面はIntelに期待するしかないかもね
- 59 名前：デフォルトの名無しさん mailto:sage [2009/04/02(木) 23:41:47 ]
- 時間とメモリの使用量が不定になるからねぇ。
OpenCLの主戦場を考えるとどうなんでしょうか。
- 60 名前：デフォルトの名無しさん mailto:sage [2009/04/03(金) 01:52:09 ]
- 再帰するようなアルゴリズムの場合、命令ポインタの動きに一意性がないし
決してデータレベル並列ではないんだよな。
SIMDでは命令ポインタが要素ごとに独立、というわけにはいかない。
プレディケートをやるのは逆に言うと自由に分岐ができないことの現れだし。
- 61 名前：デフォルトの名無しさん mailto:sage [2009/04/11(土) 13:13:33 ]
- ほしゅ
- 62 名前：デフォルトの名無しさん mailto:sage [2009/05/03(日) 23:04:11 ]
- まだ？
- 63 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2009/06/20(土) 20:41:46 ]
- >>64
OpenCL 1.0 仕様書
ttp://www.khronos.org/registry/cl/specs/opencl-1.0.43.pdf
- 66 名前：デフォルトの名無しさん mailto:sage [2009/06/21(日) 04:07:00 ]
- Appleが用意したOpenCLの技術解説のpdfのリンク貼っとく
images.apple.com/macosx/technology/docs/OpenCL_TB_brief_20090608.pdf
- 67 名前：デフォルトの名無しさん mailto:sage [2009/06/29(月) 13:32:04 ]
- OpenCLのCPU動作版って公式で作るのか？
それとも誰か作ってる人が居る？
- 68 名前：デフォルトの名無しさん mailto:sage [2009/06/30(火) 20:18:36 ]
- Intel か Apple が CPU 用 OpenCL ドライバを作成すれば問題ない。
Windows や Linux の他社 OS や
AMD などの他社 CPU などで動作するドライバは
やっぱり公式待ちかな。
個人で Java VM や GPU Direct3D/OpenGL ドライバを
作ってしまえる人が興味を持ってくれたら話は別だけど。
- 69 名前：デフォルトの名無しさん mailto:sage [2009/06/30(火) 20:23:54 ]
- スノレパにはCPU用ドライバが付いてくるでしょ
GPUよりも数十倍から100倍以上は処理が遅いCPUで
Open CLを動かす価値が有るかはわからないけれど
- 70 名前：デフォルトの名無しさん mailto:sage [2009/06/30(火) 20:34:15 ]
- >GPUよりも数十倍から100倍以上は処理が遅いCPU
という夢を見ている
- 71 名前：デフォルトの名無しさん mailto:sage [2009/06/30(火) 20:46:55 ]
- Core 2 Quad QX9775： 102.4 GFLOPS
Radeon HD4870：1.2 TFLOPS（1200 GFLOPS）
一桁余分だな。
- 72 名前：デフォルトの名無しさん mailto:sage [2009/06/30(火) 23:19:38 ]
- このスレで言うのもなんだが並列処理って知ってる？
- 73 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 00:44:41 ]
- CPU と GPU を並列に走らせて 10 が 11 になるよりも、
その１をUIやGPUが苦手な処理を与えたほうがいいんじゃね？
マルチタスク（プロセス）的にも CPU は空けておきたいかも
- 74 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 02:58:17 ]
- CPUよりGPUのが早いってことになってるけど
それは実は大嘘でちゃんとマルチコアで作りこんだらスピードは大差ない
GPUメーカー製のドライバはCPUでも動くような振りだけは実装するだろうけど
絶対にまともな実装はしない、ばれるから
だからちゃんとしたCPUメーカーか第三者が作ったものが必要
- 75 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 03:05:43 ]
- >>71
それは理論的な演算速度だけだとそうだけど
メインメモリからデータを取り出して結果を戻すのに要する時間で計算すると
遥かにCPUの方が早い
- 76 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 06:44:02 ]
- 結局ワークロード次第なのだがGPUが明らかに速い分野なんて非常に限定的で馬鹿にされまくっているのが実情
GPGPUは過去のEPICと被るな
- 77 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 11:17:39 ]
- >>74
なんでGPUメーカーがCPU用ドライバを作るんだよ。
DirectXですらCPU用ドライバはＭＳが作ってるんだぜ？
>>75
特定分野に関してならメモリアクセスは速いでしょ。
じゃないと3Dレンダリングが使い物にならないものになる。
結局プログラマがどれだけ局所化を行えるかだろうね
- 78 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 14:42:50 ]
- >>77
３Dは転送する情報量は頂点座標だけなんだからCPUより早いのは当たり前でしょ
CPUのネックはメモリ転送速度だって言ってるでしょ
大量のデータを計算するような用途ではどんな工夫をしようがCPUには勝てない
- 79 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 14:45:50 ]
- しかも分散処理する部分は複雑に作りこんでないから
計算してる間は描画が止まるからな
計算してる間は文句なしに画面描画が止まる
CPUだと計算負荷に応じて外も動くけど
- 80 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 14:51:59 ]
- >>78
だからそのCPUでは勝てない分野でGPUを有効活用しようっていうのがGPGPUでしょ
映像のエンコードしかり、ゲノムの解析しかり超大量のデータ処理を肩代わりしたり、
またはAIなどの人工知能やMSのProject Natalみたいなものを実現するため、とか
- 81 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 14:57:20 ]
- >>79
だからGPUの仮想化とかマルチタスク処理とかがあるんでしょう
3Dゲームとかでもない限り 1/60 秒毎に画面描画を
挟むのはたいした負荷でもないレベルだし。
GPUでは小回りが利かない部分を管理するのがCPUの得意分野
- 82 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 17:58:11 ]
- >>80
だから今の構造だとCPUでは勝てない分野が３Dポリゴンの描画しかないのｗ
- 83 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 17:59:09 ]
- >>81
>>GPUでは小回りが利かない部分を管理するのがCPUの得意分野
現状と何も変わらない
- 84 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 18:03:26 ]
- 本来ならGPUの機能はCPU内部にあるべきだが、
IBMやINTELはサーバとか大規模計算方面ばかり気にして3Dとかグラフィックとかを軽視していたから、
見るに見かねた人がGPUなんてものを作ったんだよね。
- 85 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 18:04:59 ]
- GPUって、本質的に見たらやってることはCPUと変わらないのに、
CPUとバスを経由して通信している分無駄があるんだよね。
だから将来的にGPUはCPUに飲み込まれるのが健全だと思うね。
- 86 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 18:11:33 ]
- 行列積とか倍精度でもGPUの方が速いだろ。
- 87 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 18:23:10 ]
- >>86
そういう処理をするCPUの命令の一つにしてしまえば良い。
- 88 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 18:44:55 ]
- >>86
だから計算対象のデータをGPU側に引き渡してる間にCPUで計算出来るっつー話だわな
- 89 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 18:47:34 ]
- >>88
いや、まぁ実際にそういうことが多いわけだけど、俺が言いたいのそうじゃなくて、
GPUをCPUに統合するのが健全だと言っているだけであって・・
夢見がちな俺の願望でしかないわけだが。
- 90 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 21:55:32 ]
- >>89
今その方向に向かっているな。
AMDそのためにATIを買ったんだし、GPU専業のNvidiaは焦っている。
- 91 名前：デフォルトの名無しさん mailto:sage [2009/07/01(水) 22:00:36 ]
- ハードだけ買ってもOpenCLはじめソフトがｇｄｇｄ
このままだとIntel最強ってゆー何時もの結論で終了する
- 92 名前：デフォルトの名無しさん mailto:sage [2009/07/02(木) 01:07:12 ]
- マカーとして言わせてもらえばQuickTimeとAdobe CSくらいが対応してくれれば対応アプリとしては十分な気がするんだよな
OpenCLが一番活用できそうなのって結局画像動画関連だし
それにCoreImageやCoreVideoがCPUでも動いたようにOpenCLもCPU上で動かせるから未来がどっちに転んでも技術としては問題ないと思う
- 93 名前：デフォルトの名無しさん mailto:sage [2009/07/02(木) 01:20:12 ]
- 夜のお供に漫画ビューアにもな。
- 94 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2009/07/02(木) 12:51:12 ]
- DCのデモでも、CPUより早く動かすの苦労してたよ。
データ数が半端無く多くないとCPUを上回れない。
- 96 名前：デフォルトの名無しさん [2009/07/02(木) 12:56:37 ]
- 茸の左をひょいひょい躱した粟生と
リナレスの鬼速ジャブ…
この対決は興味深いぜ
- 97 名前：デフォルトの名無しさん mailto:sage [2009/07/02(木) 16:12:28 ]
- CPUとは別に画像処理などに有用なコプロセッサが１つ
PCやMacで眠っているからそれも使おうって方向でいい。
- 98 名前：デフォルトの名無しさん mailto:sage [2009/07/02(木) 19:12:15 ]
- 昔はコプロって別売りだったな。
- 99 名前：デフォルトの名無しさん mailto:sage [2009/07/02(木) 20:12:40 ]
- GPUの得意分野は浮動小数点数のベクタ演算だからなおさらコプロちっく
- 100 名前：,,・´∀｀・,,）っ-○○○ mailto:sage [2009/07/02(木) 20:52:46 ]
- Larrabeeって次世代の8087って位置づけなんだろうな
- 101 名前：デフォルトの名無しさん mailto:sage [2009/07/03(金) 02:14:02 ]
- 数年後にはCPUに統合されるのがわかりきっているけどな
- 102 名前：デフォルトの名無しさん mailto:sage [2009/07/03(金) 02:15:26 ]
- そのさらに数年後には独立されるだろう
- 103 名前：デフォルトの名無しさん mailto:sage [2009/07/03(金) 02:58:35 ]
- CPUだけじゃ最先端3Dレンダリングを処理しきれないｗって理由で、か
- 104 名前：デフォルトの名無しさん mailto:sage [2009/07/03(金) 04:19:19 ]
- 画期的なメモリバス技術でも開発されれば統合プロセッサのまま進化を続けるんじゃないかな
- 105 名前：デフォルトの名無しさん mailto:sage [2009/07/03(金) 06:38:34 ]
- ワイドテレビでこんなに広く！→縦が伸びてこんなに広く！→ワイドになって（ｒｙ
- 106 名前：デフォルトの名無しさん mailto:sage [2009/07/03(金) 22:50:21 ]
- CPUはある意味CELLの行く道が正しかったのか？
- 107 名前：デフォルトの名無しさん mailto:sage [2009/07/03(金) 22:56:22 ]
- >>105
ますます家が狭くなるがな
- 108 名前：デフォルトの名無しさん mailto:sage [2009/07/04(土) 15:37:52 ]
- OpenCL自体は普通にマルチスレッドのフレームワークに使えるから期待してるんだけど
出来ればクラスタリングとかにも対応して欲しいが
- 109 名前：デフォルトの名無しさん mailto:sage [2009/07/04(土) 17:43:55 ]
- OpenCL って Direct3D のシェーダ言語同様にドライバによる
インタプリタだと認識しているけど並列計算のフレームワークとして使えるの？
OpenMP や Grand Central Dispatch じゃダメなのだろうか
- 110 名前：デフォルトの名無しさん mailto:sage [2009/07/04(土) 18:47:02 ]
- 演算シェーダ相当の抽象化レイヤと考えて問題ないよ
汎用的な並列計算はOpenMPやGCDの方が適切。そのままマルチコアCPUをターゲットにした方がいい
OpenCL適用できる分野は「並列計算」の中のさらに「GPUに適した」特殊なアルゴリズム分野になる
とにかくデータを小さなブロックに小分けして、延々と同じ処理繰り返すようなの
- 111 名前：デフォルトの名無しさん mailto:sage [2009/07/04(土) 19:29:33 ]
- 標準化されてることに意味がある
- 112 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2009/08/07(金) 13:07:44 ]
- やっと動きが
- 114 名前：デフォルトの名無しさん mailto:sage [2009/08/08(土) 11:10:40 ]
- これRADONには対応しとらんのん？
- 115 名前：デフォルトの名無しさん mailto:sage [2009/08/08(土) 11:13:29 ]
- ラドン…だと？新手の北朝鮮ミサイルか？
- 116 名前：デフォルトの名無しさん mailto:sage [2009/08/08(土) 12:03:20 ]
- 恐竜だろ
- 117 名前：デフォルトの名無しさん mailto:sage [2009/08/08(土) 15:02:36 ]
- 風呂かとおもった
- 118 名前：デフォルトの名無しさん mailto:sage [2009/08/08(土) 19:53:25 ]
- サンプル動かしてもGPU全然関係ないな(´・ω・｀)
ATI StreamなのになんでCPUだけなんだよ
- 119 名前：デフォルトの名無しさん mailto:sage [2009/08/08(土) 22:02:49 ]
- AMDの対応がまだなんじゃね。
- 120 名前：デフォルトの名無しさん mailto:sage [2009/08/08(土) 23:16:43 ]
- ていうか Radeon の OpenCL ランタイムドライバが出来ていないとか？
- 121 名前：デフォルトの名無しさん mailto:sage [2009/08/11(火) 09:48:44 ]
- CPU対応は優先度が一番高いんだろう
GPUはチップ毎に対応しないといけないし
CPUとGPUの比較をしたり両方使って同時処理するのにも必要
- 122 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 07:49:11 ]
- 俺予想
OpenCLが動くということはnVidiaと同じ土俵でパフォーマンスが比較できるようになる。
現行のRADEONだとOpenCLでパフォーマンスが出ない。
nVidiaと比較されるのがいやなので今はドライバを出さずに
次のGPU(OpenCL向け機能拡張入り)を出すタイミングでドライバを出す。
- 123 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 19:05:49 ]
- >>122
萩原Obj-C(1.0のやつ)をみながらやっているもので。
Tiger使っているので2.0へはまだいけない。
- 124 名前：デフォルトの名無しさん mailto:sage [2009/08/15(土) 19:07:04 ]
- ごめん間違えた。
|
 |
