トップページ⇒tech
994コメント306KB

GPGPU

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん2005/10/08(土) 23:15:20
いつの間にやらCPUを超える演算性能を持ってしまったGPUに計算させてみるという
GPGPUについて語りましょう

参考リンク

総本山? gpgpu.org
http://www.gpgpu.org/
GPUをCPU的に活用するGPGPUの可能性
http://pcweb.mycom.co.jp/articles/2005/09/06/siggraph2/
0002デフォルトの名無しさん2005/10/08(土) 23:18:48
２
0003デフォルトの名無しさん2005/10/08(土) 23:23:53
メモリーに関してはだんだんスパコンのアーキに近づいてるからなぁ。
0004デフォルトの名無しさん2005/10/09(日) 03:46:05
ラデX1800のようにメモリレイテンシをあまり気にしなくていいというのは羨ましいな
0005デフォルトの名無しさん2005/10/09(日) 11:50:01
ShとBrook期待age
0006デフォルトの名無しさん2005/10/09(日) 13:11:52
CPU→GPU→CPUって経路でデータ流せるんだっけ?
0007デフォルトの名無しさん2005/10/09(日) 14:06:12
出来なかったら、画面のキャプチャーとか出来ないだろ。
0008デフォルトの名無しさん2005/10/09(日) 17:05:54
今現在、計算結果を持って帰るには一度フレームバッファに書いたのを吸い出すしかない。
今後改善されるとは思うけど、これじゃあ使えねぇよ。

でもXBOX360はメインメモリに直接アクセスする方法が用意されているらしい。
実用段階になったら、まずはトリップ計算機から誰か作ってよ。
0009デフォルトの名無しさん2005/10/09(日) 17:21:09
>>8
ソース公開してる奴ってどれ？＞計算機
ちとやってみたい
0010デフォルトの名無しさん2005/10/10(月) 14:05:01
これからはJavaやC#のようなオブジェクト指向言語をベースに
速度が重要な部分はシェーダー(GPGPU)でなんて流れになるのでしょうか？
0011デフォルトの名無しさん2005/10/10(月) 14:58:23
なりません
0012デフォルトの名無しさん2005/10/11(火) 14:13:56
GPGPUって過渡的なものであって、今後はXbox360/Cellに代表される
ヘテロジーニャスなマルチコアプロセッサの流れだろうな
0013デフォルトの名無しさん2005/10/11(火) 14:43:51
360はホモ臭い
0014デフォルトの名無しさん2005/10/11(火) 15:22:02
あぁたしかに360はハードウェアアーキはホモだけど、ソフトウェアアプリで
ヘテロっぽく使うんだった.
0015デフォルトの名無しさん2005/10/11(火) 20:31:37
小泉風に言えばGPUでできることはGPUに、CPUでなければいけないところはCPUでってこと？
0016デフォルトの名無しさん2005/10/11(火) 21:53:02
その言い方だと今までのアプローチとなんら変わらんがな
0017デフォルトの名無しさん2005/10/11(火) 22:59:09
OpenGLとかで流行ったBASICにできることは（ｒｙ、Cでなければ（ｒｙと変わらんね。
0018デフォルトの名無しさん2005/10/11(火) 23:55:23
それって>>10と同じじゃね？
0019デフォルトの名無しさん2005/10/12(水) 00:04:04
未だにオブジェクト指向と速度を関連させる奴がいるのか。
0020デフォルトの名無しさん2005/10/12(水) 00:24:44
JavaやC#が速いとはあんまり思えないけどな
0021デフォルトの名無しさん2005/10/13(木) 21:17:35
age
0022デフォルトの名無しさん2005/10/13(木) 21:32:40
情報が少なすぎて。。
0023デフォルトの名無しさん2005/10/15(土) 00:38:51
RGBA8bitの32ビットフォーマットのテクスチャに対し、
各位置のビットが1のピクセルの個数を数える、見たいな処理って出来ませんかね。
Rの3ビット目が1のピクセルは150個、みたいな感じで。

RGBA4種類の個数とかだったら簡単に出来るんですが、
各ビット合計32個のデータを取り出す方法がおもいつかない。。
0024デフォルトの名無しさん2005/10/15(土) 08:50:52
>>23
8bit パレット画像として扱うとかどう？
二アレスとサンプリングにして。
１回に１チャンネルしか処理できないけど。
0025デフォルトの名無しさん2005/10/15(土) 12:41:23
>>24
やっぱり複数回に分けて処理するしかないですかねー。
せっかくデータをまとめたんだから、1度に処理できないかと考えたけど無理か。
0026デフォルトの名無しさん2005/10/15(土) 14:27:28
bsf・・・はx86だしな
0027デフォルトの名無しさん2005/10/23(日) 20:29:04
保守
0028デフォルトの名無しさん2005/10/24(月) 02:06:59
JavaとGPGPUのコラボ最強と思ってるのはたぶん漏れだけ
0029デフォルトの名無しさん2005/10/25(火) 01:53:53
GPUは基本的にストリームプロセッサだからCPUのような複雑な
分岐や少量のデータ処理を多数行うような仕事だと効率悪い。
現実は厳しいよ。
0030デフォルトの名無しさん2005/10/25(火) 15:42:06
そういう仕事をGPUに投げるのが間違い。
0031デフォルトの名無しさん2005/10/25(火) 23:21:53
>>29
大量のデータをひたすら単純処理する仕事はJavaの苦手とするとことだと思うのですが
0032デフォルトの名無しさん2005/10/25(火) 23:39:54
C++とGPGPUこれ最強
0033デフォルトの名無しさん2005/10/26(水) 01:58:39
>>1
語りたい事もないのに糞スレ立てるな
0034デフォルトの名無しさん2005/10/26(水) 02:11:17
GPUってなんの計算をしてくれるのよ。
0035デフォルトの名無しさん2005/10/26(水) 08:52:24
ようはSIMD
0036デフォルトの名無しさん2005/10/31(月) 01:05:14
>>34
いまならシェーダーさえ書けばどんな計算だってしてくれる
向き不向きはあるが、膨大な量の単純計算繰り返しなら
最新のCPUよりもGPUのほうが早い
0037デフォルトの名無しさん2005/10/31(月) 01:16:46
向き不向きなんてレベルじゃない。
かなりのレベルの並列性が無いとダメだし、入出力もかなり限定された形でしか出来ん。
どんな計算でもなんてとても言えん。
が、条件にはまる物ならばパフォーマンスの高さに驚く。
0038デフォルトの名無しさん2005/10/31(月) 01:28:46
結局GPGPUの使いどころとしては画像処理(2D)・映像処理・音声処理あたりに落ち着くんでしょうかね
もともとGPUの得意分野だし
0039デフォルトの名無しさん2005/10/31(月) 01:39:01
物理演算はねーの？？
0040デフォルトの名無しさん2005/10/31(月) 21:15:21
GPU演算での精度はどれぐらいまで期待できるんでしょうかね？
0041デフォルトの名無しさん2005/10/31(月) 22:43:58
丸めの方向を制御できなかったり、なんていう困った点もあるみたいよ＞GPGPU
0042デフォルトの名無しさん2005/11/08(火) 00:19:25
保守
0043デフォルトの名無しさん2005/11/13(日) 01:46:21
age
0044デフォルトの名無しさん2005/11/13(日) 15:32:56
発想としては面白いし、昔からこういうハードを本来の目的以外に使うって話は好きなんだけど
(キャラクタ表示機能しかないマシンでビットマップ表示とかFM音源でPCM多重再生みたいな）
なんかあんまり現実的に聞こえないんだけど。。

ハイエンドなGPUなんてゲーマー以外もってないじゃん。
CAD用のGPUなんてもっと少数派だし。
そのくせ、3d表示で使ってる間は当然使えないわけだろうし。
だいいち各GPUの違いを吸収する負担は誰が負うのよ。

CPUのマルチコア化の流れを受けてのことなのかな。
昔のコプロみたいにCPUの中にそういうGPU的なアーキテクチャを組み入れていこう、
って展望でもあるのか？
0045デフォルトの名無しさん2005/11/13(日) 16:05:04
3D表示使わないアプリで使えば無問題だし、
最近じゃハイエンドじゃなくてもシェーダが動く。
GPUの違いはシェーディング言語そのものでバージョン管理と、
そのラッパーであるライブラリで十分埋まる。
0046デフォルトの名無しさん2005/11/13(日) 20:08:06
>>44
とても現状を理解しての発言には思えない。
0047デフォルトの名無しさん2005/11/13(日) 20:15:55
PhysXもそろそろ出るね
CPU以外のパワーを利用するのって
一時的かと思ってたけど時代の潮流かな
0048デフォルトの名無しさん2005/11/22(火) 18:01:21
http://staraxis.kazelog.jp/okiraku/2005/11/atiavivo_49a9.html
ATIのAVIVOエンコード機能は凄い!!

DVD映像5分（720x480）をDivXやwmvにエンコードするのが25秒で終わるとか早すぎ！！！
GPGPUを使った物らしいです
0049デフォルトの名無しさん2005/11/22(火) 22:17:01
いや、Theaterっていう専用チップが乗ってるよ
http://www.4gamer.net/news.php?url=/news/history/2005.09/20050920190000detail.html
0050デフォルトの名無しさん2005/11/25(金) 12:27:04
FAQ - GPGPU.org Wiki
http://www.gpgpu.org/wiki/FAQ
0051デフォルトの名無しさん2005/11/29(火) 00:05:32
GPU GEMS2の日本語版が出たようだ

http://www.shader.jp/xoops/html/modules/wordpress/index.php?p=166
0052デフォルトの名無しさん2005/11/29(火) 00:06:17
sageたままだった・・・orz
0053デフォルトの名無しさん2005/11/29(火) 00:09:53
AGPメモリにフレームバッファ確保できなかったっけ？
0054デフォルトの名無しさん2005/11/29(火) 01:22:55
>>10
Javaチップ、Javaアクセラレータ
なんてものがあるしな。
考えられなくもないな
0055デフォルトの名無しさん2005/11/29(火) 01:24:29
>>19
むしろVMと速度だな。
C言語の中の人は
オブジェクト指向を使うと速度が遅くなる
から使わない方がいいとか未だにいっているからね。
0056デフォルトの名無しさん2005/11/29(火) 01:25:23
>>28
JavaのGUI, Swing APIやJava3D APIの3Dレンダリングの
部分だけGPUに任せられたらいいねえ。
0057デフォルトの名無しさん2005/11/29(火) 01:29:20
>>31
それも微妙なところではあるが。
Java SE 5 Tigerからかなりの高速化が実現されているし
Java SE 6 Mustangからはさらに高速化する。
Javaアプリ初回起動だけVM上で動いて
２回目以降からはネイティブで動くってことがあるわけで。
Javaアプリを起動するたびにVMをいくつも起動するという
問題も解消されるし。

それとJavaは他の言語と比べレスポンス性能が
極端に遅いことからクライアントサイドでは普及が
一時停滞した。ところがJavaは代わりに
スループット性能が高いという利点があったりする。
他の言語が戦術的短距離走タイプであるのに対し、
Javaは戦略的マラソンランナータイプ、ってところだろうか。
0058デフォルトの名無しさん2005/11/29(火) 11:54:36
>>56
Java3DはOpenGLかDirect Xがバックエンドになっているんだが。

ちなみに、SwingをGPUに描画させるという考えは、Swingの
設計思想(全部Javaで描画)に反するから実現不可能。
0059デフォルトの名無しさん2005/11/29(火) 16:23:09
これってグラボ変えたら動かなくなるんでしょ？
グラボなんてドンドン新しいのが出るんだからそんなの使えネェじゃん。
0060デフォルトの名無しさん2005/11/29(火) 16:42:24
それを避けるための高級言語じゃないの？
0061デフォルトの名無しさん2005/11/29(火) 17:11:03
自作板の雑談と何も変わらんな
0062デフォルトの名無しさん2005/11/29(火) 17:42:26
大抵はグラボを変えても動きます
特に新しいものに変える場合は可能性は高いです
例えるなら>>59は「MMXってCPU変えたら動かないよね？」みたいな質問です
0063デフォルトの名無しさん2005/11/30(水) 00:55:00
＞大抵はグラボを変えても動きます
大抵って？

＞例えるなら>>59は「MMXってCPU変えたら動かないよね？」みたいな質問です

MMXは、世に機能公開して広範なアプリを作らせた以上、
後継CPUでは完全互換を取って当たり前、という位置にいるわけだが、それと同等と？　
MMXが出たのは１０年くらい前で、今でもまだ動くんだが、それと同等と？
0064デフォルトの名無しさん2005/11/30(水) 01:01:32
>>63
既にShaderはほぼ標準装備ですが何か？
0065デフォルトの名無しさん2005/11/30(水) 01:12:41
>>63
並列アルゴリズムの実装のために少しでも安くて速い計算リソースを使おうという研究なんで、
互換性を気にして「10年後に動かなかったらどうするんだよ」という向きには用は無い。
0066デフォルトの名無しさん2005/11/30(水) 01:25:58
そもそもGLSLはOpenGLドライバ側でコンパイルされてGPUのコードに変換されるものだから
原則的にはGPUが変わっても動くと考えても問題ない。
(バグや仕様で動かない可能性は100%否定できないが)

ARBあたりから互換性のないシェーダー言語が出てきて、
どっかのGPUメーカーが今のGLSLをサポートしなくなるということがあれば問題になるが
ここまできてARBやGPUメーカーが今の仕様を完全放棄するのは難しいと思われ
0067デフォルトの名無しさん2005/12/01(木) 19:23:35
今までのGPUは後方互換をほぼ意識しないで拡張してきたからこれだけの性能が出たのだと思う。
今後もちゃんと動くかはかなり疑問に感じる。（GPGPUが一過性のような気がする。

＃最近のボードでも過去のDXは動くけど、ネーティブに動いてるわけではなくて、ドライバ辺りのエミュレートだったと思う。
0068デフォルトの名無しさん2005/12/01(木) 20:10:14
まぁ一過性というのはそのとおりでGPUは通過点でしかないだろうね。
今はいろいろ試して、問題点を出したり適応範囲を模索したりしてる段階。
それを元にハードウェアも含めてだんだん方向性が決まってくるわけで。
0069デフォルトの名無しさん2005/12/01(木) 21:17:17
GPUに本当に有用なアーキテクチャがあるならコプロと同じ運命をたどるでしょ。
リレースイッチをブザー代わりに使うような技術に発展性があるわけがない。
0070デフォルトの名無しさん2005/12/11(日) 06:22:53
age
0071デフォルトの名無しさん2005/12/13(火) 05:47:10
>>69
浮動小数点演算はコプロというか専用エンジンが無いとどうしようも無いぞ。
それはCELLとかも同じ。
0072デフォルトの名無しさん2005/12/13(火) 19:53:50
整数演算もできるようになるのはいつ？
0073デフォルトの名無しさん2005/12/13(火) 21:27:15
>>71
意味わからん。話が噛み合ってないな。

どうでもいいけど、コプロがない時代はPCは浮動小数点演算ができなかった、
とでも思ってるのかなw
0074デフォルトの名無しさん2005/12/14(水) 16:26:15
マシンに本物のFPU積んだ時には、嬉しくって毎日レイトレしてたな。
0075デフォルトの名無しさん2005/12/14(水) 16:41:40
コプロ積んでもBASICが全く速くならなかった時には、orzだったな。
0076デフォルトの名無しさん2005/12/15(木) 20:19:33
>>69
しかしブザーが出回るまでの間は有用だし生き延びるだろうさ。
0077デフォルトの名無しさん2005/12/17(土) 09:48:59
コプロ無しの少数演算って遅すぎだろ
0078デフォルトの名無しさん2005/12/17(土) 09:56:39
それよりGPGPUの話をしよう
0079デフォルトの名無しさん2005/12/17(土) 14:40:11
先生！誰もわかってないので話すことがありません！
0080デフォルトの名無しさん2005/12/17(土) 18:07:10
GPGPUは手段であって、目的じゃないからな。
なにか高速に計算したいものがあって、その手段としてGPGPUが良ければ使う。
目的がないのにGPGPUやろうぜとか言われても盛り上がらん。
手段のために目的を探すのはアホだしな。
0081デフォルトの名無しさん2005/12/17(土) 18:47:17
目的がないから手段も学ぶ必要ないもんな・・・・
日本発のGPGPUを使ったDivXエンコーダーとか作れれば盛り上がるのだろうが。
0082デフォルトの名無しさん2005/12/17(土) 20:29:41
GPGPU = Game Programming Gems(ﾌﾟ
0083デフォルトの名無しさん2005/12/18(日) 03:24:22
>>47
GRAPEは専用プロセッサのままなので他では使われないね。
コプロにしたほうが広がりやすい気がするけど帯域が問題なのかな。
http://www.itmedia.co.jp/news/articles/0405/28/news048.html

そして東工大のOpteronグリッドにはClearSpeedのSIMDアクセラレータが乗る
http://www.itmedia.co.jp/news/articles/0410/07/news039.html
http://japan.cnet.com/news/ent/story/0,2000047623,20075021,00.htm
0084デフォルトの名無しさん2005/12/19(月) 15:18:34
Scoutって一番興味あるんですが、まだ公開はされていないんですか?

Los Alamos National Labsのサイトに行ってもPDFの論文にしかリンク貼ってない。
0085デフォルトの名無しさん2005/12/21(水) 01:05:14
>>84
Brook for GPU じゃだめなの？
0086デフォルトの名無しさん2005/12/21(水) 13:29:13
Vista時代で、常に3D使うようになったらGPGPUも終わりな気がするのは
俺だけかな。
0087デフォルトの名無しさん2005/12/22(木) 17:50:35
AeroGlassをEnableにすれば大丈夫じゃない？
0088862005/12/22(木) 18:09:05
AeroGlassをEnableにすると、常にシェーダーが使われているわけだから
GPGPUには使えないのではないかと思ったんだけど。
0089デフォルトの名無しさん2005/12/22(木) 20:22:33
>>86
GPGPUって科学技術計算等の激しく重い演算用だろ？
普通のアプリ走らせてる横でやる必要もないと思うが。
0090デフォルトの名無しさん2005/12/22(木) 20:29:13
聞きたいのは二つのシェーダー使うアプリを同時に使用できるかと言うこと。
できるのならWindowsがGPU使っていてもGPGPUできるだろう。
もしできないのであったら、GPGPUするときはAeroGlassをオフにしなければならない。
>>89が言うことももっともだが、いちいちそんなことが必要になるなら価値は少し下がる。
0091デフォルトの名無しさん2005/12/23(金) 00:15:44
GPUにもコンテキストスイッチは存在するんじゃね？
0092872005/12/23(金) 00:16:23
ごめん、英語間違ってますた…disableだ…＿|￣|○
0093デフォルトの名無しさん2005/12/23(金) 00:34:05
VistaではGPUが仮想化されて、DirectXのデバイスロストが無くなる。
GPGPUとAeroGlassの併用も可能と思われ。
0094デフォルトの名無しさん2005/12/25(日) 18:37:14
>>90
GUIは(ゲームなどの描画と違って)四六時中描画してるわけではない。
0095デフォルトの名無しさん2005/12/26(月) 05:54:47
>>90
多分できるだろうけど、切り替えが発生したら猛烈に遅くなる予感。
GPGPUの唯一の価値＝速度だから、あんまりそういう用途には向いてないような・・・
0096デフォルトの名無しさん2005/12/26(月) 19:08:48
計算用に、もう一枚刺す。
0097842005/12/26(月) 19:49:18
>>85

いや、なんか紹介記事見てたら、簡単そうで。
C*の情報がないので言語仕様がわからないけど。

Vista時代には、PCI-ExpressにGPUどんどん追加していける仕様にするのでは。
x1でもパフォーマンス出るように工夫する必要があるけど。
0098デフォルトの名無しさん2005/12/26(月) 21:46:14
>多分できるだろうけど、切り替えが発生したら猛烈に遅くなる予感。
CPUはそれなりに現実的にマルチタスクできてるんだから
GPUだけできない理由は何もないような。
ドライバがそこらへんに対応してれば。
0099デフォルトの名無しさん2005/12/27(火) 16:55:05
>>98

並列性が高い分、タスクスイッチに伴うペナルティコストが、CPUに比べて
馬鹿にならないと思われ。
0100デフォルトの名無しさん2005/12/27(火) 17:07:20
並列動作可能なら、CPU側のタスクに合わせてタスクスイッチする必要はないんじゃない？
OS分の描画やりながら、遊んでるユニットでGPGPUの計算するとかできんの？
0101デフォルトの名無しさん2005/12/27(火) 19:25:35
VistaになってもUIは2kスタイルに設定するから問題ない。
0102デフォルトの名無しさん2005/12/27(火) 22:44:45
>>100

ローカリティの問題があるから、かなりVRAM積まないと違う作業はやりにくいと思うよ。
別カードにした方が賢いね。OSの描画はUMA、GPGPUはPCI-Eとか。
0103デフォルトの名無しさん2005/12/27(火) 22:56:31
結果はどの道メインメモリに書き戻すんだからそれほど大きなワークは必要なさそうな気もするが。
scatter&gatherつってもその範囲は高が知れてるし。
まあ用途次第だけど。
0104デフォルトの名無しさん2005/12/28(水) 21:03:56
GPGPUを使ったプログラムを誰かうｐしてくれよ
0105デフォルトの名無しさん2006/01/08(日) 11:27:22
だれかエンコーダー作ってよ。
sf.net探したけど見つからないし。
0106デフォルトの名無しさん2006/01/21(土) 15:20:00
保守。
0107デフォルトの名無しさん2006/01/21(土) 16:23:17
>>89
MFLOPS単位で処理能力公表してるし、浮動小数計算するのがメインっぽいね。
代表的なのとしては、動画再生支援くらい？
画像音楽動画エンコくらいしかおもいつかね。
他に浮動少数が活躍する場面ってなにがあるかな？

>>90
3Dならそれぞれのオブジェクトに対するシェーダーをロードして描画って感じだから、
それぞれのパイプラインが処理して同時に出力できるってな感じじゃねの？
0108デフォルトの名無しさん2006/01/22(日) 11:00:38
今こそGPGPUを活用するときではなかろうか。
http://pc.watch.impress.co.jp/docs/2006/0120/mobile321.htm
0109デフォルトの名無しさん2006/01/22(日) 13:01:49
H.264はAMDがYAMATOでデモってたけど、
やっぱ70Mbpsまでいくとコマ落ちするんだろうか。
0110デフォルトの名無しさん2006/01/22(日) 22:42:33
PureVideoとか待ってられないから、オープンソースで
シェーダ実装のH.264デコーダーとかでないかな。
0111デフォルトの名無しさん2006/01/22(日) 22:46:15
つかここム板なんだからGPGPUでhello, worldくらいやれ
0112・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/01/22(日) 23:00:21
だめだろ文字列を描画する以上の複雑な計算が無い
描画を豪華にしたいなら普通にシェーダ普通に使えって話
0113デフォルトの名無しさん2006/01/25(水) 09:18:55
ATI X1900スゲー化け物だね。

ただ例によってSM3.0といってもフル実装ではないのかな。
GPGPUというとどうしてもnVIDIAという印象があるから
手を出すのは勇気が要るのだけど・・・。
0114デフォルトの名無しさん2006/01/25(水) 22:46:15
純粋にグラフィック扱うならHDRでもAA効くATiの方がいいと自分は思ってるけど
VTFとか見てるとほかにも問題ありそうで怖い。
0115デフォルトの名無しさん2006/01/25(水) 22:47:57
まだまだ実用的ではないな
0116デフォルトの名無しさん2006/01/25(水) 23:16:11
X1800の時の爆熱問題を解決しないまま、
さらに熱い物を出してくるのは凄い。
0117デフォルトの名無しさん2006/01/25(水) 23:30:00
実際X1900なんてメディアのベンチ掲載用にとりあえず作ったやつでしょ。
数出さなければ、いくらでもできるよ。
普通のCPUだとただコア増やすだけじゃ意味無いけどGPUなんて増やせば増やすだけいいしね
まぁ一つが小さくて単純だからできるんだろうけど。
0118デフォルトの名無しさん2006/01/26(木) 02:34:56
3DMarkだけスコアが高いなんてさすがATIだな
0119デフォルトの名無しさん2006/01/26(木) 03:55:46
それでも48基って一度触ってみたいﾊｧﾊｧ
0120デフォルトの名無しさん2006/01/26(木) 12:43:18
>>119
お熱いのがお好き?
0121デフォルトの名無しさん2006/01/26(木) 19:11:38
Intelが45nm製造に成功って書いてあったけど、
実用化されれば90nmの製品がまったく同じものだと1/4の面積になるの？
0122・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/01/26(木) 19:53:37
原子・分子のサイズの限界もあるからまったく同じにはならない筈だよ。リーク電流対策とか必要だし。
0123デフォルトの名無しさん2006/01/27(金) 10:13:52
>>10
速度が重要で、かつこれからやる処理の中でGPUだと著しく速い命令で解決できる処理を内包する時だろ？
0124デフォルトの名無しさん2006/01/27(金) 18:20:22
GPGPUをやってみうと思い、試行錯誤しているのですが、
floatの配列を画像に変換してテクスチャとして貼り付け
オフスクリーンに出力された画像をfloatの配列に戻すまでは出来たのですが
シェーダー上ではテクスチャや出力する色情報がvec4やfloat4となっていて、
そのままfloatとして扱うことができません。どうすればいいのでしょうか？
0125デフォルトの名無しさん2006/01/27(金) 18:31:18
>>124
つ　スウィズル演算子

まあ並列で処理しないとGPGPUの魅力が4分の1になるんだが。
0126デフォルトの名無しさん2006/01/27(金) 18:39:12

カタカナだと出ないな
ttp://www.microsoft.com/japan/msdn/library/ja/DirectX9_c/directx/graphics/reference/shaders/ps_swizzling.asp
0127デフォルトの名無しさん2006/01/27(金) 18:50:10
>>125-126
即レスありがとうございます。
これを参考にいろいろ調べてみます。
0128デフォルトの名無しさん2006/01/28(土) 02:14:37
スレ立て以来初めてム板らしいやりとりが成立したなｗ
0129デフォルトの名無しさん2006/01/28(土) 16:48:11
次はCPCPUの時代
0130デフォルトの名無しさん2006/01/28(土) 17:03:46
みんなこれ読んだか?
ttp://grape.astron.s.u-tokyo.ac.jp/~makino/articles/future_sc/note011.html
0131デフォルトの名無しさん2006/01/29(日) 02:08:39
>>130
説明は面倒くさいが、その記事には同意しかねる。
GPGPU が万能じゃないなんて当たり前な話で、使いどころが分かってない奴は使わなければいいだけの話だ。
俺はゲーム屋だから、やらせることはいくらかある。だからやらせる。
0132デフォルトの名無しさん2006/01/29(日) 13:28:06
なあ最近ひらめいたアイデアなんだけど聞いてくれる？
普通テクスチャをシェーダにバインドするときの最大でも16ぐらいまででしょ？
でもテクスチャの代わりにキューブテクスチャを使えばx6枚使えることにならん？
例えばR32Fのシャドウマップを普通にバインドすると16だけど
RGBA32Fのキューブマップとしてバインドすれば16x6x4=384になる。ﾅｲｽｰｱｲﾃﾞｰｱじゃね？
0133デフォルトの名無しさん2006/01/29(日) 13:46:53
>>132
キューブの境界に連続性が無いデータだと、ちと不安だな。
あと、rgba にするのは、チャンネル間移動が無いことが前提だな。
いざというときには使える tips かもね。
0134デフォルトの名無しさん2006/01/30(月) 13:05:44
>>121
原子分子のサイズが主要な問題ではないんだけどな。
半導体製品の製造工程は理解できている?
#つーか、原子分子のサイズだけを問題にできるような製造技術があったら一財産築けるぞ。
0135デフォルトの名無しさん2006/01/31(火) 23:43:28
http://v-infinity.seesaa.net/article/11073754.html
GPGPUを使っていると思われるエンコードソフト

ATIとnVidiaのビデオカードで動作するらしい。
0136デフォルトの名無しさん2006/01/31(火) 23:58:44
>>135
>>48
0137デフォルトの名無しさん2006/02/01(水) 15:17:52
記事先では、GPUではなく、CPU処理って書いてるけど
ぶっちゃけ、単なるシェーダーで処理してるだけなら、現行のGF/ATiのGPUでGPU処理できると思うんだが・・・。
0138デフォルトの名無しさん2006/02/01(水) 18:18:42
GPUはUIの表示以外に使ってない。将来的には使う予定だろうけど。
じゃあ最初にCPU用コード書く必要ないじゃんね。もしかしてOSSのぱくり？
0139亀レスだが2006/02/13(月) 02:25:14
>>31
> 大量のデータをひたすら単純処理する仕事はJavaの苦手とするとことだと思うのですが

そんなことはない。
GPUが得意なことではあるが、
CPUが得意なことでJavaが不得意なことはない。
むしろHotspotの登場で数値計算などの分野での活躍が他言語より目立ってる。

システムよりな事、例えばアプリの起動速度、は苦手なこと多いが。
0140デフォルトの名無しさん2006/02/13(月) 09:54:38
>>139
おまえはJavaでソフトウェアレンダーでも書いてろ。
0141デフォルトの名無しさん2006/02/13(月) 10:54:25
確かに多少ゆがんでるようだが>>31よりは事実に近いな
0142デフォルトの名無しさん2006/02/13(月) 14:35:11
Java厨は消えろ。どうせシェーダなんて叩けないだろ。
0143デフォルトの名無しさん2006/02/14(火) 22:43:23
Java氏ねPCの動作を重くする害虫ソフトめ！
0144デフォルトの名無しさん2006/02/14(火) 23:49:16
重くなるのか？
0145デフォルトの名無しさん2006/02/15(水) 13:05:37
>>139
単語に反応するだけじゃなくて、議論の流れを読めよ。
0146すだこ2006/02/27(月) 03:45:54
実際問題として例えば

　　LAPCKが動いた

とか

　　姫野ベンチがいくらだったとか

そういうのって、どっかにあるんですかね？

0147デフォルトの名無しさん2006/02/27(月) 12:07:53
JavaのJITがGPGPUを使用するコードを吐くと嬉しい。
これが出来たら、ネイティブコード系の言語がいらなくなるかも。
性能面で。
0148デフォルトの名無しさん2006/02/27(月) 15:22:15
>>147
JavaからGPU使えばいいだけでは？
0149デフォルトの名無しさん2006/02/27(月) 16:15:47
実行環境が対応することで
開発した当初は存在してないGPUも
活用できるようになるだろ。
WORAの思想もそのまま生かされる。
0150デフォルトの名無しさん2006/02/27(月) 16:19:09
そのためのCgでは？
0151デフォルトの名無しさん2006/02/27(月) 18:39:33
Cgは演算結果をメインメモリに書き出せない。
だから、基本的にはグラフィック処理にしか使えない
0152デフォルトの名無しさん2006/02/27(月) 20:05:18
メインメモリに書き出すのはシェーダではなくAPIの役目では？
0153デフォルトの名無しさん2006/02/27(月) 20:44:31
そういう仕組ができれば自然とCgやHLSLもサポートするだろう。
問題はいつサポートされるのかということと、まともなスピードで
出せるかということだ。
0154デフォルトの名無しさん2006/02/27(月) 20:49:46
Direct3D10のOutputStreamみたいな話？
0155デフォルトの名無しさん2006/02/27(月) 22:02:15
>>148
透過的にして欲しいということだろ？
現状VMもSSE2とか自動判別してつかうようになったり
ハードウェアアクセラレーションもDirectXやらOpenGLやら使えてる

WinだとNT4対応のためにDirectDrawがデフォだが描画時テクスチャの
コピーをメモリからVRAMに自動的に作って高速にブリット、
オフスクリーンイメージが失われたらメインメモリから復旧とか全自動だ
もちろん、VRAMにおいておく優先順位が設定できて自動的にVRAMから
おいだされたりとかわりとすばらしい
0156デフォルトの名無しさん2006/02/27(月) 23:24:09
Java3Dでシェーダ使えるんじゃないの？
0157デフォルトの名無しさん2006/02/27(月) 23:34:47
なぜゆえこのスレでJavaにこだわるんだ
0158デフォルトの名無しさん2006/02/27(月) 23:36:08
極度に抽象化されているがゆえに知らないうちに使われている

という状況が一番あるからでは？
0159デフォルトの名無しさん2006/02/27(月) 23:51:55
JITにGPGPU使わせるよりも、
シェーダをJavaで記述する方向で開発した方がいいだろう。
0160デフォルトの名無しさん2006/02/28(火) 00:07:10
5.0で追加されたatomicAPIとかみたあとではもう何が来ても驚かん。
0161デフォルトの名無しさん2006/02/28(火) 12:52:32
CoreImageもGPGPU？
0162デフォルトの名無しさん2006/03/03(金) 18:51:04
わけねーだろ
0163デフォルトの名無しさん2006/03/03(金) 22:20:09
GPGPU = 食べるための研究ネタ + 趣味
0164デフォルトの名無しさん2006/03/04(土) 11:40:46
でも、かつての「コプロセッサ」みたく、
ベクトル演算用のプロセッサを
メインプロセッサの他に持つのって
たぶん正解の一つだよな。

バスがハイパートランスポートだと最高かな。
0165デフォルトの名無しさん2006/03/04(土) 12:08:02
>>164
その考え方だといつかはCPUに取り込むのが普通

という結論になっちまうぞ

感覚的には非対称型マルチプロセッサのほうが近いのでは
0166デフォルトの名無しさん2006/03/04(土) 13:44:50
>>164
＞ベクトル演算用のプロセッサを
＞メインプロセッサの他に持つのって
その目的は何だ？
0167・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/03/04(土) 15:31:49
暗号とかゲーム用物理演算のアクセラレーション
0168デフォルトの名無しさん2006/03/04(土) 22:13:25
それって、CELLじゃん。
0169デフォルトの名無しさん2006/03/04(土) 22:14:53
>>168
orz
車輪の再発明スレに行ってくるか....
0170・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/03/04(土) 22:26:06
でもIntelのMany Core構想ってCellにも通じるものがあるよ。
汎用プロセッサだから当分はメインコアのリッチ化は進行するだろうけど。
0171デフォルトの名無しさん2006/03/05(日) 02:02:27
つーか、ＤＳＰ搭載やらｘｘコントローラ搭載なんてＣＰＵはありふれてるし、それらと今のＧＰＵはちょっと違うだろ。
依存性の無い並列処理がたまたま最近（ちょっと昔？）の頂点処理や画素処理にあるわけだ。
Cell なんかは、あまりＧＰＧＰＵっぽくはない。ＤＳＰを７つとか８つ積んでるようなもんだ。
ゲーム屋には面白いけど、ＧＰＧＰＵらしい並列演算を念頭に置くなら、ヘテロなんてどうでもいい。ＧＰＧＰＵのパワーの源は、同じコンテキストの演算を別パラメータで同時に実行するトコにあるわけだから。
0172デフォルトの名無しさん2006/03/05(日) 12:12:59
昔パソコンのCPUが貧弱な時代にはプロセッサボードというのがわりとありまして
拡張スロットにCPUより性能のよい石とメモリがのっておりました。

歴史は繰り返してるだけ
0173デフォルトの名無しさん2006/03/05(日) 13:10:09
それいうならコプロw
つーかガイシュツ杉
0174デフォルトの名無しさん2006/03/05(日) 13:20:07
このスレでGPGPU以前にシェーダプログラミングやったことある奴って
２・３人しかいなさそうだな
0175デフォルトの名無しさん2006/03/05(日) 14:42:12
>>173
コプロだとコプロインターフェース経由でのアクセスという意味だから
外部にあるプロセッサとは別物だろう


そしてGPUはそっちの方式
0176デフォルトの名無しさん2006/03/05(日) 17:50:21
O・D・P！O・D・P！
0177デフォルトの名無しさん2006/03/05(日) 22:25:24
組み替え可能ハードウェアはどうよ
FPGAで組むと、クロックは半分くらいになるらしいけど、
特定用途なら１サイクル当たり倍以上の性能だせるっしょ
0178デフォルトの名無しさん2006/03/05(日) 23:05:11
数百MHz～数GHzクラスのクロックで動かせる一般向けFPGAってあるのか？
0179デフォルトの名無しさん2006/03/05(日) 23:47:43
通常300MHzくらいまでだな

ただし、腕による
0180デフォルトの名無しさん2006/03/06(月) 00:54:43
http://www.xilinx.co.jp/products/silicon_solutions/fpgas/virtex/virtex4/index.htm
これは５００MHzってなってるね
フリーの高速実装とか出回ればよさげ。
0181デフォルトの名無しさん2006/03/06(月) 01:18:40
ハードウェア加速という訳がきらい
0182デフォルトの名無しさん2006/03/12(日) 10:18:08
ハードウエアブーストってのはどうだ？
0183・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/03/12(日) 19:51:14
ハードウェアｋｓｋ
0184デフォルトの名無しさん2006/03/17(金) 02:42:33
GPGPUって

文字列の計算とかできる。


AAAABBAACCAAAにCは何個含まれているかとか計算できるの？

いまいちどんな計算できるかわからない
0185デフォルトの名無しさん2006/03/17(金) 19:20:23
文字だって、１つ１つは数値でしょ。アスキーコードの
普通に出来るっしょ
0186・∀・）っ-○●◎- ◆Pu/ODYSSEY 2006/03/17(金) 22:18:32
整数演算性能には期待しないほうがいい気もするんだが・・・
0187デフォルトの名無しさん2006/03/18(土) 00:11:39
期待するとかしないではなくて可能か不可能かしりたい
現状Pentiumの100Mhzぐらいの処理性能でもいいから
可能かどうか知りたい
　サンプルとか全然なくて書き方すら解らず困り気味
0188デフォルトの名無しさん2006/03/18(土) 01:32:06
文字コードを実数に変換して処理するとか（ｗ
0189デフォルトの名無しさん2006/03/18(土) 03:03:19
可能かどうかで言ったら、むしろ不可能なことの方が少ないだろう。
ただ184の処理は明らかにGPU向きではない。

というより184は>>131の2行目でも読んでくれ。
0190デフォルトの名無しさん2006/03/18(土) 03:50:19
>>184 できるぞ。
例えば複数の文字列を２次元配列にする。これを８ビットパレットの入力画像とする。
パレットの内容は、調べたい文字の番号のパレットだけ 1 で他は 0 とする。

入力画像を
abcdefgh
aaaabbbb
aqswedef
pokuhywd
の 8x4 画像としよう。文字列が４本だ。

出力バッファを 1x4 の画像とする。これを 0 クリアしておく。
で、A を調べたいとする。
入力画像から、左から順に８回パレット参照して、出力バッファに"加算"してゆく。
1 1 1 1 1 1 1 1
1 2 3 4 4 4 4 4
1 1 1 1 1 1 1 1
0 0 0 0 0 0 0 0
８回行うと、出力バッファの内容は一番右になる。左側から、n 回目のフェッチ＆加算だ。

４並列でテーブル引きと加算が行えたわけだ。
テーブルの内容によっては、文字による重み付けも行える。
画像の内容を元にテクスチャフェッチもできるから、関数空間の計算結果を入れておくことで、複雑な関数を扱うこともできる（ピクセル間の線形補間が有効な精度のときに限る）。
事情が許すなら、RGB 別々の値にすれば３つの関数を同時に実行することもできる。
ちなみに縦長でアクセスしたりすると VRAM アドレッシングの問題でピクセルパイプがフル稼働できないから、実装時には工夫するように。
畳み込み演算を並列にやって効果が上がるものは検討の価値がある。
ライフゲームなんかは練習にいい。


ところで俺は 131 なんだが、そのときやってた PS3 のゲームはお蔵入りしたｗｗｗｗｗｗ
今ＤＳやってるｗｗｗｗｗ
おまいらはテクスチャフェッチのレイテンシ隠すのに涙目になってればいいさ、ばーかばーかｗｗｗｗｗｗ
0191http://www.vector.co.jp/soft/win95/util/se072729.html2006/03/18(土) 22:16:50
TextSS　のWindowsXP(Professional)64bit対応化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？
0192デフォルトの名無しさん2006/03/18(土) 23:19:37
>>190
あー

お前特定できちゃいました
0193デフォルトの名無しさん2006/03/19(日) 02:03:09
興味あるのですがどこから入門すればいいのでしょうか
0194デフォルトの名無しさん2006/03/19(日) 09:41:45
>>190のVRAMアドレッシングの話って、詳しい説明あるとこない？
0195デフォルトの名無しさん2006/03/19(日) 20:42:58
>>194
知らん。
しかしピクセルがＶＲＡＭ上で何故ジグザグに配置されているかを理解してれば問題ないんじゃないだろうか。
それ以上は機器固有の話だから、実測するしかない。
0196デフォルトの名無しさん2006/03/19(日) 23:05:06
havok fx
ttp://www.shader.jp/xoops/html/modules/wordpress/index.php?p=230
0197デフォルトの名無しさん2006/03/20(月) 01:47:19
>>195
ジグザグに配置って初めて知ったんだけど、どういうこと？
http://spin.s2c.ne.jp/stoday03.html
の、ヒルベルト曲線順ラスタライズみたいな話ですか？
0198デフォルトの名無しさん2006/03/20(月) 09:58:10
通りすがり＆スレ読んでなくて悪いけど、これはガイシュツ？

GPU コンピューティングの動向と将来像
ttp://www.jaist.ac.jp/~masa-t/publications/GPU_final.pdf
0199デフォルトの名無しさん2006/03/21(火) 02:18:54
>>196
... new type of rigid-body object called a Debris Primitive. A Debris Primitive is a compact representation of a 3D collidable object ...
面白そうかも。
デブリ同士じゃなかったら怒るけど。デブリ単体でもそこそこの地形となら喜ぶけど。
ああ、ハイトマップとの比較かもなあ。

>>197
そのページで言うところの「単純なタイル順（Z字順）」のこと。

>>198
初出。
そういうのが公開されるのは >193 のような人にとって喜ばしいことだ。
0200デフォルトの名無しさん2006/03/21(火) 02:28:18
>>198のは>>196の管理人が書いた物だ
0201デフォルトの名無しさん2006/03/21(火) 13:15:32
プログラミングはどこから始めたらいいのでしょうか。
GPGPUの技術的な背景とかは解りましたが、
とりあえずプログラム組んでみてどこまで可能か調査
してみたいのですがみなさんはどこから学んだのでしょうか
0202デフォルトの名無しさん2006/03/21(火) 22:16:46
>>201
アバウトすぎだ。
何が知りたいのかサッパリわからん。
http://www.redout.net/data/osietekun.html

nVidia のサイトでも行けば？
0203デフォルトの名無しさん2006/03/21(火) 23:29:42
いやもうHelloWorldレベルでいいんですけど
0204デフォルトの名無しさん2006/03/21(火) 23:55:15
・・・・。
がんがれｗ
0205デフォルトの名無しさん2006/03/22(水) 01:51:25
>>203
http://msdn.microsoft.com/library/ja/jpdx8_c/hh/directx8_c/_dx_directx_graphics_c_c_tutorials_graphics.asp
これで不満なら、どこまで出来てどこで詰まってるのか説明しろ。
他の連中は知らんが、俺はエスパーじゃねぇ。
0206デフォルトの名無しさん2006/03/22(水) 13:56:48
↑それは、GPGPUというよりDirectXのHelloWorld

要するにGPUで1+1を計算させて2という値をメインメモリに
持ってくるようなのがGPGPUのHelloWrldじゃないのかな。
0207デフォルトの名無しさん2006/03/22(水) 17:28:42
NVIDIA、GPUによる物理シミュレーションをGDCでデモ
http://pc.watch.impress.co.jp/docs/2006/0322/nvidia.htm
0208デフォルトの名無しさん2006/03/22(水) 23:28:39
>>206
じゃあお前が説明してやれよ。


アレやったら、描画先を変更してサーフェスをロックして持ってくるだけだろ？
演算方法なんざ、最初はレンダーステートの設定だけで十分だろ。

つーか、ナンセンスな回答だってのは承知してんだよ。
何が分からんのか分からねーんだから答えようがねーよ。
財力もプラットフォームも言語知識もハードウェア知識も分かんねーのにどんなアドバイスができるってんだ。

つーか GPGPU で Hello World つったら、Hello World って書いたテクスチャをフレームバッファにレンダリングすることじゃないか？
フレームバッファこそ、GPGPU の標準出力としては相応しいだろう。

なんでそんなに俺をイラつかせるんだ、ってスレが昔あったなあ。マ板だっけ？
0209デフォルトの名無しさん2006/03/23(木) 02:01:06
Brookとかｓｈとか使ってプログラム組んでみた方いますか？
今ちょっと勉強してます。
0210デフォルトの名無しさん2006/03/23(木) 11:58:18
レンダリングするだけじゃ普通の描画じゃんか。
0211デフォルトの名無しさん2006/03/24(金) 01:10:12
>>210
何が不満なんだ？ Hello World と同じくらいには役に立つと思うが。
0212デフォルトの名無しさん2006/03/24(金) 04:49:25
クダ巻くだけならどっかいけ。
0213デフォルトの名無しさん2006/03/24(金) 12:58:06
>>211
>1を読めよ

>いつの間にやらCPUを超える演算性能を持ってしまったGPUに計算させてみるという
>GPGPUについて語りましょう
0214デフォルトの名無しさん2006/03/24(金) 14:11:29
>>213
演算結果の出力がレンダリング結果じゃないか。
エッジ抽出や DCT とかしたら、フレームバッファに転送して目視確認するだろ？
何が足りないんだ？ それとも何かが蛇足なのか？ 「入門」がスレ違いなのか？
0215デフォルトの名無しさん2006/03/24(金) 14:34:21
じゃあDirectXスレでいいじゃん
このスレ要らんね
終了か？
0216デフォルトの名無しさん2006/03/24(金) 15:32:51
GPUで計算してフレームバッファに書き出して、そのフレームバッファを
メインメモリに持ってきて、それを構造体に格納していくくらいのことしないと
HelloWorldとは言えない。
そして、いまでは専用言語で簡単にできるじゃないか。
0217デフォルトの名無しさん2006/03/24(金) 20:46:13
行列演算が簡単に出来れば応用範囲が広がりそう
0218デフォルトの名無しさん2006/03/24(金) 21:40:10
俺もHelloWorldを欲してるクチでGPUを使う方法が分からないから何とも言えんが
行列演算はSIMD向きじゃん。文字列処理に比べれば簡単だと思う。

問題は、どれだけGPUにデータを留めたまま大量に演算出来るかじゃないか?
1演算してはCPUが使うようだと、GPU間のデータ転送に時間を食われる。
0219デフォルトの名無しさん2006/03/24(金) 22:48:22
みんな、DSP的に使いたいのでしょ？
メディアンフィルタとかエンコーダーとかやってみたいね。
俺もやり方はよくしらんが。
0220デフォルトの名無しさん2006/03/25(土) 01:54:11
はっきり言ってDSP的に使う以外、GPUに興味ないな
だれか教えてくれないのですか？ケチしないで教えてくださいよ
0221デフォルトの名無しさん2006/03/25(土) 03:04:58
>つーか GPGPU で Hello World つったら、Hello World って書いたテクスチャをフレームバッファにレンダリングすることじゃないか？
ﾜﾛﾀ
0222デフォルトの名無しさん2006/03/25(土) 05:02:12
>>215
> じゃあDirectXスレでいいじゃん
いいアイデアだ。入門はヨソの描画ライブラリスレに任せよう。
このスレは入門に限ったスレじゃないから、話題がある限りは不要ということも無いだろう。

>>216
ロックして持ってくるだけだろ。入力データもロックして書き込まないと認めないということか？
専用言語とやらを入門とすることについては、君が説明する分には俺に異論は無い。

>>221
楽しんでいただけたようでまことに結構。
0223デフォルトの名無しさん2006/03/25(土) 05:44:20
定番の波動シミュレーションあたりが、Hello World的存在じゃないかな。
GPGPU的には全く面白くないネタだけど、Hello Worldってそんなもんだろう。
0224デフォルトの名無しさん2006/03/25(土) 12:03:44
よし決めた。
最初の目標はGPUでπの計算することだ。
0225デフォルトの名無しさん2006/03/25(土) 17:53:00
>>223
おれはそういうのは、最初の演習問題にはふさわしいけれども、Hello World 的だとは思えないのだが。
ちょっとのお約束と、なんらかの出力、という程度が Hello World 的ではあるまいか。変数や制御構文の前にやるものだし。

描画はできる、というのを前提とするのなら、プラットフォームやライブラリを越えて一般化できる具体的（ソースつき）な入門はありえない、という結論になるだろうか。それとも専門言語の人に期待するか。
0226デフォルトの名無しさん2006/03/25(土) 21:14:14
なにこのヘタレの素靴
0227デフォルトの名無しさん2006/03/27(月) 04:59:04
>>226
ようこそ
0228デフォルトの名無しさん2006/03/27(月) 14:23:17
GPGPUって、
ベクトル演算器→たけーよ→グラボ使えるじゃね?→できるもんならやってみろ
の世界だろ。
0229デフォルトの名無しさん2006/03/27(月) 23:44:08
うんそう
0230デフォルトの名無しさん2006/03/28(火) 12:16:07
だからフレームバッファに描画さえすればhello worldとか言うのはおかしい
0231デフォルトの名無しさん2006/03/29(水) 09:04:50
うんこう
0232デフォルトの名無しさん2006/03/29(水) 17:33:43
>>230
あとはロックするコードだけ晒せばいい？
他には何かある？
そもそも DirectX 限定というはおかしいと思うのだが、そういう指摘は無いの？
それとも Hello World の定義が違うなら、>225 に書いた、「最初の演習問題の前」「変数や制御構文の前」とは違う定義をしてくれ。
0233デフォルトの名無しさん2006/03/29(水) 18:23:34
1+1, 1+2+3+...+10を計算するコード
0234デフォルトの名無しさん2006/03/30(木) 13:44:56
どちらか？ それとも２つとも？
0235デフォルトの名無しさん2006/03/30(木) 13:46:57
後者がいいな。ループも使うし。
0236デフォルトの名無しさん2006/03/30(木) 17:44:06
トリップサーチはどう？
02371/32006/03/32(土) 19:38:50
ほらよ。uudecode しな。こういう、ピクセル毎の処理量が違うのは、向いているとはあまり言えないと思うけどな。
begin 755 gpgpuhellobydx.cpp.gz
M'XL("#%7+D0"`W1E<W0P-P"M65MOV\@5?J8!_X>!@C4HFU8HV5)D.`E`290C
M6#>(E)5+`X&F1C83B61)ZN)L\[#*T^X"V\UNBWTI^@,*]&E1]*'H0X%]:("D
M_Z!HT8>BV]^P#STSPYMNL94FMB5RYLQWKG/FG,FM'NX;)D;NSQVOSY'/[:WM
MK5N&J0]&/8SN]@YZ1ZG+^PM#T\4QU^L9%AW;WG(]9Z1[J-A6U$;M3&ZI\L/M
MK4^WMQ#\*U<;DHJF`KH2T`L!.9>38W3[-E(O,?(<S73[EC/$/61;KN$9EHG@
M'7DP.<:.AZ>I.,A(0./C[:V7\'?+5Z)T4"J?E;MQSHCW!Q\^>MQZT$&_"(A@
M+CWW5FPT6B6E\EC.\.ED<GMK#H7P-W3L/GF*[H7*?+HOIK)]`?E?8DJ$SS3]
M%,-/]%(@&L95%JCL/@:ZLPXC?6,,?S'Z"'*@#Y2#N(']5$J&@W7OH'2$=M%%
MUP8+HWM(/([-E/`8C.G/0SBQ]T4J%4^]D1.0@?LKYB*),G+Z6HCDPEMCY"T2
MG='8*8SZ?>SXE&Q(N=1ZV%DD;QI3/&!3/G5LQ"<F0:Y!0*"Q9?20/L":.;)Y
M5&F;STUK8L(R`R5IG'!&'_'LC>.,_?LM#,0NYI,D=-<"T3<?(!Q<D(0@S$W.
M*;4T&QAG:8(9=FDX<LO2%/'H2OF'[L6Y->61;IFNA_1+S0%+P"!*(J))#;NN
M=H$+A$04R(3_42MT&Z<19+4E*^VJBHI2M5J0BJ>H8Y@]:])T+)U_T*F7!-2N
MU%4!=9I22ZH)J$J_?7,Y&(+&1.D`K%.I2\T*@:AIALFC!Y6ZHDKUHBS$'ZM-
M16T)R#`]'P;8%*N2HJ")?LQVR!`/7>SQ:&>B"T1\UWB!K3X_T9-4<D(RT5,#
MNV]VS!Z1%6(E$CQ.X;XH#C37K6M#$O.)"_O"'EWBP<!*$$NW\(7A>MBA-#QP
MH_8G>J/+B=F#%44':QYFV/S<>@$E$E2XU;]44!J3/*JWJU5T[Q[BHST:[`"&
M?\23Y-A52J==2()*I5$'-R9]5W*!JQ.Z9B+3`F_314A#T?[_F9E@P1-W"D>]
02382/32006/03/32(土) 19:39:06
MP@%T$]PLU]4N]9ZL`@\$06?;QPCF'V/'JN&AY5R!Q>EP:''ZQHS.T><4,P4F
MME%;;3F:4"::+<.^UTE2`)9*1VK*Y;)<5+NEBE*46J6(MJ#ISUF2*,,AI/DK
MRC6UVZZ?UAN=>F2[LE2IRJ7`<OOWF<'8=J%6DTI2$Q3JEN2R!)$LD+&2?*8^
M:LK=!U)5H)X4``U=^P]6%ENRI,I=I5%6.U)+[K(SJ=EJ%&5%J=1/;@846'%G
M?G-OY%(_<0=N#9+".B?3W.<;*\XUL)B?X7F4AU.&_H*V;44ZD;NE1W6I5BD*
M@0^D?"M_DB_DZ4"ST:A&MMT)DAB-\&5UWL?9,).HKQD#W$O=5"G@7VT43^52
MMP5QA`:6_ASW6F`>0@*GX[<_???N\W^__LWL[==__^8_RU:@HN[?K\(ZLHJF
MPIT(A>Y4GT<0I&NT6D3:3!6.U%8\27EP/)%C#;[NHCQ\[>T%W"*29XSD&9`<
MPE=$`K`PCQT;X+NZYGIW1Z9K7)BP&\D!L'N?CW1+V07#<Y-/D+%[B/8`#*HI
M8/>,BO?2%VNUN=KF(#+8^^T1(]W0(NOC5<%>&*S@G^C8O"[<8@LWC;0;;*`6
M-N&P5S7G@IQ,^6`+T0V3SA72N9-TKI7.T<$:;):*(M6:5;E;;]1E&FA0JF.V
M@_SZ8(,]-,?\8UIZ7BMF[K!\N8'!_P_!V/XN2DWE".F:[9+A>?P3[+''(DSS
M.X0H>1SD6-C^AFEX:!A/L><8MA%&(]<P+_P#A*Q*Q8HY*-U<TN[<I=E-"0Y<
M_D`00WUI.05*/\ED<T^I[*[MP-8#.%I$);Q+PP5D!S8>)'#+'%PA=V3;EN,A
MF[!"+BL-/Q$/IRDH$]8)P0P3F)>6;S?PJ%\'QDH_.X)6K)&C8](\D;.=2]AN
M]Z`K0GU`WZ![XW16HF2R6=)P9#/9(S&3SA_E<D>YPTSZ3O;H()?-9`YS^2/Q
MZ`[>)U2PG.3;<-7M7#9[D$5".@)-D[XE2Y#A)\;.X(QP&?T5?;"!9=F@P\@D
MQS_,LP7ZH`O;7;<LIR=R8S$UO0JQ8"K3@RSHAO!`.>AQ#N"/294HIEY<32<^
M_!,QE0+4IVCV._J<?CI[\_7W7YY^_J?9][/_SG[X]J?97V8_S'X_^Y%"#4<#
M"D3^=#%%N'+S,&]F?YS]^)D1GCGO4!Z=0X[][!F-92[ACLXY!Q1D?P'`&-SC
02393/32006/03/32(土) 19:39:25
MCH8DIS-&UIAS,I0)%34DHJ88V4#(K.I@&TP7J(IZ]B%$PD%JRF1TQ(`!ZWI,
M&W;L[.UK!71Z^]WX=1_4%EDKE$#GD$2>=P?87P^LI_YJCJ-SQXR.:``TOA72
M(16\(XHW^Q=\_-K[\A^SMU_]=O;FU<M7Q5?&JX?,-@Q#']H<59#B9`))XR!O
MOBG,_C#[,Y7R'0DJ\,@_9W\%7_PML`+#TGJ]R**90!ABS;U[*R@SC&%H6:#U
MB?;V8AK&W!S0<=1^^_L^U5";QJE"8PV,(60<2DL)(?F!EP(7T1#RI855+^(A
ME(X"Z)=6&$#IW%P`06@@SBJ*`HT>/P@\]D@DH[FI`FGK(2N>H>-SXZWRXJ0M
M.X[EU-P+-R2('P:$5G)=/#P?8)8[^*4\(KB>,\#F\D22;'.!0"@/I!*MOPOM
M$V&'"23L1+RC8R0Z1U:P7CH\0NJEJL<O=B(6]*A@:C<M2LPGDP%,G"Q^)<`M
MIMFY/$L3[;5%02RE\X@O=1JMTFZ2F6"53.SXG[M96&&<ZQ@M6^I:/0*1YO5_
M;V4PI]K&4B\`;"[R]659`9IW4]&QB?EK*Y4X[:9%2JP+7>69^)47CPYW_<XY
M?J69C#5;G59%E1OUZB-AU17JFI8K?MVT0=4X)]J&52-%/VM42I!&SOP;63]H
MYIKRN&BL/^)C-S;!72Y8@"?75KN[R9T0;D7OA58'U@HF'[`)AGBHVU<\B@DP
M#I\6!?91EYBSCH<QN:[SADV@>.")(4N907V]X,V0]US(W*CZGD/_F&T!Q"6_
M\HK_)E*1Q1]-F)*C39H..7>-,;OP::I=M561ZB=568&')BMFKY=L'ND#TL`Z
M$66S=\,T%%%NRAW*B+!N>/O%\%?E98G\MBU^W;'NKJ/>@"W74A]UV\V2I,IK
M;+<,^"$Y).JEQ,,\Z4H2].KU)E<B-[H3B5HS*%7T2X<G'9H("2?Q20]!Z[7^
MSL2]A'[MNDL3/YO0!+*>573]^C)F1?A*KHGPT+;Q&Y3W>^&#[UIB_Z5`Y_UI
-D5W;_P^%I7C`EAP`````
`
end
0240デフォルトの名無しさん2006/03/32(土) 20:06:09
乙。アセンブリでシェーダ書いてるあたりがプロ臭い。
0241デフォルトの名無しさん2006/03/32(土) 20:49:58
プロならコードを出すわけがない。
著作権は自分にないからな。
0242デフォルトの名無しさん2006/03/32(土) 20:53:22
普通にアプロダにあげてくれないか？
0243デフォルトの名無しさん2006/03/32(土) 21:08:06
おまえらuudecodeもできないの？
俺はLinuxだから標準でできるけどコンパイルはできないというふざけた奴だ。
0244デフォルトの名無しさん2006/04/02(日) 00:48:55
乙。
D3DTSS_TEXCOORDINDEXにハマったが、ようやく2つのテクスチャを足せるようになった。
俺のグラボじゃPixelShader1.xだし8bitしか対応してない。ちっ。
0245デフォルトの名無しさん2006/04/22(土) 04:42:08
おまえらもしかしてコレ↓で十分だったのか？
http://www.gpgpu.org/developer/#tutorial
散々叩いといてさ。

どーでもいいけど PS3 か 360 の仕事くれ。安くてもいいから。
ＤＳはもう飽きた。仕事が来ても倍の人月でふっかける。
0246デフォルトの名無しさん2006/04/23(日) 23:24:33
brook良さげですよ。環境構築が面倒ですが。。
http://gpgpu.jp/category/1411192.html
0247デフォルトの名無しさん2006/04/24(月) 01:00:04
Linuxで開発する方法教えてください。
Windowsってキモクて真で欲しいのでお願いします
0248デフォルトの名無しさん2006/04/24(月) 01:52:02
Linuxでコンパイルする。
それだけ。OpenGL系ならそれでいいじゃん
0249デフォルトの名無しさん2006/04/24(月) 08:47:21
>>247
glut 使ってコーディングできるなら
http://www.gpgpu.org/developer/#tutorial
へ池。

それができないなら
くだすれOpenGL（超初心者用）
http://pc8.2ch.net/test/read.cgi/tech/1131208166/l50
OpenGLスレ Part10
http://pc8.2ch.net/test/read.cgi/tech/1141034983/l50
あたりへ行け。
0250デフォルトの名無しさん2006/04/24(月) 15:14:53
>>246
アラッ、いいページですね
参考になりました
0251デフォルトの名無しさん2006/04/25(火) 01:44:54
brookコンパイルしたいLinuxでしたいです。
Windowsはきもくて嫌ですお願いします
0252デフォルトの名無しさん2006/04/25(火) 22:38:48
>>251
つ http://www.gpgpu.org/w/index.php/Brook#Installing_Brook
0253デフォルトの名無しさん2006/05/09(火) 02:04:36
ﾓｼﾞﾚﾂｦｱﾂｶｲﾀｲ
0254デフォルトの名無しさん2006/05/11(木) 00:56:38
１文字１文字をfloatにするとか？
いずれにしろどう処理したいかによるか。
0255デフォルトの名無しさん2006/05/11(木) 01:50:32
60ＧＢのデータをソートするのに90MB/secって遅すぎだろ
大して速くないよなＧＰＧＰＵ
0256デフォルトの名無しさん2006/05/11(木) 02:13:37
文字列処理ライブラリを作りたいのか？
それとも探してるのか？
0257デフォルトの名無しさん2006/05/11(木) 02:14:21
文字列処理ライブラリを作りたい　ＹＹＹＹＹＹＹＹＹＹＹＹ
探している　ＮＮＮＮＮＮＮＮＮＮＮ
という感じです。最近徹夜でテンションがＡＧＥＡＧＥです
0258デフォルトの名無しさん2006/05/11(木) 12:00:41
基本的には複数の文字列に対して一斉に同じ関数を適用することしかできないがそれでいいのか？
（コマンドリストを作るとかもできなくはないが）
シェーダアレイ内で一番遅いピクセルに律速されるのでばらつきが大きいデータはパフォーマンスが出ないがいいか？
DirectX のシェーダアセンブラしか知らない俺でよければ手伝えるかもしれないが。
0259デフォルトの名無しさん2006/05/12(金) 01:16:26
うーん、ちょっとまだ解ってないこと山積みだけど
あるデータないから、特定のデータを探すとかができればいいですよね
たとえば特定の方法で解析すると意味ができるようなものとか

ツリー構造のデータ
線形リストデータ
そんな感じのデータを検索したりすることができないかと考えていろいろ調べてはいますが結果はいまだ０
0260デフォルトの名無しさん2006/05/12(金) 01:46:29
>>259
strchr ならできるが、フェッチ量を考えるとかなり具合が悪い気がするな。
同様に正規表現検索なんかも、DFA にしたのをシェーダ言語にコンバートできそうな気もするが、汎用 CPU みたいな気合入ったキャッシュ機構がないと具合が悪そう。
ツリーやリストはまだなんとかなりそうかな。

つーか、いろいろ調べてるなら、アセンブラしか使えない俺は用無しか。
0261デフォルトの名無しさん2006/05/12(金) 01:56:44
アセンブラでもいいんですけど、何せ効率が悪いので
できれば、C++からインラインで留めておきたいと考えてます
0262デフォルトの名無しさん2006/06/16(金) 08:52:22
GPUとCPUで、得意不得意な処理があると聞きます。
GPUが得意な処理はCPUの何倍も高速に処理できると聞きましたが
具体的にはGPUが得意な処理と言うのはどういったものなのでしょうか？

動画のエンコードやデコード、ファイルの圧縮・解凍や、ハッシュ生成や暗号化などが高速なのでしょうか？

0263デフォルトの名無しさん2006/06/16(金) 11:58:05
依存性の少ないストリームデータを横に並べてベコベコ叩くような処理が得意です。
0264デフォルトの名無しさん2006/06/16(金) 18:49:30
ぶはは、馬鹿ばっか（核爆）
0265デフォルトの名無しさん2006/06/16(金) 19:03:32
自称研究者の単なる情報収集家とかいるしなｗ
0266デフォルトの名無しさん2006/06/16(金) 21:13:46
日本の大学でgpgpu系の研究室って有りますか
0267デフォルトの名無しさん2006/06/16(金) 21:30:24
>>266
無い。日本の研究者連中はどいつもこいつも馬鹿。
素直に欧米の大学行け。
0268デフォルトの名無しさん2006/06/16(金) 22:10:31
別にGPGPUの研究してないから馬鹿ってわけでもないと思うが・・・
むしろ、GPGPUの研究してるようなやつの方が有る意味馬鹿に見える。
もちろんこの場合の馬鹿は、変態的な手段で目的を達する事に喜びを得る馬鹿って意味だけどな。
0269デフォルトの名無しさん2006/06/16(金) 22:31:22
GPGPUﾊｧﾊｧ…
0270デフォルトの名無しさん2006/06/20(火) 16:41:54
こと半導体に関しては、大学よりも企業の研究所のほうがレベル上なんじゃないの？
0271デフォルトの名無しさん2006/06/21(水) 00:17:43
>>270
誤爆？
02722702006/06/21(水) 09:49:22
>>271
誤爆じゃねって
ぶっちゃけどーなの？
0273デフォルトの名無しさん2006/06/21(水) 11:34:09
>>270
GPGPUは半導体プロセスよりも情報処理の方が分野が近いとおもふ
0274デフォルトの名無しさん2006/06/22(木) 09:55:34
いいたいことはわかる。
ハードウェアアーキテクチャ屋ね
0275デフォルトの名無しさん2006/06/22(木) 12:18:19
一時はもてはやされてたが、今どーなんだ？
どんなに素晴らしいアイディアでも普及しなきゃ意味ないからなぁ
0276デフォルトの名無しさん2006/06/22(木) 15:49:36
誰かGPUをC++から扱う事が出来るクラスライブラリのSh使ったことある？
関連書籍も無いし、途方にくれてる・・・orz
0277デフォルトの名無しさん2006/06/22(木) 16:02:07
ぐぷぐぷ
0278デフォルトの名無しさん2006/06/22(木) 16:24:42
>>277
俺もスレタイ見てそう読んだ
0279デフォルトの名無しさん2006/06/23(金) 02:33:40
>>275
普及ってお前、どのレベルで言ってんの？ HPC が必要な分野なんてそうないだろ。
マジレスついでに言っておくと、ゲームでよく使われてるよ。
0280デフォルトの名無しさん2006/06/23(金) 21:07:00
http://www.geocities.jp/takashi_drive2005/gpuindex.htm
皆さんの参考になりませんか？俺が書いた訳じゃないけど。
0281デフォルトの名無しさん2006/06/24(土) 02:40:17
>>280
続きが見たい。
0282デフォルトの名無しさん2006/06/24(土) 13:33:19
情報処理学会あたりで検索かけると何件かネタが見つかる
ttp://www.bookpark.ne.jp/ipsj/
著者なり研究室なりをたどれば少しは情報が出てくるんじゃなかろうか
0283デフォルトの名無しさん2006/08/03(木) 08:48:51
あげてみる
0284デフォルトの名無しさん2006/08/03(木) 20:15:00
GPGPUはれいめい期なの？
参考書籍はないの？
0285デフォルトの名無しさん2006/08/04(金) 18:49:12
GPUはあと3年もすればコプロセッサという名前になります。
0286デフォルトの名無しさん2006/08/04(金) 19:35:23
AMDにそんな業界を作り変える力は無いぞｗ
0287デフォルトの名無しさん2006/08/04(金) 22:00:29
intelとnVidiaはどうするんだろう？
0288デフォルトの名無しさん2006/08/05(土) 02:36:55
Intelは業界１位のグラフィックスチップメーカー＆CPUメーカー
nVIDIAは業界１位の単体グラフィックスチップメーカー

AMDは、グラフィックスチップ部門を持たないメーカー＆２位のCPUメーカー
ATiは、業界２位の単体グラフィックスチップメーカー


どう考えても、AMDとATiが組んだところでそんな業界の仕組みを変えれるとは思えない。
２位同士が組んでどうやって１位同士が確立しているシステムを潰すってんだ。
0289デフォルトの名無しさん2006/08/05(土) 20:00:12
最終的にはIntelがそういう流れを決定付ける。
0290デフォルトの名無しさん2006/08/15(火) 22:50:30
まあな
0291デフォルトの名無しさん2006/08/16(水) 02:06:00
GPGPUで動画のエンコードとか聞いたけどさ
そういう前後の依存関係が関係する処理ってGPUで出来るの？
一旦、処理した内容をメインメモリに戻して、その結果を元に次の処理って事をしないといけないと思うんだけど・・・。
0292デフォルトの名無しさん2006/08/16(水) 02:51:53
動画圧縮における「前後フレームとの依存関係」と
アルゴリズムにおける「データの依存関係」は違う。
0293デフォルトの名無しさん2006/08/27(日) 04:43:49
GPGPU的Hello Worldとして何から手をつければいい？
ちなみに現時点でGPGPUについては概要しか知らないんだが。
0294デフォルトの名無しさん2006/08/27(日) 07:27:52
ハロワルは視覚的にわかるものが好ましいから
適当なテクスチャデータ→GPU→ピクセルズーム→メインメモリ→BMP出力
こんな感じでどうよ？
0295デフォルトの名無しさん2006/08/27(日) 15:29:09
>>293
http://www.gpgpu.org/developer/#tutorial
http://www.gpgpu.org/w/index.php/Brook#Installing_Brook

このスレで Hello World の話題が出たことあるんだから、それを踏まえた上での質問をして欲しいものだが。
0296デフォルトの名無しさん2006/08/27(日) 18:12:14
ATIのGPUがFolding@homeに参戦
http://slashdot.jp/articles/06/08/27/0239247.shtml

こういうのが本命かな
0297デフォルトの名無しさん2006/09/09(土) 15:59:23
ttp://channel9.msdn.com/wiki/default.aspx/Accelerator.HomePage

Accelerator provides a high-level data-parallel programming model as
a library that is available for all .Net programming languages.
The library translates the data-parallel operations on-the-fly to optimized
GPU pixel shader code and API calls. Future versions will target multi-core cpus..
0298デフォルトの名無しさん2006/09/10(日) 01:35:24
>>297
ぱっと見ではプログラム中の一部の処理をピクセルシェーダに置き換えられるようにしただけに見えるんだが
どうも要領を得ないので読み直すか
0299デフォルトの名無しさん2006/09/11(月) 00:48:37
ttp://www.shader.jp/xoops/html/modules/wordpress/index.php?p=326
0300デフォルトの名無しさん2006/09/20(水) 11:11:02
http://www.gpgpu.org/
が見えないんだけど、どうしちゃったんだろ？
0301デフォルトの名無しさん2006/09/26(火) 19:47:06
http://journal.mycom.co.jp/articles/2006/08/01/siggraph01/004.html

DX10では今までと比べ物にならんほど汎用性が増すみたいだね。
0302デフォルトの名無しさん2006/09/28(木) 22:51:28
浮動小数点数のバッファに1.0より大きな値を記録する事は出来ないのでしょうか。
試してみたら1.0で飽和されてしまって。
0303デフォルトの名無しさん2006/09/29(金) 08:49:41
シェーダー言語使ってるかどうかとか、情報少なすぎ。
どっかで8bitとかのフォーマットに変換されてたりするんじゃないか？
03043022006/09/29(金) 12:27:41
>>237を元にしてD3DFMT_R32Fを使いテクスチャを2枚にして
ps_1_1
tex t0
tex t1
add r0, t0, t1
してます。

結果が1.0以下になる演算では小数で解が得られているので
8bitに変換されているというより1.0で飽和しているという印象を受けました。
03053022006/09/29(金) 16:04:33
ps_2_0
dcl t0
dcl_2d s0
dcl_2d s1
texld r0, t0, s0
texld r1, t0, s1
add r0, r0, r1
mov oC0, r0

にしたら上手くいっているようです。
2枚のテクスチャを加算するピクセルシェーダのコードはこれで間違いないでしょうか。
0306デフォルトの名無しさん2006/09/30(土) 01:13:47
俺の持っているのは DX9 のだが、マニュアルの
[DirectX Graphics] - [リファレンス] - [シェーダ リファレンス] - [ピクセルシェーダ 1_X] - [レジスタ ps_1_X]
と
[DirectX Graphics] - [リファレンス] - [シェーダ リファレンス] - [ピクセルシェーダ 2_0] - [レジスタ ps_2_0]
のテンポラリレジスタのところでレジスタ精度を見てみると、ps 2.0 は浮動小数点数だが、ps 1.1 は D3D8CAPS.MaxPixelShaderValue を上限とする小数部 8bit の固定小数点数の可能性があることがわかる。

君の持っているカードもわからないのに、何故具合が悪かったかなどわかりようもないが、305 のコードは合ってる。
0307デフォルトの名無しさん2006/11/09(木) 19:24:06
http://pc.watch.impress.co.jp/docs/2006/1109/kaigai316.htm
0308デフォルトの名無しさん2006/11/11(土) 08:31:59
>>307
これで、おれのようなへっぽこコード書きでも使えるようになった。
0309デフォルトの名無しさん2006/11/11(土) 12:33:04
Geforce8800GTXのSLIで1TFlopsが30万円くらいだしすげーよな。
はやく開発環境ほすぃ
0310デフォルトの名無しさん2006/11/11(土) 15:54:43
ここまでくると、もうGPGPUとは呼べないよね。
0311デフォルトの名無しさん2006/11/11(土) 17:01:11
今までシェーダーでやってた人が馬鹿みたい
メモリー周りはどうなってるのかな？
0312デフォルトの名無しさん2006/11/11(土) 17:11:54
そんなことよりもなぁ、演算プロセッサボードで作ってた連中が不憫で不憫でw
0313デフォルトの名無しさん2006/11/11(土) 17:14:11
あーもう要らないね、GPU内で全部計算できるし、転送しなくてすむし。
グラフィック以外の計算にも使えそうなキガスルがどうだろう。
0314デフォルトの名無しさん2006/11/11(土) 17:17:43
>>313
フーリエ変換に使えないか、調査予定。巧くすれば、プロセッサボード屋に払う分をこっちの仕事にできそうな希ガス。
0315デフォルトの名無しさん2006/11/11(土) 18:13:55
GPU内でDSP的でない処理がモリモリできるのであれば、
メインメモリとの転送量も少なくできるかな。
もしそうなら、x16じゃなくてx1レーンに沢山のっけてもいいかも。
できるかどうか知らんけど妄想。
0316デフォルトの名無しさん2006/11/12(日) 18:44:29
Cで扱えるようになるっていうのは、ハードウェア的な新機能なの？
旧型のGPUも、ドライバーで扱えるようになるのかな？
0317デフォルトの名無しさん2006/11/12(日) 19:10:51
GPUのアーキテクチャーが大きく変わったことでCでプログラミングできるような
構造となった。だからコンパイラー付き

よって旧型チップじゃ使えないよ。
0318デフォルトの名無しさん2006/11/12(日) 20:08:45
なるほど・・・、THX
ドライバ側っつーか、ライブラリ側でかなーり頑張れば旧GPUも対応出来そうな感じもするんだけどなぁ。
もちろんパフォーマンス的なものが変わってくるだろうけど。

0319デフォルトの名無しさん2006/11/12(日) 20:36:07
無理。
0320デフォルトの名無しさん2006/11/12(日) 20:54:48
これってやっぱ単精度なんだよね？
0321デフォルトの名無しさん2006/11/13(月) 14:13:59
ちゃんと嫁よ
プロセッサ内蔵してそこが実行してるんだから旧も新もあるか。
0322デフォルトの名無しさん2006/11/14(火) 23:08:50
>>320
（独自）Cコンパイラ使えます
けどdouble使えません

単精度浮動小数演算器に桁上げ回路？くっつけて
できないのかねぇ？
ソフト的にやったら性能ガタ落ちだろうし。
0323デフォルトの名無しさん2006/11/14(火) 23:37:33
http://www.4gamer.net/news/history/2006.11/20061113170123detail.html

CUDAの詳細どぞ。
0324デフォルトの名無しさん2006/11/15(水) 10:26:20
ほんと今までグラフィック屋さんでもないのにCgいじくってひーひー言ってたのがｳﾞｧｶみたい…
まぁ、8800は素直にすげーと思うけど
0325デフォルトの名無しさん2006/11/15(水) 11:06:38
これもGPGPUですか？
http://www.itmedia.co.jp/news/articles/0611/14/news102.html
0326デフォルトの名無しさん2006/11/15(水) 19:37:40
ソフトウェアレンダとハードウェアレンダの境目が取っぱらわれるわけでもないのかな?

とりあえずこの傾向が進めば、GPUの扱いは
Cバス用のPC-9801-16に乗ったMC68kみたいになるわけだな。
0327デフォルトの名無しさん2006/11/15(水) 20:08:42
ソフトレンダはdoubleで計算してるからねぇ。
floatでレイトレったらすごい結果になるしｗ
0328デフォルトの名無しさん2006/11/17(金) 18:17:32
Mpegのエンコードにおける、動きベクトルの算出に
GPUが使えたらと考えています。
参考になるようなサイト等ありましたら教えてください。
0329デフォルトの名無しさん2006/11/28(火) 04:54:51
GPGPUなMP3エンコーダー作ってください
0330デフォルトの名無しさん2006/11/29(水) 08:20:07
http://www.kvraudio.com/forum/viewtopic.php?t=153073
こんなのきたよ
GPGPUでサウンド用DSP的なことをやるみたい。
この場合はDelayだけだけどｗ
0331デフォルトの名無しさん2006/11/29(水) 10:23:22
オフセットしてaddするだけやん！
0332デフォルトの名無しさん2006/11/29(水) 13:11:45
CUDAがでてきたから来年にはGPGPUの状況も変わるかもね。
0333デフォルトの名無しさん2006/12/06(水) 00:15:51
うちの大学で、GPUでレイトレやってる人がいる・・・・
0334デフォルトの名無しさん2006/12/06(水) 21:37:13
レイトレなんて久しぶりに聞いた単語だ。
0335デフォルトの名無しさん2006/12/06(水) 23:46:12
>>333
一昨年俺がやったぜ
GeForce6シリーズなら十分
SM2.0だとループができないから
6800GT初売りに予約して買った。
研究費だけどね。

今だと、海外もボコスカ論文出てるから
新規性アピールするのむずいかな。
あ、研究とは言ってないのか
0336デフォルトの名無しさん2006/12/07(木) 13:15:17
ごめん、GPUじゃなくて、PPUっぽい・・・
0337デフォルトの名無しさん2006/12/07(木) 14:57:30
GPUPPURか
http://d.hatena.ne.jp/gpuppur/
最近進捗ないけどどうなんだろうね。
0338デフォルトの名無しさん2006/12/07(木) 23:02:24
ファミコンのPPUを演算に使うのは難しそうだけどな。
0339デフォルトの名無しさん2006/12/11(月) 00:54:33
ソフト的に倍精度の研究やってる俺がきました
2007年後半にハード的に実装されるみたいですねー
0340デフォルトの名無しさん2006/12/11(月) 21:46:48
>>337
レイトレーシングでStanford bunnyとかレンダリングできるけど、遅い。
0341デフォルトの名無しさん2006/12/12(火) 00:59:27
>>339
あの，大変申しにくいのですが
今年のSIGGRAPHのポスターでドンピシャなのが…
Extended-Precision Floating-Point Numbers for GPU Computation
http://cs.allegheny.edu/~thall/

悪気はないんです，担当教官から言われるよりはよっほどマシだと思いますし．
頑張ってください
0342デフォルトの名無しさん2006/12/12(火) 01:36:50
>>342
俺ｵﾜﾀ＼(＾o＾)／
0343デフォルトの名無しさん2006/12/12(火) 01:48:58
読んできました。
難しい内容じゃないし誰かがやっててもおかしくないですよね
近々中間発表があるのでそれまでになんとかしないと・・・
情報提供ありがとうございましたm(_ _)m
0344デフォルトの名無しさん2007/01/14(日) 22:05:03
すみませんお聞きしたいことが
nvidiaのCg言語はATIのチップ上でも動くのでしょうか？

GPUプログラミングをやってみたいと思っているのですが
手持ちがATIしかなくて
0345デフォルトの名無しさん2007/01/15(月) 20:05:39
>>344
ATIのチップでやったことないけど、できたと思う。
NVIDIA SDKでも落としてサンプルを走らせてみたらいいと思うよ
0346デフォルトの名無しさん2007/01/16(火) 01:49:39
>>345
ありがとうございます。試してみますー
0347デフォルトの名無しさん2007/02/20(火) 09:13:53
CUDA使ってる人居ません？
興味があって、GF88GTSのメモリが少ないやつを無理して買ってきたんですけど
コンパイラが手に入らない・・・orz

もしかして、ベータテスターや関係者じゃないと、まだ配ってもらえない？
0348デフォルトの名無しさん2007/02/20(火) 09:19:58
落としてないから知らないが、CUDA Toolkit Version 0.8に
コンパイラ入ってないの？

＞The Toolkit includes standard FFT and BLAS libraries, a C-compiler for the NVIDIA GPU and a runtime driver.
って書いてあるけど。
0349デフォルトの名無しさん2007/02/20(火) 10:24:16
GPUで汎用コンピューティングを行うスレ
http://pc10.2ch.net/test/read.cgi/tech/1167989627/16

http://developer.nvidia.com/object/cuda.html
0350デフォルトの名無しさん2007/02/20(火) 15:34:52
>>347
お、動いたら感想よろしく。
0351デフォルトの名無しさん2007/02/20(火) 17:10:05
昨日か一昨日くらいにCUDAコンパイラのパブリックベータが始まった。
誰でも落とせるようになったはず
03523472007/02/21(水) 12:08:21
情報THXです！

でも、うちx64のVistaマシンなので…orz
まだ開発環境は32bit版しか出てないみたいで、ドライバに強く依存するらしく32bitアプリ側からは64bitドライバが見えないようです。
ドライバが入ってないというメッセージが出て、インストールすら出来ない…orz

早く64bitバージョンでませんかねぇ・・・。
0353デフォルトの名無しさん2007/02/21(水) 13:34:37
>>352
英語版のnVIDIAのサイトからGO!
日本語版のサイトのvistaドライバのページは何故かNot Fount
多分最新のドライバ入れれば、有効になると思われ。
Vistaでは試してないけど、XPのx64でCUDA SDKは使えたから・・・(ただしグラボがGF66なのでインストールしただけｗ)
0354デフォルトの名無しさん2007/02/21(水) 14:51:53
Supports Linux and Windows XP operating systems

とかいてあるからVistaはまだ無理なのかも
0355デフォルトの名無しさん2007/02/21(水) 14:54:32
NVIDIA CUDA Homepage
http://developer.nvidia.com/object/cuda.html

0356デフォルトの名無しさん2007/02/22(木) 11:02:37
Vistaまだっぽいな。。
0357デフォルトの名無しさん2007/02/24(土) 22:27:08
とりあえず動かしてみたいけどG80廉価版待ち
0358デフォルトの名無しさん2007/02/25(日) 13:00:56
初歩的な質問です。
GPGPUにチャレンジしてみようと思い、BrookGPUを使ってるんですが
ループの並列化がイマイチどのようにすればいいかがわかりません。

例えば、ループの部分で前回回した処理結果に加算を行う処理をする場合
前後関係が出てくるので、GPGPUに適した並列化は出来ないと思うのですが、こういうのは何か解決方法があるのでしょうか？
0359デフォルトの名無しさん2007/02/25(日) 14:02:00
int i;
float x[1024];
x[0]=1;
for(i=1; i<1024;i++){
x[i]=x[i-1]*i;
}
みたいなやつの事？
そもそも、この手のはGPGPUに向かない。
0360デフォルトの名無しさん2007/02/25(日) 14:15:44
>>358
依存関係がなくなるように計算式を変更するか、
並列させる方向を変えるような工夫が必要。

でもって、そういう工夫は実はSSEを使ったベクタ化やOpenMPによる並列化にも適しているので、
ますますGPUを使うメリットが活き難くなる罠。
0361デフォルトの名無しさん2007/02/25(日) 18:34:02
並列計算はいいんだけど
計算の中間結果を保持する為の
テンポラリバッファが大きくなって
すぐ頭打ちになりそうなイメージ
0362デフォルトの名無しさん2007/02/25(日) 21:41:38
演算精度が悪すぎて使い物にならない印象しかないんだが…。
0363デフォルトの名無しさん2007/02/25(日) 22:13:06
明日G80にダイブしてみるよ！
飽きたら速攻で売り払わないと
0364デフォルトの名無しさん2007/02/25(日) 23:03:53
>>362
http://mypage.odn.ne.jp/www/k/8/k8_hammer_trans/files/Hammer-Info.html
もうじき倍精度サポート
現状でも型としてはサポートしてるからコーディングは可能
0365デフォルトの名無しさん2007/02/26(月) 22:06:57
>>359-360

for( i=0; i<height; i++ ){
for( j=0; j<width; j++ ){
a=img[i][j]+img[i-1][j]+img[i+1][j];
}
}

こんな感じのもGPGPUには向かないってこと？
0366デフォルトの名無しさん2007/02/26(月) 22:15:27
その処理は、コンパイラが優秀ならばCPUでもGPUでも
まあまあ効率よく実行されそうだが。
0367デフォルトの名無しさん2007/02/26(月) 23:57:20
>>365
その処理は問題ない。むしろ超得意なくらい。
0368デフォルトの名無しさん2007/02/26(月) 23:58:42
>>365
それは前後の処理結果は関係ないでしょ。
imgに代入するならともかく、imgと言うデータがあらかじめあるのなら、そのままVRAMに転送すりゃいいわけだし。
0369デフォルトの名無しさん2007/02/27(火) 12:16:50
>>365 を Cg で書くとどんな感じ？
0370デフォルトの名無しさん2007/02/27(火) 12:25:46
今はCgよりCUDAの方が。。。
まぁ古いGPU(俺を含めて)の人には仕方ないが。
0371デフォルトの名無しさん2007/02/27(火) 12:48:48
>>369
kernel void func(float v1<>, float v2<>, float v3, out float o<>){
o=v1+v2+v3;
}
int main(void){
int i;
float img[height][width];float a;
float v1<width>;float v2<width>;float v3<width>; float o<1>;
for(i=0;i<height; i++){
streamRead(v1, img[i]);streamRead(v2, img[i-1]);streamRead(v1, img[i+1]);
func(v1,v2,v3,o);
streamWrite(o, &a);
}
}

BrookGPUで書くとこうかな。そのままCg用のコードを生成してくれるはず。
でも、このコード、aは上書きだし、0から始まる変数でi-1とかやっちゃってるし、色々アレだね。

そういえば、BrookGPUでループ中にstreamReadを大量にやると、VRAM食いつぶしてマシンがフリーズするな。。。
何かVRAMの内容を開放する関数は無いのかな？
0372デフォルトの名無しさん2007/02/27(火) 14:02:44
じゃあCUDAで書くとどうなるの？
0373デフォルトの名無しさん2007/02/27(火) 14:32:25
>>371
手抜きするなーｗ
外側のループもはずせるだろ。

いや、面倒だから俺はやらないけどなｗ
VRAMは自動開放だからな…、俺もよくフリーズさせてしまう。正確にはフリーズじゃなくて単に低速化するだけなんだろうけど
プロセスも殺せなくなるのが嫌だな
0374デフォルトの名無しさん2007/02/28(水) 01:06:47
Brookでやるからだよ。
頑張って自分でCgとか使ってゴリゴリ動的にメモリを管理するんだ。
って言うか、あれは隠蔽されすぎてて何やってるのかわからんし、パフォーマンスが出るような組み方ができないので
遅すぎる。BrookGPU使ってCPU処理より速い処理ってかけるの？どう頑張ってもReadBackである意味速度差がつけられちゃうよ。
0375デフォルトの名無しさん2007/02/28(水) 01:17:19
何度見てもスレタイをゲプゲップと読んでしまう
0376デフォルトの名無しさん2007/02/28(水) 02:16:30
ぐぷぐぷってよんでる
0377デフォルトの名無しさん2007/02/28(水) 04:54:13
intからfloatへの変換で+/-32768.0の範囲へ正常に変換できる様にGPUで計算したいのですが
CPUだと、
hoge*(1.0 / ( 1L << (8 * sizeof(int) - 16)));
一般的なWintel環境だと、hoge*(1.0 / (32768.0));
だと思うんですが、GPUだとこのままだとint型とfloat型の扱いの違いか、正常に変換出来ません。
GPUでやる場合、どういう風にすればいいのでしょうか？
0378デフォルトの名無しさん2007/02/28(水) 05:24:56
あ、ｽﾏｿ
単純ミス。。。

GPU側にfloatで値を渡してたから、2重に変換されてた・・・
0379デフォルトの名無しさん2007/02/28(水) 14:07:17
GPUにint型をfloatで送っちゃった時点で、桁落ち発生するでしょ。
0380デフォルトの名無しさん2007/02/28(水) 15:29:00
桁落ちするの？
0381デフォルトの名無しさん2007/02/28(水) 21:34:28
assert((float)0x7FFFFFFF != (float)0x7FFFFFFE);
0382デフォルトの名無しさん2007/02/28(水) 22:11:09
Brookもint型が扱えればな…。
floatとintだと、個人的にはfloatの方が高度なものだと思うんだけど
なんで、float扱えて、int型が扱えないのかなぁ・・・
0383デフォルトの名無しさん2007/02/28(水) 22:47:15
>>377
キャストしてGPU側に送って、GPU側で更にint型にキャストじゃ駄目なん？
って、GPGPUの言語名に使ってるかわからんけど、大抵intは無理なんかな
0384デフォルトの名無しさん2007/03/01(木) 16:20:02
ところで、おまいらAMDのフュージョンは期待してますか？
0385デフォルトの名無しさん2007/03/01(木) 16:29:50
AMDはコンパイラが期待出来ないから駄目
ここは嫌でもIntelやnVIDIAと共同で第3機関を作り、命令セットの仕様を管理させた方が良い。

じゃなきゃ3D NOWの二の舞さ。
どうせIntelもGPUコアとの統合を考えてるんだろ？
そうなった場合、どうせどこかで命令セットが共通化するんだから(しなかったら終わってる)
最初からそういう機関を作っとけよ。
0386デフォルトの名無しさん2007/03/01(木) 17:39:38
そうなるよりチップセットにプログラマブル演算機能があった方がいいな。
メインメモリへ近いしCPUである程度処理して
並列化できる処理ではCPUがそのメモリアドレスを投げて
結果をCPUに戻すかGPUなどのバスに転送させる。
定数時間で出来る処理ならメモリ転送の代わりにできる。
0387デフォルトの名無しさん2007/03/01(木) 17:45:11
チップセットにCPUくっつけたらいいんじゃね？
0388デフォルトの名無しさん2007/03/01(木) 17:51:27
>>387
すでにAMDのCPUはメモリに直接つながってるからその状態では。
0389デフォルトの名無しさん2007/03/02(金) 00:22:20
>>385
> じゃなきゃ3D NOWの二の舞さ。

AMD64はよくがんばったと思わないか?
0390デフォルトの名無しさん2007/03/02(金) 00:29:55
あれは先にIA64が大コケして自爆しただけ。
0391デフォルトの名無しさん2007/03/02(金) 00:48:26
IA-64はよくｶﾞﾝｶﾞｯﾃﾙお

Itanium2プロセッサベースのサーバ上で動作するアプリケーションの数が1万種類を超えた
http://www.itmedia.co.jp/enterprise/articles/0610/24/news002.html
Itaniumベースのサーバが急成長を続けており71.5%成長で11億ドル市場
http://journal.mycom.co.jp/news/2007/02/27/104.html
Itanium搭載サーバ、売上ベースのシェアが国内RISCサーバの6割相当に拡大
http://www.rbbtoday.com/news/20070301/39100.html
Montecito搭載、HP Integrity SuperdomeがTPC-Cで世界記録
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
0392デフォルトの名無しさん2007/03/02(金) 01:12:33
>>389
あれは殆どマイクロソフト主導じゃん
ＭＳの戦うプログラマの人がAMD64自体の開発に関わってたし

後は、あれはあくまでx86命令の拡張で、今までのCPUの延長線上のものだが
今回のフュージョンは、アーキ的には全然比べ物にならないくらいの大改造だから…
0393デフォルトの名無しさん2007/03/03(土) 03:45:34
CPUコアに統合されれば、GPGPUの最大の問題点であるReadBackの遅さが解決するな。
そもそも、CPUの命令に自然に溶け込む形みたいなので、GPGPUとか意識せずとも、勝手にコンパイラがやってくれそうな気もする。
0394デフォルトの名無しさん2007/03/04(日) 00:53:22
粒度はどんなのになるんだ？
現行GPUでいうところ quad とか batch とかにあたるもの。
0395デフォルトの名無しさん2007/03/04(日) 01:06:43
自分でループ展開して並列化して、各GPUをプログラマに管理させたりしてｗ
まぁ、コンパイラが勝手にやってくれるんじゃないかな。
それ以外の場所は、一般的なクラスタリングシステムみたいにやってくれるって事はないと思われ
そういうことは研究されてるけど、まだまだ一般的なコンパイラ1発でやってくれる仕組みは完成しているとは言いがたい。
最適な粒度をコンパイル時に調べてくれるとかやっても、別環境で実行する場合変わるしなぁ。



0396デフォルトの名無しさん2007/03/04(日) 12:47:40
いや、俺が知りたいのは、それぞれのユニットがプログラムカウンタを持つのか、コプロセッサ命令でシェーダアレイコントローラに命令するのか、ということなんだ。
全部のユニットにプログラムカウンタがあったら、そりゃサブプロセッサが沢山載ったマルチコアでしかないじゃん。
コプロセッサ命令になるにしても、拡張命令で１度に１つのユニットに１命令送るだけじゃ意味ないから、適当なグルーピングが必要だと思うんだけど。
x86ISAの拡張ってんだから、後者ではあるんだろう。
で、その粒度はどんなのになるんだろうな、と。
>395 の話題も面白そうだけど、他のプロセスなりスレッドとのユニットの取り合いとかも考えるとやってらんないね。
0397デフォルトの名無しさん2007/03/04(日) 15:14:04
偉そうな口調で頓珍漢な事言ってる人は、出て行って欲しい。
んがぁ、無理なんだよね。

ひろぽんは、殺伐とした方が情報の濃度が上がるとか言うけど、
白痴や馬鹿が沢山いるのに、そりゃああり得ない話。
頓珍漢なこと言ってると理解出来るレベルの人にとっては、
その情報って情報価値を持たない情報だったりするし。
0398デフォルトの名無しさん2007/03/04(日) 15:27:13
日本語でおｋ
0399デフォルトの名無しさん2007/03/04(日) 15:28:36
ウォッカはストロワヤが一番。やっぱりウォッカはロシアだね。
スレ違いスマソ。
自分の、これはダメかもわからんねは、
バイクで50キロぐらいで2車線目を走っていた。
するといいきなり目の前に1車線目に止まっていた車が右に、
フルブレーキするまもなく追突（前輪あたり）
10m程飛ばされて頭、ほんとにてっぺんからアスファルトに直撃。
その瞬間首が変な方向に、ぐにっとなった時。

結果は頭を支点にそのまま背中をまたアスファルトに直撃。
シボンヌ・・・、と思ったら生きてる。
その瞬間、車に腹が立って立ち上がり走っていってボンネットの上に飛び乗った。
運転手ポカーン、
んで警察に行って、病院行って、CT撮って診察の時。
他に痛い所は？と先生。
タンクで金タマ打って少し痛い。と言うと
顔色を変えてそれはいかんな、チョット見せて
（看護婦ちょっとはにかんだ様な顔でカーテンを引く）
先生、漏れの金玉をうねうねコロコロして。
ん～、大丈夫でしょう。しばらくすると痛みも引きます。
と言いながらカルテにカキコしてるのを見ると
　
　　睾丸hit　　　　

これはだめかもわからんね・・・
0400デフォルトの名無しさん2007/03/04(日) 15:58:53
朝鮮語でおｋ
0401デフォルトの名無しさん2007/03/04(日) 22:07:30
>>397
流れ的に俺のことなんだろうが、フロントエンドにしか興味ないのか？
0402デフォルトの名無しさん2007/03/04(日) 22:14:46
ネットワークのスレとかにも現れる
「おまえらバカばっかりだな」系の人だろ

もちろん具体的な議論はしません
0403デフォルトの名無しさん2007/03/05(月) 15:18:23
>>401
何処の人か分からないけど、ごめん。
イント、フロートでごちゃごちゃ言ってた人のこと。
0404デフォルトの名無しさん2007/03/05(月) 18:45:01
それも多すぎてわからん。
0405デフォルトの名無しさん2007/03/05(月) 23:09:11
【キーワード抽出】
対象スレ： GPGPU
キーワード： イント


403 名前：デフォルトの名無しさん[sage] 投稿日：2007/03/05(月) 15:18:23
>>401
何処の人か分からないけど、ごめん。
イント、フロートでごちゃごちゃ言ってた人のこと。


抽出レス数：1
0406デフォルトの名無しさん2007/03/05(月) 23:32:35
イント人もびっくり
0407未来人2007/03/07(水) 16:29:31
GPUってCPUに取り込まれて無くなってたよ。
CPUは、FPUとSPUとGPUで構成されてたよ。

0408デフォルトの名無しさん2007/03/07(水) 20:51:05
>>396
「何時の時代の人だ（と言ってもたかだか数年前だが・・）」的な
ことを今更「俺が知りたいのは」とか書くから荒れる。勉強しろ。
0409デフォルトの名無しさん2007/03/08(木) 01:13:12
>>408
url か検索ワードくらい教えてくれ。
英語でなんて表現したらたどり着くのか見当も付かん。
0410デフォルトの名無しさん2007/03/08(木) 03:00:48
【Penryn】次世代モバイルCPU雑談ｽﾚ 3【Nehalem】
ｈttp://pc9.2ch.net/test/read.cgi/notepc/1160039483/537

537 名前：[Fn]＋[名無しさん][sage] 投稿日：2007/03/07(水) 17:10:43 ID:o4rB4JJN
GPUだからコプロセッサではない。
同様にデュアルコアだからデュアルCPUではない。
たしかに正しい。
でもこの視野の狭さがアホな言動につながるのです。
プログラムから見るとどう見える?
概念レベルではどう見える?
そんな視点は一切ない。
0411デフォルトの名無しさん2007/03/08(木) 05:54:39
GPGPUの研究発表を聞いた
CPUのみに比べて若干早くなっている程度
たぶんプログラミングレベルが低いのもあるんだろう
コストパフォーマンスについて聞いたら
「将来的には」を連発してた
CPUよりコストパフォーマンスの伸びが良い予定らしい
0412デフォルトの名無しさん2007/03/08(木) 06:29:53
だってさ、1度でもGPGPUでコーディングした人ならわかるでしょ。
GPUを活かせる箇所が少ない事に…。
GPUといえども、1つあたりのストリームプロセッサの能力はCPUに比べて鼻くそだし、ReadBackのコストも馬鹿みたいにかかるんだから
並列化できなけりゃ意味がない・・・。そんな都合の良いループ部分が現状のコードや計算式見てそんなにあるか？

04134112007/03/08(木) 06:57:00
早起きなのか徹夜かどうかはさておき、さっそくどうも。

うちのソースは機械系で有限要素的なので割とあるんだな。
PS2の時に1GFlops程度出たけどP4のSSEにトータルで負けた。
CellとGPGPUは期待してるけど過剰期待は禁物だと思ってる。
いちおうGeForce8800買ってみるよ。
Cellはソフト作る気にもならないのでライブラリ充実待ち。
0414デフォルトの名無しさん2007/03/08(木) 07:33:26
私のところも並列できる応用は色々ある。
実際、ClearSpeedやXTrillionのようなアクセサレータボードで速度が出ている。
それらに較べれば、コストはGPGPUなら桁違いに掛からないわけで。
#CELLも評価対象になってるけどね。
0415デフォルトの名無しさん2007/03/08(木) 09:02:04
ムダ毛対策にもGPUによる並列処理が効果的らしい。
0416デフォルトの名無しさん2007/03/08(木) 11:01:34
>>415
全身大やけどしました
0417デフォルトの名無しさん2007/03/21(水) 18:20:19
>>412
動画のエンコードだと1つのキーフレームを1つのストリームプロセッサに
担当させることによって、簡単に並列化できる。
0418デフォルトの名無しさん2007/03/22(木) 17:50:05
標準的なグラボは
VRAM128M
ストリームプロセッサは64基

１コアあたり2Mしか使えん。(それ以前に128M丸々使えるわけが無い)
丸々割り当てるのは辛いんじゃないか？
0419デフォルトの名無しさん2007/03/23(金) 02:50:52
メモリ容量は768MBを想定してたから確かに128Mの場合は辛いなぁ。
GPU側のメモリを使いきるごとにCPU側のメモリに渡すというやり方で
なんとかなりそうな気はするけど。
0420デフォルトの名無しさん2007/03/23(金) 03:07:17
完全にCUDA世代のグラボ前提の話になってるな
まだ遠い話だ・・・
0421デフォルトの名無しさん2007/03/23(金) 07:20:12
ttp://fah-web.stanford.edu/cgi-bin/main.py?qtype=osstats
GPGPU遅いとかいうのはnVIDIAのG7x前提だからだったんだね・・・

ATIのR580速いや・・・
Cellの倍の実パフォーマンス・・・

1台あたりは
PS3 30GFLOPS
GPU 60GFLOPS
0422デフォルトの名無しさん2007/03/23(金) 10:07:36
そのCellもフルパワー出てるかわからないけどね
0423デフォルトの名無しさん2007/03/23(金) 10:43:06
>>421
俺、G7xに限らず、G80でも試したが、結果は似たようなもんだったぞ。
ぶっちゃけGPGPUは、もはや言葉だけが先行した流行りモノに過ぎない気が・・・

実際、BrookGPUとか使えばC使える人なら簡単にGPGPU出来るようになったのに
誰も使ってないし、使ってる人は割りと失望してる人が多い・・・
0424デフォルトの名無しさん2007/03/23(金) 12:59:13
G80持ってる人ここのヤツ試してくれん
ttp://gpgpu.jp/
ttp://gpgpu.up.seesaa.net/image/himeno0507.zip
ttp://gpgpu.up.seesaa.net/image/brookbench_001.zip

姫野ベンチ その２
ttp://gpgpu.jp/article/17502609.html
brookbench ver.0.01
ttp://gpgpu.jp/article/17266520.html

G80とG7xでそんなに違わないって>>423の発言が気になる。
G70とRV530で十倍近い差有るし・・

じつは、G80もG70同様遅いのかな？
0425デフォルトの名無しさん2007/03/23(金) 13:31:21
上手く全てのコアを綺麗に動かせれば、当然差が出るけど
実際の場面で、汎用処理でそういうことをするのは難しい。

姫野ベンチのようなプログラムだと差が出るだろうけどな
0426デフォルトの名無しさん2007/03/24(土) 22:24:06
いい加減ナントカシェーダという呼び方はやめなさい
0427デフォルトの名無しさん2007/03/25(日) 02:00:17
既に定着してしまっているモノを変えたければ、
より多くの人に共感してもらえて説得力のある代替案を出さなきゃ。
0428デフォルトの名無しさん2007/03/25(日) 02:08:48
David Kirk 「この命名はおかしいと自分も思う。Shader(プロセッサ)はプロセッサと呼ぶべきだと思う」
http://pc.watch.impress.co.jp/docs/2006/1121/kaigai320.htm
0429デフォルトの名無しさん2007/03/25(日) 02:46:49
nvidiaはストリームプロセッサと呼んでるじゃん
0430デフォルトの名無しさん2007/03/25(日) 05:51:54
シェーダーって元々影処理専門だったんだっけ？
0431デフォルトの名無しさん2007/03/25(日) 06:59:56
それはシェイドシェイダーユニットの役割ですね
0432デフォルトの名無しさん2007/03/25(日) 14:44:57
shade (r)だから影erみたいなもんだろ。
0433デフォルトの名無しさん2007/03/25(日) 17:09:13
元が3DCG用語だからな
それをgenericな用途に使おうとしてるんだから
呼び方に違和感が出てくるのはしかたあるまい
0434デフォルトの名無しさん2007/03/25(日) 19:00:37
3DCGの範疇であるvertex shaderの時点でもうおかしいわけなんだが
0435デフォルトの名無しさん2007/03/25(日) 19:44:42
ピクセル影er
頂点影er
プログラム可能な影er
0436デフォルトの名無しさん2007/03/25(日) 22:56:05
CG用語のシェーダーっていうのは凄く広い意味を持ってるからややこしい。
基本的に与えられたデータを元にピクセル出力するためのプログラムは全てシェーダー。
頂点処理をするのもそうだし、毛を生やしたりするのもシェーダーと言ったりする。
0437デフォルトの名無しさん2007/03/25(日) 23:08:12
「シェーダ」は元々はRenderManとかmental rayとかの用語でしょ
0438デフォルトの名無しさん2007/03/26(月) 04:57:07
vertex shaderはピクセルの出力と全く関係ないような
0439デフォルトの名無しさん2007/03/26(月) 09:44:43
CUDAを使ってトリップ検索させると速いですか？
0440デフォルトの名無しさん2007/03/26(月) 09:46:56
そういうのには向いてません。

高速にcryptを実行するってのは前に試したけど
いい感じにかきなおせなかったわ。　
04414402007/03/26(月) 09:49:34
ちなみに、cryptの能天気な話は
ttp://www.gpgpu.org/forums/viewtopic.php?p=4642&sid=fa945081fc53f719b6da6ade288b0ac8
ここみてちょ。
ここに載ってるパワポは見た上で試したが…。

こいつら、分かってて書いてるんだろうけどさ・・・。
0442デフォルトの名無しさん2007/03/26(月) 10:09:49
>>439
8800GTSで試したんだけど遅くはないけど激速じゃない。(4M程度)
コストパフォーマンスではC2Dよりちょっと分が悪い。
春に廉価版が出揃って、CUDAのバージョンが上がったらモノになるかな?

整数演算のイマイチ度については各方面から突き上げが激しいので
次アーキでは劇的に改善される可能性はなきにしもあらず。

>>440
俺はLUTで試したけど、MP内にてLoadネックで
並列度が頭打ちになってる感じ。>>440が試した結果をもすこし詳しくきぼん
0443デフォルトの名無しさん2007/03/26(月) 10:59:36
■後藤弘茂のWeekly海外ニュース■
CPUとGPUの大きな違い
●汎用コンピューティングで近づくCPUとGPU
http://pc.watch.impress.co.jp/docs/2007/0326/kaigai346.htm
0444デフォルトの名無しさん2007/03/26(月) 19:18:04
>>442
C2DでもTrip-Monaで500k程度だから4Mでも十分じゃん
0445・∀・）っ-{}@{}@{}@2007/03/26(月) 19:38:01
やきとり屋さんだよ
0446デフォルトの名無しさん2007/03/26(月) 20:56:14
utripperはathlon64 2GHzで動かすよりCeleron 1.3GHzの方が速かったんだけどそんなもん？
0447・∀・）っ-○◎●2007/03/26(月) 21:06:48
アレはキャッシュのレイテンシ依存だし



PS3で10Mうめぇｗｗｗｗとか言ってるの俺だけ？
0448デフォルトの名無しさん2007/03/26(月) 21:14:43
>>447
Cellで？
0449・∀・）っ-○◎●2007/03/26(月) 21:48:56
RSX使わせてくれないから、まあそうなるかな
0450デフォルトの名無しさん2007/03/26(月) 23:23:18
>>442
GTSで4Mか。
GTXのSLIだとどれぐらいになるかな…。
また、理論ピークと、トリップ検索の性質を鑑みるに、まだ性能向上の余地はかなりありそう。
今後に期待だ。
まあカネも電力もバカみたいにかかるけど。

[email protected]×2でTripcode Explorer v1.2.3を動かすと10.3Mtrips/sらしいので、
Woodcrestを二機積んだマシンでGTXのSLIを使えばチョー最強？
0451・∀・）っ-○◎●2007/03/26(月) 23:25:58
（・∀・）
0452デフォルトの名無しさん2007/03/27(火) 10:26:11
>>450
電源が死にそうだね。つーか、熱対策か。
0453・∀・）っ-○◎●2007/03/28(水) 01:25:33
CPUはClovertownの50W版でよくね？
0454デフォルトの名無しさん2007/03/28(水) 03:45:24
取り敢えず、8800GTXの動く環境はできた。
#CPUは1coreXeonだけど。
さて、来月から実験だ。
0455デフォルトの名無しさん2007/03/28(水) 18:10:27
ttp://sourceforge.net/project/showfiles.php?group_id=96847
brookgpuの更新が止まってるように見えるんだけど、
とりあえずダウンロードしてみた。
サンプルプログラムどこ？
仕様はわかったんだけど、動作イメージが掴めねえ。
0456デフォルトの名無しさん2007/03/28(水) 22:28:46
BrookはCVSで更新は続いてるよ。

で話は変わるがPeakStream Free Trial Download
ttp://www.peakstreaminc.com/product/free_trial_download.php

GPUとしてはFireStream,R580(?)
ttp://www.peakstreaminc.com/product/peakstream_for_windows/technical_reqs.php
Supported GPUs
AMD Stream Processor
ATI Radeon x1950 (Supported for evaluation purposes only)
0457デフォルトの名無しさん2007/03/28(水) 22:30:06
PeakStreamはCTMしようか
0458デフォルトの名無しさん2007/03/30(金) 00:30:52
>>455
ヒント：brook/prog の下
あとここの解説も分かりやすい。
ttp://www.mi.tj.chiba-u.jp/~hamano/brook/sample/sample.html
0459デフォルトの名無しさん2007/03/30(金) 00:40:37
つか、外人が思い付きで作ったｷﾓｲ言語使うのはヤメロ。
nVidia様の作られた環境だけを支持したほうがいいぞ
0460デフォルトの名無しさん2007/03/30(金) 00:46:40
実質BrookGPUは、Cで記述したソースをnVIDIA様が作られたCg言語にコンバートするシステムなわけだが…。

0461デフォルトの名無しさん2007/03/30(金) 00:52:59
>>459はCUDAのことを言ってるのだろう。
たしかにあれはいいと思うが、世の中全てがnVIDIAチップじゃないのが問題。
家の中でnVIDAだけに絞って開発するならいいが。
0462デフォルトの名無しさん2007/03/30(金) 01:29:54
>>460
でもFolding@homeでそれ使ったらまともに動かなかったんだろう。
そのマクロ言語が悪いんじゃなくて、ビデオカードが向いてなかったんだろうけど。
0463デフォルトの名無しさん2007/03/30(金) 06:58:08
>>460
CVSだとCg,HLSLに加えCTMが。
0464デフォルトの名無しさん2007/03/30(金) 10:37:08
現状だと
・キモイ新言語（CUDA,Brook,CTM?）
・ぶっちゃけ使いやすくないグラフィックス記述（グラフィックスAPI＋シェーダ言語）
しか選択肢が無い件。

汎用性汎用性とか言いながらグラフィックス記述でプログラミングしてるけど、
GPUのアーキテクチャにひっついたキモイ新言語がGPUの性能を一番引き出せるんじゃね？
という不安が拭えない。
0465デフォルトの名無しさん2007/03/30(金) 11:05:14
CUDAには数値演算ライブラリもついてきたんじゃなかったっけ?
それが使えるもんなら、自分で書いてたらバカ見るなぁ。
0466デフォルトの名無しさん2007/04/01(日) 16:28:43
つうかCUDAでいいじゃん、あれ将来的に完全に整数演算できるぞ
今はおもちゃ用だから科学計算じゃ糞だけど。ゲームとか軽い計算ならできる。
0467デフォルトの名無しさん2007/04/01(日) 19:04:47
BrookGPUで満足しているが、
あれを使うと、簡単だけど細かい操作が出来ないから
並列コンピューティングの技術やアルゴリズムが殆ど使えない…。

結果、リードバックの速度とか、GPUのマイナスの部分ばっかりが出てダメダメになるな・・・
0468デフォルトの名無しさん2007/04/01(日) 19:09:44
>>467
X19XXではうまく動いているみたいだよね＞Folding@home
0469・∀・）っ-○◎●2007/04/01(日) 19:48:11
てか、「ストリームプロセッサ」として売ってるものそのまんまじゃね
AMD Fusionにもあれがほぼそのまま搭載されるとか
0470デフォルトの名無しさん2007/04/01(日) 20:01:33
>>467
BrookGPUが細かい事出来ないのは同意だけど
元々各シェーダーユニットを管理して並列化を効率化する事は出来ないぞ。
ベクトルプロセッサだから、そういうものだ。

うん、綺麗に管理できると良いんだけどなぁ…。
0471デフォルトの名無しさん2007/04/01(日) 22:15:30
いやだからCUDA使えってあれなら俺等が求める
世界を追求できる。とりあえず、Geforce8600買ってみろ
0472デフォルトの名無しさん2007/04/01(日) 22:26:58
上のほうにあるbrookの姫野ベンチ(>>424)でも
X1300とX1600で結果が変わらないって出てるから
その辺はBrookで変換した後、更に手作業の最適化が必要なんじゃないかな
Folding@Homeは素直にShaderの数がパフォーマンスに出てるし。（単に演算の規模が違うだけ？）
Brookだと、変換言語（？）もGLSLからCg、最近ではCTMもあるようだし。

そういえば、Inqの記事に何でnVIDIAにはGPGPUなソフトが出ねーんだ？的な記事が出てた
PS3にさえFolding@Homeがでて、ATIはとっくにやってるしnVIDIAはなぜ？ってな感じで。
ttp://www.theinquirer.net/default.aspx?article=38598

実際にはG80とCUDAならFolding程度なら可能なんかな？
G80ないんで何ともいえないけど。
0473デフォルトの名無しさん2007/04/01(日) 22:33:30
R580でやってるfoding程度はG71でも可能だがパフォーマンスが出なかった
G80ではどうなんだろうな
0474・∀・）っ-○◎●2007/04/01(日) 22:36:24
CellでPCの数百倍ってちょっと信じがたいんだけど
レジスタ本数が重要とかってこたないよな？
nVIDIAのシェーダってレジスタ少ないんじゃなかったっけ
0475デフォルトの名無しさん2007/04/01(日) 22:36:41
>>472
おれもそうだけど、まだG88を買ってるやつがほとんどいないんじゃないかな。
おもちゃとしてはちと高いし、入れるとうるさいだろうし。

>>347がOS 32bitに載せ替えてくれればいいんだけど、それまでは皆次世代廉価版
待ちなんだろう。
0476デフォルトの名無しさん2007/04/01(日) 22:57:37
>>347
つかおまえ、金はあるが知識無さ過ぎだろ？Linux入れろベンチ取るぐらいの駄コード書くのに
何64bitとOSにこだわり持ってるんだ？お前なら、RE買うのお金がないのですがとか言いそうで恐いけどなw
0477・∀・）っ-○◎●2007/04/01(日) 23:17:02
俺なんかXeon買う金ないからPS3買ったくらいだｗｗ
はやくRSX使いたいｗｗｗ
0478デフォルトの名無しさん2007/04/01(日) 23:30:37
おれはNXT買う金がなくてRCX買ったよ
0479デフォルトの名無しさん2007/04/01(日) 23:30:53
>>477
そのRSXって、要はG7XXXだろ。あんまり使い途ないんじゃないかなあ。
X11周りを作り替えるってんならありがたい話だが、あんたそういうのできる人だっけ？
0480・∀・）っ-○◎●2007/04/01(日) 23:38:23
出来ない人。
むしろ描画のHWアクセラレーションが利かないのが痛いの。
欧州ギークならなんとかしてくれる・・・と思いたい
0481デフォルトの名無しさん2007/04/02(月) 00:12:15
>>480
Linux板で人の話を聞かずに無駄金使ったな。
0482・∀・）っ-○◎●2007/04/02(月) 00:21:37
GPU使えないって言ってもフレームバッファは使えるし
X立ち上げて普通に使う（FireFoxでWebブラウズしたり）分には特に問題ない。
意外と使えるんでびっくり。

まあ現状でもCellマシンとしては十分元は取れてると思う。
General Processing出来る専用コプロセッサが7個
（ユーザーモードでは使えるのは6個）あるし。

今使えなくてもアップデートで使えるようになる可能性もあるし。
0483デフォルトの名無しさん2007/04/02(月) 00:25:34
まともにニコ動が見れないWebブラウズなんかいみねーよ
0484・∀・）っ-○◎●2007/04/02(月) 00:28:07
Flashが見れないのはPPC Linux用Flashプレイヤーが提供されてないからで
PS3のせいじゃないだろ
0485デフォルトの名無しさん2007/04/02(月) 00:41:12
>>482
わかってないね。
Linux板で言ってたのは、鯖機のつもりで使えば、何の不満もないだろってことだよ。
コンソールはおまけ。おまけがそのうち化けるかもしらんけど。
0486デフォルトの名無しさん2007/04/02(月) 01:25:25
取り敢えず仕事用にHPの中古EWS調達して8800GTXのボード入れているけど、五月蝿いとは思わないなぁ。
0487デフォルトの名無しさん2007/04/02(月) 02:37:17
立ち読みしたPS3 Linux雑誌によるとnVIDIAはPS3 Linux用ドライバ作る気零らしい。
署名しかないのか。。。？
0488・∀・）っ-○◎●2007/04/02(月) 06:50:53
GK「トップガンならやれる」
0489デフォルトの名無しさん2007/04/02(月) 09:49:07
>>486
＞HPの中古EWS
それ、Netburst Xeon機だろ。
足下に2台あるけど、（ヘッポコカードとは言え）ビデオカードの音などまったく気にならない。
でも、「五月蠅くない」ってのとは違うだろう。
こんなの自宅で使いたくない。

>>487
今のところRMSの言の通りだね。
業者の非openなドライバに依存していると、いつかテメエの首が絞まる。
0490デフォルトの名無しさん2007/04/02(月) 12:59:20
能力の低いopenドライバと能力の高いclosedドライバの
両方があったら俺は後者を使う。
使えなくなったときに移行すれば良いだけだし。
0491デフォルトの名無しさん2007/04/02(月) 20:01:51
http://forums.vr-zone.com/showthread.php?t=140444
>As the Fusion programme implies, it will come with an integrated graphics core which is a subset of the R600 VPU.
>This graphics core will share system memory with the CPU,
>but ATI claims it will be faster than the NVIDIA's new GeForce 8600 GTS, thanks to the inclusion of 16MB of really fast on-die memory.
0492デフォルトの名無しさん2007/04/02(月) 23:18:57
ネタもとの日付が気になるが
Fusionにはたしかに、でかめのキャッシュかレジスタが必要でしょうな。
EDRAMとして使えばXbox360は軽く超えてしまうのか・・・
0493デフォルトの名無しさん2007/04/02(月) 23:27:30
Fusionの話かと思ったが、Socket FのGPUの話け？
0494デフォルトの名無しさん2007/04/03(火) 04:16:21
BrookGPUって、実行環境で環境変数設定しないといけないけど
あれって凄く不便なんだよなぁ・・
例えば自分の配布ソフトに組み込みたい時とか・・・
0495デフォルトの名無しさん2007/04/05(木) 00:09:04
環境ごとにバッチファイルでも作ればよくね？
0496デフォルトの名無しさん2007/04/05(木) 02:11:33
つかCUDA以外全部失敗とみなしてもいいほど糞だ。
オナニー言語とかマジ作るのやめてほしい見てると
イライラしてぶっ潰したくなってくるよ
0497デフォルトの名無しさん2007/04/05(木) 13:38:48
Cgがあの有様なのに、今度はCUDAに期待しろとなｗ
0498デフォルトの名無しさん2007/04/05(木) 20:22:18
8800を汎用計算で速度計測したサイトが見つからないんで、教えてほしい。
0499デフォルトの名無しさん2007/04/05(木) 20:35:58
8800にあんまり魅力を感じないんだけど研究する価値ある？
0500デフォルトの名無しさん2007/04/05(木) 22:25:28
>>499
CUDAが動くのが8800しかないから。
今更後戻りはしないだろうから、新世代毎にCUDAが使える
ビデオカードが増えてくるはず。

AMD X19XXはBrockGPUでも使い物になることがわかった(folding)
nVIDIAがどういう状態なのかわからないんで。
0501デフォルトの名無しさん2007/04/05(木) 23:18:25
CUDA_SDK入れてみたけど、サンプルが動作確認的なのばかりで
パフォーマンスが目に見えるようなのが無くてちょっと寂しい。
0502デフォルトの名無しさん2007/04/06(金) 00:06:01
ゲーム用途でなんだが
いわゆる、プロシージャル処理をGPUでやらせようっていう動きに
AMDは積極的のようですね。
GDCの内容もそれっぽい
R600のRubyのデモも雪原はプロシージャル生成らしい

ttp://ati.amd.com/developer/gdc/2007/Andersson-Tatarchuk-FrostbiteRenderingArchitecture(GDC07_AMD_Session).pdf
これの48ページ目の絵を良く覚えておいて
Ruby demoを見てみよう
ttp://youtube.com/watch?v=EJ6aMxPh6k0

nVIDIAもトンボのデモでやってるっぽいけど
インパクトは・・
0503デフォルトの名無しさん2007/04/06(金) 00:19:25
>>502
絵の話はよそでやってくれよ。
0504デフォルトの名無しさん2007/04/06(金) 02:29:42
とりあえずBrookGPUがなぜユーザーに環境変数を設定させる方式にしてるのかが疑問だ
ライブラリの初期化のときにパラメータを与える方式にしない理由がわからん。

bgInit(BG_OPEGL);
みたいにさぁ
0505デフォルトの名無しさん2007/04/06(金) 03:01:54
>498
自分でやれば、論文かけちゃうぞ。

>499
NVIDIAでは前のﾓﾃﾞﾙと構造が違うから、前との比較なんぞをやってしまえばこれもまた研究になると思う。


っていうかCUDAがあるのにBrookGPUを使う意味がわからん。
特定の処理に関しては楽なのか?
0506デフォルトの名無しさん2007/04/06(金) 03:09:09
CUDAを使うにはGF8シリーズが必要だろ
BrookGPUなら、プログラマブルシェーダーを搭載していれば、主要なGPUで動く
0507デフォルトの名無しさん2007/04/06(金) 07:26:06
GPGPUの壁の一つにそういった汎用性の問題があるよね。
ATIのいう業界標準のAPIに期待。
0508デフォルトの名無しさん2007/04/06(金) 16:21:22
ATIの業界標準APIってなんだよｗ
標準にならないと、所詮CUDAと同じ

業界標準で言うと、nVIDIAのCgの方がマシ
あれはシェーダー搭載している主要グラボにほぼ対応している。
純粋なGPGPU用の言語ではないけどな。
んで、Cg用のコードを吐き出すBrookGPUがまだマシだとあきらめて使われてる理由でもある
0509デフォルトの名無しさん2007/04/06(金) 23:19:25
汎用演算が今後広く普及したとしても、
nVIDIAとATiでなかよく一つの業界標準言語を作るのは無理だろうね。

MS（の強要）頼みかな。
0510・∀・）っ-○◎●2007/04/06(金) 23:27:50
SPEのISAは普及しそうにありませんか？（本音：糞食らえ
0511デフォルトの名無しさん2007/04/07(土) 00:11:12
Cgは一応MSも噛んでるな
しかもATiでも的でも使える。
CUDAもそんな感じにするんじゃないの？
0512デフォルトの名無しさん2007/04/07(土) 01:02:52
自作板で見たんだが、こんなもんがあるんだね。誰か使ってる？

Microsoft Research Accelerator Project

The Microsoft Research Accelerator system provides simplified programming
of graphics-processor units (GPUs) via a high-level data-parallel library.
This download includes a data-parallel library for .NET that targets GPUs,
documentation, and sample code using the library. Parties interested in inquiring
about commercial licensing of the Microsoft Research Accelerator software
should contact [email protected] for more information.

http://research.microsoft.com/research/downloads/Details/25e1bea3-142e-4694-bde5-f0d44f9d8709/Details.aspx
0513デフォルトの名無しさん2007/04/07(土) 01:42:17
.NETかよ
0514デフォルトの名無しさん2007/04/07(土) 10:21:45
Ge86発売日に意味もなく東京に行く出張入れることを成功したぜ。
上司になんでこんな時期に本社へ出張必要なのぉ？って怪しまれたが
気にしない。CUDAするために、２枚購入してくるぜ。

0515デフォルトの名無しさん2007/04/07(土) 18:28:10
SLI　CUDAできるのかな？
0516デフォルトの名無しさん2007/04/07(土) 18:38:50
出張期間延長で
通販にしとけばﾖｶﾀｰ
と嘆きつつPC一式調達してホテルでいじる>>514に乾杯!
0517デフォルトの名無しさん2007/04/07(土) 20:41:43
ttp://www.kohgakusha.co.jp/support/rtmshadr/index.html
ここのソース試した人いる？

ＶＣでまともに動かないんだけど
0518デフォルトの名無しさん2007/04/08(日) 03:18:39
もうすぐGF8600および8500が出る。
それからが本当にGPGPUが普及するかの正念場だな。
8800はヘビーユーザーだけの代物だったが、8600や8500は十分一般ユーザーの手に入る価格帯だし。
まぁ、その分ベンチは散々だが、所詮ローエンド
0519デフォルトの名無しさん2007/04/08(日) 04:33:46
まぁ、このスレ何気に4割が俺の書き込みなんだよなぁ・・・。
その状況から言って、やっぱり寂しいものがあるよなぁ。。。
0520デフォルトの名無しさん2007/04/08(日) 05:52:11
おまいさん>>131か？
0521デフォルトの名無しさん2007/04/08(日) 09:09:30
毎日スレ更新してるのでバンバン書き込んでください＾－＾
0522デフォルトの名無しさん2007/04/08(日) 11:04:36
まだ手を出すのは早いからな
デフェクトスタンダートが決まりつつあり
日本語ドキュが整備されつつあるぐらいでも
十分遅くない、経験的に
0523デフォルトの名無しさん2007/04/09(月) 04:26:21
>>514-515
CUDAのforumに、GPUが非SLIで複数ささってれば全部使うよー、って書いてあった気がするんだけど、ソースを失念。
0524デフォルトの名無しさん2007/04/09(月) 04:38:03
そんな(消費電力とスペースの)恐ろしいことはできないw
0525デフォルトの名無しさん2007/04/09(月) 15:21:38
最近のGPUは前世代の2倍のパフォーマンスだけど消費電力も2倍って感じだからなw
ATIの新しいのはビデオカードだけで250Wとか酷すぎる。
0526デフォルトの名無しさん2007/04/09(月) 15:46:29
8800GTXなんて、+12V電源を30A用意しろと書いてあるよ。
単純計算するとそれだけで360Wだ。
#実際、ボード上に+12V用6pin電源コネクタが二つもある。
0527デフォルトの名無しさん2007/04/13(金) 03:40:49
CPUのように消費電力が通常の半分で値段が通常の1.5～2倍の
製品を出してくれれば、一般的な開発者もGPCPUの検討用に買ってみようか、
というやつが増えると思う。
次世代では両者とも検討してほしいところ。

・・・と思ったが、250Wやら300Wやらじゃ、半分でもNetbust「全盛期」かそれ以上だ。
んなもん、ゲームもしないのに買ってもアホらしいな。
0528デフォルトの名無しさん2007/04/13(金) 11:08:03
計算終わった後に「チーン」って音しそうだな。
0529デフォルトの名無しさん2007/04/13(金) 13:24:32
おい、CUDA SDK 0.81 あるぞ。
0530デフォルトの名無しさん2007/04/13(金) 14:16:29
あるぞといわれても
0531時々書いてるこのスレの住人2007/04/13(金) 14:32:29
取り敢えず拾った。

>>529
THX!
0532デフォルトの名無しさん2007/04/13(金) 18:29:20
>>529
ｱﾘｶﾞﾀﾏｷﾝ ( ´∀｀)ﾉ⌒ω)Д`)ﾌﾞﾆｭ
0533デフォルトの名無しさん2007/04/15(日) 13:13:41
けっこうCUDA使い＝8800使いがいるんだね。
簡単な結果でいいから、報告してくれないかな。
0534・∀・）っ-○◎●2007/04/15(日) 13:21:27
おれCUTA使い
0535デフォルトの名無しさん2007/04/15(日) 15:41:46
( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )ﾋｿ
0536デフォルトの名無しさん2007/04/15(日) 16:37:35
>>533
なんか適当なベンチマークないかね。
nVideaのサンプルは動作確認っぽいのばかりで動かしても面白くないのだけれど。
#つーか、私も作らないとなんだけどね(苦笑
0537デフォルトの名無しさん2007/04/15(日) 16:44:08
SDK 0.8だと、どうしても一塊のデータをわっと処理するバッチ系の
サンプルしかなかったので、俺の場合まだまだ基本性能を評価する段階だった。
NVIDIA FORUMでは、「演算サーバみたいなもの組めねえぞｺﾞﾙｧ」なトピックがHotだった。
>>529は俺なんだが、今別の遊びをやってるのでCUDAしばらく棚上げだ。
他の誰かがほげってくれるのを待つ!
0538デフォルトの名無しさん2007/04/15(日) 23:54:14
>>533同意
とりあえず>>424の姫野ベンチの結果が知りたいな
05395362007/04/16(月) 11:31:05
Linuxだから無理。
じゃないけどBrook入れてないからめんどい。
0540デフォルトの名無しさん2007/04/16(月) 12:17:16
実行だけならBrook入れなくても
出来るよ。
0541デフォルトの名無しさん2007/04/16(月) 23:48:51
>>533
つーか今CUDAって8800以外で使えるの？
0542デフォルトの名無しさん2007/04/18(水) 18:04:18
ｹﾞﾌｫ廉価版出たけどあまりにも性能差が差別化されまくり。
それでも、エミュよりマシだと思えばいいのか。
0543デフォルトの名無しさん2007/04/18(水) 20:24:05
8600が出ましたよ。
0544デフォルトの名無しさん2007/04/18(水) 21:09:01
質問です。
ifやswitchなど条件分岐を一切使わずに汎用プログラミングを行うと言うのがかなり理解出来ないのですが
一般的にGPUでのプログラミングでは、この辺はどのようにしているのでしょうか？

例えば、GPGPUによる、動画のエンコーダーなどの分野は期待しているのですが
あの手の処理は、条件分岐の塊だと思うので、GPUではそれらが使えないとなると有効な実装方法が思いつきません。

0545デフォルトの名無しさん2007/04/18(水) 22:05:46
>>544
分岐の分だけmain()を作る
今はもうレガシな手法になりつつあるが。
当然個々のフラグメントプログラムは
画一したフローを踏むことになる。
0546デフォルトの名無しさん2007/04/18(水) 22:16:00
>>545
一瞬びっくり！という感じだけど、やっぱりわからない。
if文は普通にc++で書いて特定の箇所で飛ばすのに比べて、
mainたくさんというのは、どういうメリットがあるの？
0547・∀・）っ-○◎●2007/04/18(水) 22:43:44
mainじゃなくてもサブルーチンでもいいけど、分岐の頻度を最小限に減らさないといけない
パイプラインが長いと、分岐の度に大きなペナルティ食らうわけよ

んで

for (i = 0; i < 1000; i++) {
if (a == b) {
　　　//HogeHoge
　} else {
　　　//BokuhaKamiyamaMangetuChan
　}
}

よりも

if (a == b) {
　for (i = 0; i < 1000; i++) {
　　　//HogeHoge
　}
} else {
　for (i = 0; i < 1000; i++) {
　　　//BokuhaKamiyamaMangetuChan
　}
}

のほうが速いよね。
パフォーマンス重視なら、分岐を繰り返し処理の外に追い出せる場合は
なるべくそうしたほうがいい。たとえ冗長になってもね。
普通のCPU向けプログラミングでも同じ
（最近は分岐予測のほうが賢くなってるから一概にはいえないけど）
0548デフォルトの名無しさん2007/04/18(水) 23:12:58
>>547
>>545の話はそういう話なのかい？
＞mainじゃなくてもサブルーチンでもいいけど
あんたのコードで//HogeHogeのところで別プロセス呼んでたりしたら、
普通は頭がおかしいコードだと思うよね。
0549・∀・）っ-○◎●2007/04/18(水) 23:19:36
プログラムって基本的にループの塊なんで、

むしろループがプロセスの単位だと思ってくれ
0550デフォルトの名無しさん2007/04/18(水) 23:24:46
いやさ、おれもコード書きのはしくれなんで、forkくらいは使うけど、
>>545のはGPUを使うときの独自の流儀の話をしてんじゃないの？ってこと。
0551・∀・）っ-○◎●2007/04/18(水) 23:24:58
ちなみにGPUにプロセスの概念はない。GPU上でOSは動かないだろ。
0552・∀・）っ-○◎●2007/04/18(水) 23:32:44
たとえばJPEGの量子化なんかだと、除算値を定数化できれば大幅に高速化できるわけで。
でもコンパイル時には不定なわけで。
でも除算値毎にEXE作ってたらアホらしいから、普通のCPUだと、動的に命令コード生成したり
する。一般人はこんな面倒なことやらないけど、トップガンの常套手段ね。

でもGPUだとそういうことできないから（CPU側でやれば可能かも）
モジュールを複数作ってパラメータにあったのをロードすると。
そんだけの話でしょう。
0553デフォルトの名無しさん2007/04/18(水) 23:59:05
>>552
いちおう理解できたようだ。感謝。
でも>>547は関係ない話だろう。
0554デフォルトの名無しさん2007/04/19(木) 00:13:38
スレが伸びてると思ったら糞団子かよ
0555デフォルトの名無しさん2007/04/19(木) 00:46:37
トップガン(藁
0556デフォルトの名無しさん2007/04/19(木) 00:50:39
分岐コストが高いなら、両方のルートを計算すればいいだけ。
そういう頭の使い方ができない香具師にはGPUを使いこなすのは難しい。
0557デフォルトの名無しさん2007/04/19(木) 01:04:55
つまり下手鉄砲も数打ちゃ当たる？
0558・∀・）っ-○◎●2007/04/19(木) 01:07:57
弾の数が勿体ない。
スループット落ちるじゃないか。
0559デフォルトの名無しさん2007/04/19(木) 01:09:19
252 ：Socket774 [sage] ：2007/04/19(木) 00:15:30 ID:0/nRKtHL
Larrabeeはかなり本気で開発している模様

> またRattner CTOが基調講演で触れたIAコアによるテラフロップCPUに関し、
> もう少し細かい話も出てきた。デモで紹介された80コアの試作チップはIAコアでは
> なく、もっとシンプルなものだったが、IAコアを搭載するものを同社は開発中で、
> コードネームは「Larrabee」であることがGelsinger氏から明らかにされた。
>
> 実際のコア数がどのくらいになるのかは不明だが、命令セットが拡張された
> IAコアを搭載することになるようだ。これは製品化を前提にした開発のようで、
> 「来年にもデモが披露できる予定」とGelsinger氏。

そしてGPGPU終了のお知らせ

> 最後にMicrosoft ResearchのDavid Williams氏の「Intelのこのアプローチは、
> GPGPUコンピューティングに関するディベートを終わらせることになる」という
> コメントを引用し、Larrabeeに対する自信を見せた。

http://journal.mycom.co.jp/articles/2007/04/18/idf06/index.html
0560・∀・）っ-○◎●2007/04/19(木) 01:12:33
早い話がIntel版Cellだな
0561デフォルトの名無しさん2007/04/19(木) 01:19:22
さすが団子ﾁｭｰさん＾＾
0562デフォルトの名無しさん2007/04/19(木) 10:22:20
ダンゴの一言は重みがあるな
0563デフォルトの名無しさん2007/04/19(木) 20:33:33
GPUで出来ることの幅が広がるのはうれしいけど
本来のGPU的の使用には向かなくなってるのかな？
例えば、これからコアもっとリッチに、粒度をもっと細かくしていくと
行き着く先はCell+だよね。で現状CellはGPUの代わりは出来ていない。
0564デフォルトの名無しさん2007/04/19(木) 20:42:46
上の奴は何を言ってるんだ?
もっと勉強してこいと言いたい。
0565デフォルトの名無しさん2007/04/19(木) 20:51:19
今のGPUがやっているような、パラレリズムの特徴を利用してメモリアクセスの
レイテンシーを隠ぺいできるような仕組みがないと、PUの利用効率が悪くなって
大きなファクターでの性能向上は難しいような気がする。

個人的には David Williams 氏のいうことはあまり信用できないな。
0566デフォルトの名無しさん2007/04/19(木) 21:34:20
>>556-558
ItaniumやXbox360 GPUのプレディケーションって奴では？
XBOX360なら48 shader
分岐待ちしてるのと、演算にリソース使うの
どっちが良いんだろう？
まぁ、R520系のように分岐ユニット（？）をつければ良いのかな・
0567デフォルトの名無しさん2007/04/19(木) 21:42:32
G70系のように比較的大きい粒度だと小さいレジスタですんでたのが
R520系では小さい粒度のためG70系に比して大きいレジスタを搭載している。

NVIDIAはどうか知らないがAMDは更に小さくするんじゃないかな？粒度
05685362007/04/20(金) 18:36:53
取り敢えずCUDAのサンプルと同等の処理をgccでコンパイルして較べてみた。
3.4GHzXeonで66ms掛かる処理が8800GTXで0.23ms。
#サンプルはsimpleTexture。
こういうサンプルだと確かに速いね。
#いかん、Xeonの方はsse使ってないやw
05695362007/04/20(金) 19:28:19
で、Xeonでsse使ったら(ベクタ化してないけど)44msにはなった。
でも、200倍近く。これなら取り敢えず、実験でお金が貰えそうだw
0570デフォルトの名無しさん2007/04/21(土) 05:44:09
>>568
ども。
Xeon Quad DPのコア当たり性能が仮にNetburst Xeon 3.4GHzの倍だとしても、
x 2 x 4 x 2 でもまだ、10倍以上か。

double演算エミュレーションのサンプルみたいのはあるのかな？
0571デフォルトの名無しさん2007/04/21(土) 06:18:08
コード示さんとわからん。
05725362007/04/21(土) 08:21:24
GPU側はCUDAのサンプル、CPU側はそれを移植したもの。
どうしても見せろってことなら後で載せるよ。
#どうせだからこのPCでもコンパイルしてタイムを計ってみるか。
05735362007/04/23(月) 18:28:24
あー、載せるの忘れてた。CPU版のソースはこんな感じ。これをGPUのサンプルのtransform()と入れ替えて辻褄合わせた。
#でも、CUDAではgetData()相当で単純に整数化しないでニアレストネイバーか何かでサンプリングしているのでその分更に差が開く……

static float getData(float * data, float x, float y, int width, int height)
{
int ix = static_cast<int>((x + 1) * width + 0.5f);
int iy = static_cast<int>((y + 1) * height + 0.5f);
ix %= width;
iy %= height;
return data[iy * width + ix];
}
void transform(float * rdata, float* g_odata, int width, int height, float theta)
{
for (int y = 0; y < height; ++y) {
for (int x = 0; x < width; ++x) {
float u = x / (float) width;
float v = y / (float) height;
u -= 0.5f;
v -= 0.5f;
float tu = u*cosf(theta) - v*sinf(theta) + 0.5f;
float tv = v*cosf(theta) + u*sinf(theta) + 0.5f;
rdata[y*width + x] = getData(g_odata, tu, tv, width, height);
}
}
}
このコード、Celeron1.2GHzでは109msだった。
0574デフォルトの名無しさん2007/04/23(月) 19:42:27
>>573
おいおい、そのCPU用のコードはいくらなんでも冗談だろ？
05755362007/04/23(月) 19:49:31
>>574
何か問題でも?
getData()はCUDAのサンプルの出力からの類推ででっち上げたから問題があるとしたらその辺かな?
transform()に関してはCUDAのサンプルのロジックそのままだからそれについては何もコメントできないけど。
0576デフォルトの名無しさん2007/04/23(月) 20:21:04
>>575
CUDAで実行した場合に transformKernel() 内のすべてのロジックを
各画素について糞真面目に計算してるとでも思ってるのか？
そのCPUコードじゃGPUと対等じゃないよ。
0577デフォルトの名無しさん2007/04/23(月) 20:37:55
普通に考えて、width, height, thetaのみに依存する（入力ストリーム全体に対して不変の）
ロジックは先に計算してGPUの定数レジスタに格納する、くらいの最適化はしてるだろうね。
DirectXのHLSLシェーダをアセンブリにコンパイルしたときのpreshaderみたいに。
0578デフォルトの名無しさん2007/04/23(月) 21:22:20
>>573
CPU側をこんな感じにすればGPUの計算量に近くなるかな

void transform(float * rdata, float* g_odata, int width, int height, float theta)
{
　float inv_width = 1.0f / width;
　float inv_height = 1.0f / height;
　float sin_theta = sinf(theta);
　float cos_theta = cosf(theta);

　for (int y = 0; y < height; ++y) {
　　for (int x = 0; x < width; ++x) {
　　　float u = x * inv_width;
　　　float v = y * inv_height;
　　　u -= 0.5f;
　　　v -= 0.5f;
　　　float tu = u*cos_theta - v*sin_theta + 0.5f;
　　　float tv = v*cos_theta + u*sin_theta + 0.5f;
　　　rdata[y*width + x] = getData(g_odata, tu, tv, width, height);
　　}
　}
}

逆にCUDAのほうでsin, cosの中身をthetaだけじゃなくビルトイン変数blockIdxとかに依存させたら
各入力に対して毎回三角関数を計算せざるを得なくなるから劇的に遅くなるんじゃないかな
0579デフォルトの名無しさん2007/04/23(月) 21:58:44
gcc、それくらいの最適化は任せられなかったっけ？
気持ちが悪いから、可読性が落ちないなら、速い方にするけど。

>>573にもう一度回してもらうのが一番手っ取り早いか。
0580デフォルトの名無しさん2007/04/23(月) 22:24:02
>>579
sinf, cosfは外部のライブラリ関数で、Cコンパイラはその処理内容を知る立場にないから、
for文の中にある関数の呼び出し回数を勝手に減らすような最適化は普通しないと思うよ。
インライン関数だったらそういう最適かも可能だけど。
05815362007/04/23(月) 23:00:41
うい、流れは理解した。
明日にでも試してみる。

>>580
gccはsinf()はインライン展開しないようだね。
このテストじゃないけれど、iccはsincos同時に求める専用関数に置き換えるくらいのことはする。
iccの方は現在手元にないから水曜日になるけどテストしてみま。
0582デフォルトの名無しさん2007/04/23(月) 23:33:10
>>581
投げてばっかりで悪いけど、よろしく。
8600でも買おうかと思ってたけど、unitが半分のはずが1/4しかないんでちょっと萎えてる状態。
0583デフォルトの名無しさん2007/04/24(火) 06:46:36
CUDAって、Vistaにまだ対応してないよね？
あと、XPはx64にも対応してないけど、これってネイティブな64bitモードで動かないってだけ？
俺メインマシンがVistaとXP x64とのデュアルブートだから、CUDAの導入に踏み切れない・・・。
対応してるなら、早速グラボ買って来るんだが・・・
0584デフォルトの名無しさん2007/04/24(火) 06:58:26
積は最近遅くない気もするがね。

void transform(float * rdata, float* g_odata, int width, int height, float theta)
{
　float inv_width = 1.0f / width;
　float inv_height = 1.0f / height;
　float sin_theta = sinf(theta);
　float cos_theta = cosf(theta);
float v = -0.5f;
　for (int y = 0; y < height; ++y, v += inv_height) {
float u = -0.5f;
　　for (int x = 0; x < width; ++x, u += inv_width) {
　　　float tu = u*cos_theta - v*sin_theta + 0.5f;
　　　float tv = v*cos_theta + u*sin_theta + 0.5f;
　　　*rdata = getData(g_odata, tu, tv, width, height);
++rdata;
　　}
　}
}
05855362007/04/24(火) 17:56:14
ほい、お待たせ。
結論から言うと、10msそこそこまで速くなった。
#コンパイルオプションつけ捲くりw(-O3 -funroll-loops -msse2 -mfpmath=sse)

コードの方は>584をベースにgetData()も手動最適化したくらい。ってことで、念の為にコード。
static float getData(float * data, float x, float y, int width, int height, float wf, float hf)
{
int ix = static_cast<int>(x * width + wf);
int iy = static_cast<int>(y * height + hf);
ix %= width;
iy %= height;
return data[iy * width + ix];
}
呼び出し側は、
float width_half_up = width + 0.5f;
float height_half_up = height + 0.5f;
しておいて
*rdata = getData(g_odata, tu, tv, width, height, width_half_up, height_half_up);
ちなみにアセンブリ出力を眺めたところ、rdata[y*width+x]と*rdata, ++rdataでは一番内側のループ内のロジックは同一。
この程度の最適化はするらしい。どうやら主な違いはu, vを計算しなおすのにx, yを使う関係でcvtsi2ssが入る辺りじゃないかと。
#掛け算より遅いかどうかは知らないけれど。

ってことで、レスくれている人達THX。こちらもどうせいろいろ資料作らなければならないんで、ネタ提供してもらって助かってます。
#そう言えば、DOSPARA辺りで8800積んだBTOのPC出始めてますねぇ。
05865362007/04/24(火) 18:31:54
>>583
この辺は参考にならない?
http://forums.nvidia.com/index.php?showtopic=28716
0587デフォルトの名無しさん2007/04/24(火) 20:27:32
>>585
どうもです。10msそこそこってのはCeleron1.2GHzですか？
getData（テクスチャフェッチ）はGPUが非常に得意な部分だからそこでかなり差が付いてるかもね。
0588デフォルトの名無しさん2007/04/24(火) 23:38:13
Celeron 1.2GHzならメモリが遅過ぎでしょう。
あとCeleronの場合、整数だけで座標を演算した方が速いと思う。
それにしても比較するのは酷な環境。
0589デフォルトの名無しさん2007/04/24(火) 23:45:07
ところで時間計測はどのように行ってます？
05905362007/04/24(火) 23:49:26
いや、10msはXeon3.4GHz(>568-569参照)。
そう言えば、Celeronの速度は忘れてた。
05915882007/04/24(火) 23:55:05
あとこれCPUにもよるだろうけど、繰り返さなくていいなら

if ( unsigned(width-1-ix) < width && unsigned(height-1-iy) < height )
    return data[iy * width + ix];
else
    return 0.0f;

の方が速いよな。
本当はループの外で判定出来るからもっと速くなるけど
とりあえずこの程度は予測分岐で賄えるだろうと怠慢。
0592デフォルトの名無しさん2007/04/24(火) 23:56:58
何言ってるか分りにくいか。
ix %= width
みたいな除算が重たいから取り除くって話ね。
05935362007/04/25(水) 00:41:07
>>591-592
あー、それは敢えてCUDAサンプルの出力を見て合わせた。
最初は条件分岐でやったけど、確か大して時間変わらなかったように記憶している。

>>589
CUDAのサンプルの時間測定をそのまま使ってたんで、今調べたらgettimeofday()だった。
05945882007/04/25(水) 03:13:43
積に比べれば遥かに重いんだけど、流石にXeonでは誤差か。

けどGPUがサイズを二の累乗に限定していたのはこういうところにもあるはずで、
例えばwidthとheightが二の累乗に限定出来れば

ix %= width;

を

ix &= (width-1);

にして除算が排除出来る。
Celeronではかなり効果あるんじゃないかなあ。
0595デフォルトの名無しさん2007/04/27(金) 00:55:48
上の方でも条件分岐が必要な処理に関して質問があがってたのですが
イマイチ、ぴんと来ないので質問させてください。

遂に昨日8シリーズを手に入れたのですが、とりあえずは簡単に使えるBrookGPUでDCTを実装して試そうと思ったんです。
で、DCTで係数kiとして

kiの値は
ki=1/√2 (i=0)
ki=1 (i≠0)
って処理がありますが、
具体的には、こういう部分はどのように書けばいいのでしょうか？

ifが使えないとなると、せっかくforループを使わずにGPUに投げられるのに、ループ回してCPUでiの値を確認しなくてはいけなくなると思うんですが・・・

初歩的な質問で申し訳ないのですが、この辺具体的な話がイメージ出来なくて困っています。
0596デフォルトの名無しさん2007/04/27(金) 01:01:48
つか、ゲッパチ買ってきたんだけどCUDA糞じゃん

普通の文字列処理とかできねーじゃん。汎用GPUプログラミングとかいっておいて
なーんもできねーじゃんゴミだだまされた。明日nvidiaに電凸しよう。
0597デフォルトの名無しさん2007/04/27(金) 01:26:43
>>595のは、ちょっと例が悪かったです。
ごめんなさい(汗
ただ、他にifを使う部分は、やっぱり数式に直すしかないんですかね？
0598デフォルトの名無しさん2007/04/27(金) 01:42:26
>>597
悪いってレベルじゃねぇぞｗ

で、結局そこはCPU側に出すか
もしくは数式的に直せるのであればそうするしかないな。
CUDAは知らん。

>>596
はいはい。
使いこなせないだけですね。
文字列処理って何ですか？
文字列を数値化すれば、形態素解析であろうが、文字列マッチングであろうが
置換であろうが、余裕ですよ。
0599デフォルトの名無しさん2007/04/27(金) 06:51:15
>kiの値は
>ki=1/√2 (i=0)
>ki=1 (i≠0)
単純になら、ki=1-(1-1/√2)*(i==0)
i==0の時だけループからはずすのも手だし、
テクスチャを係数テーブルにするほうが普通じゃ。
0600デフォルトの名無しさん2007/04/27(金) 07:50:49
>>597
効率がどうなるかは知らんが、そういう用途ならCUDAの方が楽じゃない?
0601デフォルトの名無しさん2007/04/27(金) 09:50:02
BrookGPUで各ユニットで共通の変数を利用したい場合ってどうすればいいのでしょうか？

例えば、
for(int i=0; i<128; i++)
out[i]=i;

や
for(int i=0; i<128; i++)
out[i]=out[i]+5;

このようなパターンです。
0602デフォルトの名無しさん2007/04/27(金) 09:55:56
>>601
まず、後者の場合、reduceを使う

void reduce sum(reduce float res<>){
res=res+5;
}
こんな感じ

前者の場合。
イテレーターを使うんだと思うんだけど、ちょっと俺にもわからん。
06036022007/04/27(金) 09:57:59
って、うわ・・・
後者も間違ってる。。sumの問題じゃなかったのね。
すまん。

その場合普通に
kernel void (out float o<>){
o=o+5;
}
でいいじゃん。
0604デフォルトの名無しさん2007/04/27(金) 10:35:23
>>601

void reduce func(reduce float i<>, out float o<>){
o=i;
i=i+1.0;
}

後者は何が言いたいのかわからん。
普通で
0605デフォルトの名無しさん2007/04/29(日) 00:19:43
お前らCUDAやりなさい。

ところで、CgがあるのにCUDAを出す意義って？
nVIDIAは言語の乱立を自重汁
0606デフォルトの名無しさん2007/04/29(日) 00:46:51
Cgはシェーダー言語。HLSLのベースになった時点であるいていど成功。
CUDAはプログラミング言語。
0607デフォルトの名無しさん2007/04/29(日) 00:49:41
>>606
はあプログラミング言語ねえ
0608デフォルトの名無しさん2007/05/02(水) 03:02:44
>>595
conditional move とか select とか、そういう類の命令を持つ CPU とか GPU があるのね。
だから３項演算子とか>599のようなことで問題なし。
そんなことを気にするよりも、まずは動くものを作ってこことかどっかに投げないと、何が聞きたいのかわからんというか、何を答えても的外れになりそうな気分になって答えられない。
0609デフォルトの名無しさん2007/05/02(水) 13:22:28
BrookGPUって、intは使えないよね？
データがint型で、ストリームに送る前にキャストしても返ってくる値がおかしいから困る・・・。

こういうのってどうすればいいんだ？
0610デフォルトの名無しさん2007/05/03(木) 08:20:49
桁落ちが原因だろ。＞値がおかしくなる。
落ちない範囲に収めるor諦める
0611デフォルトの名無しさん2007/05/03(木) 18:01:20
コーヒーブレイク
ttp://www.forum-3dcenter.org/vbulletin/showthread.php?p=5449565#post5449565
ttp://www.forum-3dcenter.org/vbulletin/showthread.php?p=5450755#post5450755
R600のリークスライドなんですが、SuperScalar,SIMD,VLIW等
並列実行のキーワードが並んでます。
詳しい人、どうなんでしょうこのGPU。
0612デフォルトの名無しさん2007/05/04(金) 00:36:29
電気馬鹿食いDQNカードだぞ？
0613デフォルトの名無しさん2007/05/04(金) 13:22:12
これからGPGPUに入門しようと思って、手始めに3Kのテキストデータの文字列に+1するだけの単純コードで実験してみた。
BrookGPUが簡単だったので、こいつを使った。

kernel void func(float i<>, out float o<>){
o=i+1.0;
}

//streamRead(in1,inc1);
//func(in1,in1);
//streamWrite(in1,inc1);
for(i=0; i<2048;i++){
inc1[i]=inc1[i]+1;
}

//GPU:18秒
//CPU:9秒

…全然だめじゃん。GPGPUって
環境は、Athlon64 X2 4200+,GF8600GTS
これより式を複雑にしたら、もっとスーパースカラーなCPUがより有利になるでしょ。
GPUは、和積演算だけは、同時実行出来るんだっけ？
0614デフォルトの名無しさん2007/05/04(金) 13:36:48
>>613
それは計算量少なすぎ。
明らか転送のネックの方が大きいだろｗ
06156132007/05/04(金) 13:40:38
>>614
CPUの時も、streamReadとstreamWriteだけやるようにしてみました。
それでもCPU:16秒でした^^;
0616デフォルトの名無しさん2007/05/04(金) 14:10:15
>>615
それはつまり、GPUの処理時間は2秒ということだね。
……だからなに?
0617デフォルトの名無しさん2007/05/04(金) 14:20:32
転送時間を差し引いても、演算速度がCPUよりGPUの方が遅いって話だろ

そんなの冷静に評価してるやつはみんな言ってるじゃん
たまに『GPUはCPUの数十倍』とか夢見たいな話してる脳内お花畑さんが居るがｗ

0618デフォルトの名無しさん2007/05/04(金) 14:49:27
BrookGPUはデバッカはついてるのかな？
ブレークポイント設定してステップ実行とか出来るの？

今、主にHLSLで組んでいるんだけど
GPUデバッグがやりずらくて困ってるんけど
同じかな？
0619デフォルトの名無しさん2007/05/04(金) 15:11:56
>>618
BrookGPUって、単なるコンバータだよ。
結局Cgのデバッグ作業になるが・・・。
Cgは、nVIDIAがそういうツールを提供してる。
0620デフォルトの名無しさん2007/05/04(金) 15:39:12
>>613

大量にデータを送り込めば数で勝るGPUは高速
しかし、BrookGPUのstreamは2048くらいしか要素を確保出来ない。
その程度では、GPUコア全てを使い切れないので、CPUの方が高速。

これの意味はもう分かるよな？

さっさと、CUDAでも覚えるんだ。
0621デフォルトの名無しさん2007/05/04(金) 15:44:08
BrookGPUなんて海外じゃもう糞確定してるって見方が大半だよ。GPGPUで
最先端いってるやつらに、BrookGPUwって感じで笑われるしなぁ。


0622デフォルトの名無しさん2007/05/04(金) 15:50:31
BrookGPUはお遊び言語なのは知ってるけど
じゃあ、何が良い言語なんだ？
CUDA出る前からGPUは騒がれてたんだから、CUDA以前から扱いにくくともCPUよりちゃんと速度が出るのはあるんだろうね？

SHとか使ったが、あれは、ちょっとなぁ・・・
0623デフォルトの名無しさん2007/05/04(金) 15:58:54
実際に海外の優秀なやつはら暇つぶし程度にしかいまのところやってないよ
速度云々は別にどうでもいいって感じだよ。ただできましたって感じだよね


0624デフォルトの名無しさん2007/05/04(金) 15:59:51
…おい
誰も何でつっこまんの？
行列演算させずに、１次元計算させてどうするんだ。

まずは、GPUに計算させる前に、Gridにデータを落としこむべきだろ。
Gridにデータを落とし込むような価値の無い計算ならば、するな。


本当にレベル低いな、おい…
0625デフォルトの名無しさん2007/05/04(金) 16:03:56
>>624
何マジレスしてるんだよw？
0626デフォルトの名無しさん2007/05/04(金) 16:17:52
行列に落とし込むくらいだったら、CPUに演算させた方が・・・ｗ

たまに出てくるGPGPUで有効な例とする
for(i=0;i<SIZE_N;i++){
out[i]=in[i]+1;
}
こういう処理を否定してちゃあ、世間のジャーナリストは嘘つきだなｗ
0627デフォルトの名無しさん2007/05/04(金) 18:55:00
ttp://mumei24.run.buttobi.net/cgi-bin/upload.cgi?mode=dl&file=971

DLパス:gpu

トーラスをランバートのシェーディング（ｃｇ）で表示するだけのプログラムなのですが
どうも動かないです。OPENGLです。

誰か助けてください。
0628デフォルトの名無しさん2007/05/06(日) 00:11:23
>>611
リンク先は流し読みしただけだけど。

SuperScalarやらSIMDやらは今更な感じがする。
今までってSuperScalarじゃなかったんだっけ？
少なくともSIMDだったよな。

VLIWはちょっと気になるな。
GPUに既存のCPUのアーキテクチャでやられたヤツを色々持ち込むのはいいんだけど、
効率（性能）が向上するかは未知数だし、
GPGPU的に使いやすいかは別問題だったりするし、
どうなるんだろうね。

と、思ったことを適当に書いておく。参考にならんな。
0629デフォルトの名無しさん2007/05/07(月) 01:27:32
GPUはSPMDだろ。
まぁCUDAで言えばWarpはSIMDだが、いずれにしてもGridレベルのSPMD。
0630デフォルトの名無しさん2007/05/09(水) 18:24:24
627ですが…反応ないですか
0631デフォルトの名無しさん2007/05/09(水) 22:08:54
>>630
激しくスレ違い。
ここはコンピュータグラフィックス関連のスレじゃないよ。
0632デフォルトの名無しさん2007/05/10(木) 19:04:59
…スレ違いなんですか
他スレの方が汎用コンピューティングとあったのでこちらで聞いたのですが
0633デフォルトの名無しさん2007/05/10(木) 22:31:23
GPUスレと勘違いしてないか？
GPGPUスレだぞ。汎用的にGPUを使おうってスレで、本来のグラフィックス処理がらみはスレ違い。
0634デフォルトの名無しさん2007/05/11(金) 00:05:44
OpenGLスレとかその辺かな。
0635デフォルトの名無しさん2007/05/13(日) 22:58:51
このスレッドの人ってあかでみっくぽすとの人が多いのかな
0636デフォルトの名無しさん2007/05/14(月) 01:27:35
中途半端に賢い人が多いんだよ
0637デフォルトの名無しさん2007/05/15(火) 07:05:44
>>611
ttp://techreport.com/reviews/2007q2/radeon-hd-2900xt/index.x?pg=3
float MAD serial以外は、概ね速い。
0638デフォルトの名無しさん2007/05/17(木) 02:43:02
最近シェーダを学び始めた者です。

調べた結果、自分の中で結論出たようなものなのですが、
最後の確認として質問させてください。

シェーダで、32bit整数を扱うことは可能でしょうか？（ベクトル型で）
もし可能であれば、シェーダモデルやベンダ拡張等問いません。

GPGPUな目的で学習していますので、このスレで質問させて頂きました。

よろしければご教授お願いします。
0639デフォルトの名無しさん2007/05/18(金) 11:28:03
Cgでint4が出来れば扱えるんじゃない
0640デフォルトの名無しさん2007/05/18(金) 22:35:37
CUDAは、さっさとXP x64とVistaに対応するべきだ。
俺、この2つのデュアルブートだから、せっかく8シリーズ買ったのに・・・。
これのために買ったのになぁ・・・orz
0641デフォルトの名無しさん2007/05/19(土) 00:02:18
>>639
ありがとうございます。
試してみます。
0642デフォルトの名無しさん2007/05/19(土) 21:48:38
ATI RADEON X800 XTで
Ｃｇの中でforやらbreakが使えないみたいなエラーが出たんだけど

これってどこで確かめれるの？
0643デフォルトの名無しさん2007/05/19(土) 23:25:09
>>640
ゲフォ8800なんて買う変態がXP 32bitにするわけがないからなぁ。







本当に本腰入れたいんならVista&XP×32bit&64bit全部入りだろうけど。
とりあえずコンパイルしてエミュで動かしてみたが速度とかどうってより
operatorやらtemplateやらが通るのに吹いた
0644デフォルトの名無しさん2007/05/20(日) 01:18:59
>>643
CUDAのこと? あれ、だってコンパイルにはgcc使ってるもの。
0645デフォルトの名無しさん2007/05/20(日) 14:17:03
あーそりゃそうだな
0646デフォルトの名無しさん2007/05/26(土) 21:56:13
ねねCUDAで

if(input == 'a'){
...
}
else if( input == 'b'){
...
}

て処理書きたいんだけどどうやって書けばいいか教えてください
0647デフォルトの名無しさん2007/05/26(土) 21:58:16
無理
0648デフォルトの名無しさん2007/05/26(土) 22:57:06
なんだとぉ
ふざけるんじゃねーよ教えてくれよマジ切れするぞ
ゆとり世代は沸点低いんだよ忘れたのか？
0649デフォルトの名無しさん2007/05/26(土) 23:35:02
＞ゆとり世代は沸点低いんだよ忘れたのか？
ちょっと地面に穴掘って埋まってきたら?
圧力掛かると沸点高くなるっしょ。
0650デフォルトの名無しさん2007/05/26(土) 23:56:46
>>649
なめてんのかコラいいかげんにさっさと教えろよ
0651デフォルトの名無しさん2007/05/27(日) 00:00:20
マジレスしてやるよ
CUDA SDKにはエミュついてるから、自分で試しヤガれ
コンチクショー
0652デフォルトの名無しさん2007/05/27(日) 00:23:39
だから無理だって言ってるだろ。
GPUには、条件分岐するキーワードは無い。
予めCで分岐してから、各処理を呼び出すしかない。
0653デフォルトの名無しさん2007/05/27(日) 00:38:12
じゃあ
abcdefjを128bitのhexとかに予め変換してとか小細工しても

strstr()なんかを作ることは無理なのか？
0654デフォルトの名無しさん2007/05/27(日) 11:33:06
>>653
もちっと、じぶんのあたまでよくかんがえてからしつもんしよう。
ぺたっ　（もうすこしがんばりましょう）
0655デフォルトの名無しさん2007/05/27(日) 11:34:31
>>654
わかんねーからきいてるんだろうが
こちとら時間ねーだんよささっと情報晒せ
0656デフォルトの名無しさん2007/05/27(日) 12:11:24
時間ないなら諦めたら?
0657デフォルトの名無しさん2007/05/27(日) 12:12:27
>>656
悪かった取り乱してしまった。すまいと反省している。
ね？ね？ヒントでいいかなんか情報くださないな
0658デフォルトの名無しさん2007/05/27(日) 12:56:58
なかなか釣れませんね
0659デフォルトの名無しさん2007/05/29(火) 01:34:39
あのー誰か教えてよぉもう2日もがんばってるけど
できないよ
0660デフォルトの名無しさん2007/05/30(水) 08:32:29
>>659
そもそもなぜGPUでstring処理を行いたいのでしょうか？？

いくらCUDAでGPUを汎用プログラミング用途に使えるようになったと
言っても、やはりGPUが得意とするのは大量の単精度浮動小数点データ
に対する演算だと思うのですが。
0661デフォルトの名無しさん2007/05/30(水) 13:59:24
余計なお世話だろ
0662デフォルトの名無しさん2007/05/30(水) 14:36:51
すみませんでした
0663デフォルトの名無しさん2007/05/31(木) 00:38:24
>>660

1024bitとかまぁもっと長いbit列の処理をさせた場合
現状どの程度優位（もしくは無意味か）データが採りたいんですよ。

だれか具体的にいくらって数値出していただけるならうれしいのですが
そんなもん自分でやれっていわれるのはまちがいないのでCUDAで
どうやって作ればいいのかちょっと聞いてみたかったんですよ。
未だにできないでうーむってうなってますよw
0664デフォルトの名無しさん2007/05/31(木) 01:00:22
>>663
CUDA SDK付属のエミュでまずは作れ。
そしたら実機で回してみせるよ。
0665デフォルトの名無しさん2007/05/31(木) 01:02:10
>>663
CUDA SDK付属のエミュでまずは作れ。
あうあう？うーんうーん？エミュってどこにあるの
それいってくださいよーもー
0666デフォルトの名無しさん2007/05/31(木) 01:08:06
まずはダウソしてインスコしてビルド汁
話はそれからだ

http://developer.nvidia.com/object/cuda.html
0667デフォルトの名無しさん2007/05/31(木) 01:22:09
64bitじゃ無理じゃーん
どうしろっていうんだorz
0668デフォルトの名無しさん2007/05/31(木) 02:35:44
俺もXP x64とVistaのデュアルブートだから無理だったんだよな・・・prz
0669デフォルトの名無しさん2007/05/31(木) 07:54:50
>>667
欲張って64bitのマシンを買うからだ
0670デフォルトの名無しさん2007/05/31(木) 09:40:38
大丈夫、漏れは64bit機で32bitRedHat入れている。
#勿論、CUDAは問題なく動く。
0671デフォルトの名無しさん2007/05/31(木) 23:27:42
http://grape.astron.s.u-tokyo.ac.jp/~makino/articles/future_sc/note048.html
http://jp.arxiv.org/pdf/astro-ph/0703100

実用の計算で150Gflopsなら立派なもんだね。

負け惜しみで発熱に文句付けてるけど、
1年半すればミドルレンジ、3年後にはノースのおまけになるのがGPU。

残念ながらGrapeはお終い。
0672デフォルトの名無しさん2007/05/31(木) 23:32:08
演算アクセラレータボードを作っている会社も危ない状況ですね。
某社のボードなんか100万とかする挙句に開発環境がそれの倍以上だもんなぁ。
0673デフォルトの名無しさん2007/05/31(木) 23:52:47
ねぇねぇubuntu x64環境でどうやってCUDAするの？
toolとcudaいれたけどVideoのドライバがインスコできない
なんで？
0674デフォルトの名無しさん2007/05/31(木) 23:54:34
ERROR: this .run file is intended for the
Linux-x86 platform, but you appear to be
running on Linux-x86_64. Aborting installation.

とか出るのですが原因が判りません。
0675デフォルトの名無しさん2007/05/31(木) 23:59:43
>>674
日本語の参考書が出るまで、あんたにはCUDAは使えない。
日本語の参考書が出たらまたどうぞ。
0676デフォルトの名無しさん2007/06/01(金) 00:26:47
>>671
いやさすがに3年後でmGPUにはならないでしょ…
0677デフォルトの名無しさん2007/06/01(金) 01:30:32
>>674
エラーメッセージにダメな原因がはっきりと書いてあると言うのに、
これでも文章の意味が分かりませんか。はぁーーーーー。

# 日本の英語教育がよくないのか、それとも674氏特有の問題なのか。

ネイティブスピーカーが何を言っているのかなかなか分からない私で
すが、文字として書かれていれば、これくらいの文章は普通に理解で
きないものですかねぇ。

なんだかんだ言っても実質的に世界標準言語は英語なわけで、GPGPU
とか言い出す前に、まずは中学・高校レベルの英文は読めるようになる
必要があると思います。

# それができないなら、675氏の言う通りだと思います。
0678デフォルトの名無しさん2007/06/01(金) 01:34:26
いや、日本語の参考書が出てもダメでしょ。
0679デフォルトの名無しさん2007/06/01(金) 03:14:22
>>671のサイトのはGRAPEの製作者のところなので
自分たちのシステムの優位性をアピールしたいんだろうが
その人たちですら、性能面でのGPUの優位性はもはやみとめざるを得ないと言う事だろうな。





しかしまぁ、CUDAの実行環境の話もそうだけど
さっさとGPGPUの環境整えてくれ。Vistaやx64非対応ってやる気あんのかと
0680デフォルトの名無しさん2007/06/01(金) 03:16:42
一般人は、エラーメッセージの内容を信用しないって所があるんじゃね？
多分、そのメッセージが日本語でも同じ。

理由は、Windowsのような、全くもって何の解決にもなってないようなエラーを吐く環境に鳴れたせいかと。
アプリケーションの強制終了の時のエラーダンプを、アプリケーションの作者に送っても殆ど無意味だし。
ブルースクリーンのエラーメッセージをコンピュータのサポートに送っても無意味だからなぁ
0681デフォルトの名無しさん2007/06/01(金) 23:10:00
おいハードディスク買ってきたから32bitOS入れるから
教えてくれるよね？
0682デフォルトの名無しさん2007/06/02(土) 14:26:11
環境は今からそろえるつもりとして、はじめるとしたらCUDAとCgどちらがいいですか？
0683デフォルトの名無しさん2007/06/02(土) 14:33:49
両方やれば?
0684デフォルトの名無しさん2007/06/02(土) 15:37:28
ねぇねぇねぇ
CUDAで
NVIDIA: could not open the device file /dev/nvidiactl (No such device or address).
とかでるんだけどさ、なんで？
NVIDIA-Linux-x86-1.0-9751-pkg1.tar.gzこれいれたんだけどさ。
いまカードはGeforce7950GTXなんだけどエミュで動かせるって聞いたけど違うのかな？
カード走って買ってこないとダメ？
0685デフォルトの名無しさん2007/06/02(土) 16:17:50
GPUチップを認識できてないとそうなった希ガス。
nvcc動かすだけなら大丈夫だと思うけど。
0686デフォルトの名無しさん2007/06/03(日) 02:02:23
エミュ用のディレクトリのを実行した？
0687デフォルトの名無しさん2007/06/03(日) 12:43:44
サンプル動いたぉ
0688おしえてちゃん2007/06/03(日) 14:27:02
gpgpu志向のプログラム作ろうとしてます。
ですがいきなり分からないことが、出てきました。

点を二つ作り、その点の大きさをgl_PointSizeを使って
大きくしたら、点が重なりました。その重なった部分の混合色は
どのようにつくられるのですか？

1,(vertex + fragment シェーダでの処理を一単位と考えて)
二度シェーダプログラムを呼んで色の混合を作る。
2,（上と同じ考えで）一度で処理する。
3,そのほか

同じカーネルに、複数の色を叩き込むということなので、
その色の混合処理の方法がわからないのです。

一体どれなんでしょうか？
0689デフォルトの名無しさん2007/06/03(日) 18:14:52
あまりGPGPU指向の話じゃないねぇ
0690デフォルトの名無しさん2007/06/03(日) 19:24:42
ちょいCUDAで質問
とりあえずCUDAの手順として
デバイス初期化
メモリ初期化（host,dev)
計算
終了処理
という感じになっているが、なんでkernelの関数呼び出す時こんな
キモい呼び出しになってるの？すっげーキモくて違和感ありありなんだが

testKernel<<< grid, threads, mem_size >>>(d_idata, d_odata);

こんなアフォな呼び出ししたくねーよw
0691デフォルトの名無しさん2007/06/03(日) 19:55:22
その呼び出しのどの部分がキモいのか具体的にお願いします。
0692デフォルトの名無しさん2007/06/03(日) 20:43:48
逆にそれだけで済んでしまうところが肝なんだが。
0693デフォルトの名無しさん2007/06/03(日) 21:10:34
今エミュだけだからよーわからんのだけど
__device__と__global__って再帰呼び出し禁止だけど

２つの関数交互に呼ぶのはOKなのかなぁ？
エミュだとOKに見えるのだが実機だと動かなそうだがうーん

0694デフォルトの名無しさん2007/06/03(日) 22:12:09
ソース上げてくれたらテストするよ。
0695デフォルトの名無しさん2007/06/03(日) 23:13:18
__device__ hogeから__device__hoge1を呼び出せないのは痛いなぁ。

inline展開できない場合は処理不可能なのかぁうーむ。これにはちと
まいったな
0696デフォルトの名無しさん2007/06/07(木) 23:58:14
なぁなぁ

Geforce8800GTXでCUDAするとき
sharedメモリいくらになるの？
各ブロックはいくらになるの？

その辺の情報がいまいちよーわからんのだが
0697デフォルトの名無しさん2007/06/08(金) 07:41:27
CUDAが未だにVistaやx64に対応できないのは何か理由があんの？
もうかなり経つよね。
0698デフォルトの名無しさん2007/06/11(月) 00:43:57
GPGPU完全死亡
http://pc.watch.impress.co.jp/docs/2007/0611/kaigai364.htm
0699デフォルトの名無しさん2007/06/11(月) 02:23:44
>>698
こんなのセルと大してかわらへん
並列度が低すぎる
0700・∀・）っ-○◎●2007/06/11(月) 03:08:05
IA命令セットと互換ってのがみそだろ。
どうせSSEだろうけど。
0701デフォルトの名無しさん2007/06/11(月) 07:00:21
で、どれだけ広まるのよ？一般に。
GPU以上に広まる可能性はあるのけ？
0702・∀・）っ-○◎●2007/06/11(月) 07:04:13
そもそもGPUじゃないし
ただGPUで出来るGeneral Processingのおいしい部分は全部持ってっちゃうと思う。
x86のコードがそのまま動く意味は大きい。
0703デフォルトの名無しさん2007/06/11(月) 07:04:20
しかも2009年まで出てこなんじゃ
インテルお得意のキャンセルされるかもしれないしね
0704デフォルトの名無しさん2007/06/11(月) 07:22:53
てことは、一般には浸透しない可能性の方が大きいな。
Intelの資料にはLarrabeeだけで4CPU(?)構成の絵があったりするから
OSもそのまま走るのかも？

Tera Tera Teraには下記の記述がある。
LARRABEE ??TERATERA--SCALE SOLUTIONSOLUTION
Discrete high end GPU on general purpose platform
TeraFlopsof fully programmable performance
GPU ->16 cores @ ~2.0GHz, >150W
JPEG textures, physics acceleration, anti-aliasing, enhanced AI, Ray Tracing etc.
0705デフォルトの名無しさん2007/06/11(月) 18:39:47
CPUコアがいくら増えたところでGPUの性能が落ちる訳じゃないし。
0706デフォルトの名無しさん2007/06/11(月) 19:57:52
GPGPUよ、短い命であった。
0707デフォルトの名無しさん2007/06/11(月) 22:43:50
そう、CPUのコアが増えたところで
GPGPUを使えば更に速くなるわけで、どっちか切り捨てるとかそういうものじゃないでしょ。
使えるものは使うと速くなるんだから。この場合は　だけどｗ
0708デフォルトの名無しさん2007/06/11(月) 23:07:43
例えば今まで
CPU10 + GPU25 = 35
で処理できていたことが
CPU20 + GPU25 = 45
で処理できるならそれはいい。
なんで
CPU20 = 20にGPU切り捨てる必要があるんだ
0709デフォルトの名無しさん2007/06/11(月) 23:15:13
しかも、CPUよりはGPUの方が安い罠。
0710デフォルトの名無しさん2007/06/11(月) 23:18:20
30コアのCPUがいきなり一万円台で買えるとは思えないが。
よっぽど一世代前の高級GPUのほうが安く買えるかも。
0711デフォルトの名無しさん2007/06/11(月) 23:41:11
PCI-Expressに挿せる超高速コプロならなんでも売れると思うけどね。
GPUでも糞INTELの石でもなんでもいいけどね
0712デフォルトの名無しさん2007/06/11(月) 23:46:48
そうは言ってもClearSpeedはベンチマークスコア上げるのには
有効だが実用面ではちょっと。
0713デフォルトの名無しさん2007/06/11(月) 23:51:48
あれは期待外れだった。糞高いコンパイラだけで性能出せないんじゃ……ねぇ。
0714デフォルトの名無しさん2007/06/12(火) 07:29:59
「Larrabeeが登場したら、ハイパフォーマンスコンピューティングのベンチマークを
総なめにする可能性がある」とある業界関係者は期待を語る。

Larrabeeのターゲットアプリケーションは、一目見てわかる通り、GPUがGPGPU
でターゲットにし始めている領域と完全に重なる。つまり、LarrabeeはIntelによる
GPGPUの動きに対する回答だ。IntelとGPUベンダーは、ハイパフォーマンスな
浮動小数点演算性能が必要な並列コンピューティングの領域で、真っ向から
ぶつかることになる。
0715デフォルトの名無しさん2007/06/12(火) 14:02:27
LarrabeeはSSL対応レイヤ3スイッチのアクセラレータや
重めのアプリケーションサーバにも向いているような気がする。
値段次第だけど。
0716デフォルトの名無しさん2007/06/15(金) 05:53:00
R600のプログラム形態はSPIのStorm-1に近いかも知れん。
0717デフォルトの名無しさん2007/06/15(金) 06:11:31
ttp://journal.mycom.co.jp/articles/2007/02/15/isscc1/
>Stream ProcessorはDPUの他、2つのマイコン(MIPS 4000Ec)を搭載している。
>一つはSystem MIPSと呼んでおり、管理用OSが動作している。
>もう一つはDSP MIPSと呼んでおり、ここでメインアプリケーションが動作し、DPUをマネージメントする。

>並列アーキテクチャを備えたDSPながら、データ処理ロジックの開発は極めて簡単だという。
>アプリケーションはシングルスレッドプログラミングで記述すればよく、複数のレーン間の協調や、
>分散して配置されているメモリのマネジメントについて考慮せずに開発ができるという。
>複数のレーンには同じ命令を配置するので、レーン間で因果関係は出ない(出ないように
>各レーンに割り当てるデータの切り方を考慮する必要がある)。
>また、メモリのマネジメントはコンパイラが自動的に行う。
>このため、マルチスレッドプログラミングが必要なマルチコアDSPよりも、
>アプリケーション開発が楽であるという。しかも、将来の製品展開によってレーンの数が増減した時にも、
>ほぼ同じアプリケーションを使い続けることができるというスケーラビリティを持っているという。

R600の場合command processorとUltra-Threaded Dispatch Processorを二つのMIPS
レーンをShaderと置き換えれば似てるかも知れんね。
ただしR600の場合そのレーンのブロックが4つある。
0718デフォルトの名無しさん2007/06/15(金) 19:06:16
GPGPUでGrapeオワタと思たらメニーコアでGPGPUオワタ
0719デフォルトの名無しさん2007/06/19(火) 20:26:20
GPGPUを使った類似画像検索とか面白そうだが
どこもやってないのかな？
0720デフォルトの名無しさん2007/06/19(火) 21:52:03
画像のパターン検索？ならやってた人がいたと思う
0721デフォルトの名無しさん2007/06/19(火) 23:10:03
まぁそういう用途はGPGPUよりもこういうほうが面白そうだけどスレ違いか
ttp://www.k2.t.u-tokyo.ac.jp/vision/M-SIMD_architecture/index-j.html
0722・∀・）っ-○◎●2007/06/20(水) 00:57:06
DirectX10でGPUを汎用整数プロセッサとして使うサンプルある？
0723デフォルトの名無しさん2007/06/20(水) 01:19:03
今更R600って、…MSX Turbo-R？
0724部外者('A`)NEET ◆xayimgmixk 2007/06/20(水) 11:57:32
あれは、R800だろ。
0725デフォルトの名無しさん2007/06/20(水) 16:44:13
SEGA の体感ゲームだっけ?
0726デフォルトの名無しさん2007/06/21(木) 01:21:12
R3000じゃなかったっけ？
ジオメトリエンジンついてるんだよな？
0727デフォルトの名無しさん2007/06/21(木) 05:39:54
ttp://www.dailytech.com/article.aspx?newsid=7772
NVIDIA Announces Tesla General Purpose Processor Platform

ttp://pc.watch.impress.co.jp/docs/2007/0621/nvidia.htm
NVIDIA、G80ベースのHPC向けGPU「Tesla」
～PCI Expressカードタイプから1Uラックまで

>Teslaのソフトウェアプラットフォームは同社の汎用プログラミングモデル
>「CUDA (Compute Unified Device Architecture)」を利用。
>CUDAにはGPU用のCコンパイラが含まれており、
>Cプログラムに若干の修正を加えるだけで、
>CUDAコンパイラが処理をCPUとGPUに振り分けられる。
0728デフォルトの名無しさん2007/06/21(木) 06:05:30
新しいGPGPU
ttp://www.gpucomputing.eu/index3.php?lang=en&page=_library1.php&id=3
ttp://www.gpucomputing.eu/index3.php?lang=en&page=_demo4.php&id=3
0729ktkr!2007/06/26(火) 11:26:50
ktkr!

Linux
[Download x86, x86-64] CUDA Tookit version 1.0

Windows
[Download] CUDA Tookit version 1.0 for Windows XP (32-bit)
[Download] CUDA SDK version 1.0 for Windows XP (32-bit)
[Download] Windows Display Driver version 162.01 for CUDA Toolkit version 1.0

ttp://developer.nvidia.com/object/cuda.html




....ちょ、x64とかVistaは?
0730デフォルトの名無しさん2007/06/26(火) 11:50:15
お、情報THX。
早速見てみなくちゃだわ。
0731デフォルトの名無しさん2007/06/26(火) 12:15:19
もう完全にCUDAはやる気ないんじゃない？

うちはXP x64とVistaのデュアルブートだから、完全にアウト。
0732デフォルトの名無しさん2007/06/26(火) 12:17:27
>>731
大丈夫、TesraがあるからCudaは終わらない。
0733デフォルトの名無しさん2007/06/26(火) 14:56:23
こりゃあrapidmindの勝ちかな
0734デフォルトの名無しさん2007/06/26(火) 15:51:35
x86_64 でXPとかビスタなんて使ってるやついたのか？
0735デフォルトの名無しさん2007/06/26(火) 15:54:31
GPGPU用途に限ればLinuxでもいいのか。
CUDAカーネルの5秒制限も払拭されることだし。
0736デフォルトの名無しさん2007/06/26(火) 18:51:32
残念。Larabeeの一人勝ち。
0737デフォルトの名無しさん2007/06/26(火) 19:15:32
CUDAの分野とかから考えて、Vistaとx64を避ける意味がわからん。
特にVistaでは、GPUの仮想化をサポートしてるんで、まさにGPGPUの為の実装みたいなもんなのに・・・
0738デフォルトの名無しさん2007/06/26(火) 20:32:02
Larrabeeは2009-2010登場のでGPU軍勢が散々広まってしまった後だ。
それにGPUは3世代進歩する。
専用ライブラリやランタイムが必要ならISAがx86である意味は薄い。
ましてや32コアを意識してプログラムを組めなんて気の遠くなることは・・・
Larrabeeだけこける。

GPU軍勢の影の総大将がMicrosoftであることは間違いない。
0739デフォルトの名無しさん2007/06/26(火) 20:52:27
>>737
じゃあDirectX10.1が出る頃には対応するんじゃないか
0740デフォルトの名無しさん2007/06/26(火) 21:11:16
PeakStreamを忘れないでください…と思ったけど買収されたしナァ
0741デフォルトの名無しさん2007/06/26(火) 22:39:50
>>738
そんなばかなｗ
GPU軍勢って、nVIDIAだけじゃん。
結局IntelとAMDの天下だよ。
0742デフォルトの名無しさん2007/06/26(火) 22:46:43
ララビー来るまでにTeslaがどれだけ普及するかだなぁ。
取り敢えずCUDA1.0を788GTSで動かすかな。
0743デフォルトの名無しさん2007/06/26(火) 22:58:45
歴史的に見て、このプロセッサ(GPU)をCPUが取り込もうとして
失敗する事は殆ど無い。最終的にCPUに取り込まれるのは必然だと思われ。

性能云々の問題ではすまない。それで住むならMIPSは勝利していたはず。
キーとなるとは、いかにGPUを汎用的に使えるようにするか　だ。
GPUのメリットはぶっちゃけてしまえばコア数の差だ。これがもっと汎用的な事が可能なCPUもコアが増えるとなれば大変だ。
向き不向きで確かにGPUの並列化のほうが得策かもしれないが、その差が微々たる物であった時、はじめは部分的に使われても、最終的には全てを飲み込まれてしまう。

CUDAがx64やVistaに対応しないとか、馬鹿な所で詰まってる場合ではない。
今のメリット(先行)を生かさないと・・・。
本当に何を考えてるんだか・・・。
0744デフォルトの名無しさん2007/06/27(水) 01:05:29
先生！
強い電波を観測しますた！！
0745デフォルトの名無しさん2007/06/27(水) 01:39:32
>>743
まー、さっさと対応して欲しいよね。
俺もCPUに取り込まれてx86になったら、人は流れると思う。
特定分野はわからんけど、それならそれでx64に対応しろよ。
何もかもが中途半端
0746デフォルトの名無しさん2007/06/27(水) 01:45:07
長文いってみようか。

性能ではなく普及台数の勝ち負け（プラットフォーム足り得るか）で言えばTeslaは間違いなく「負け」だな。
研究者は独りでｵﾅﾆｰしてﾊｧﾊｧできるだろうが、需要となるキラーアプリが無い限り一般消費者が飛びつくわけがない。
どっかのアホがPPUでレイトレとか風呂敷広げてたが、PPUと同じように普及せず終わる。
（つかそもそもTeslaは一般向けじゃねぇし）

GPUはGPUたる所以のラスタライザ周りのハードワイヤード機能が足枷となって
電力消費の観点からも性能は伸び悩むだろうが、Vistaや3Dゲームで元々GPUは需要があるだけに可能性はある。
ただ現状ではVistaは全く普及していないし、CUDA・CTMとベンダ毎に仕様が異なるから
2010年にLarabeeが登場する頃までは標準化も達成されずグダグダが続くだろう。

ってことでIntelとAMDが談合してx86にデータ並列のストリーム処理命令を新たに追加して終わりだな。
LarabeeでもFusionでも使えるとなれば勝ち決定。
0747デフォルトの名無しさん2007/06/27(水) 02:10:44
と思ったがLarrabeeは全部のコアでフルx86が走るのか。
そうなると>LarabeeでもFusionでも使えるとなれば～は無いな。
0748デフォルトの名無しさん2007/06/27(水) 02:28:25
CPU/MCHどっちにくっついていようがオンボードVGAがシェーダー重視で肥大化して
いったら、逆にS3（VIA）その他の弱小グラフィックスが再び脚光を浴びる。

（PCIeカードの）GPGPUは大学の研究室/個人レベルで使われるだろうが、それで終わる。
チップ自体の価格は大量生産を背景に競争力を持てるが、プログラミングコスト、電力
コストを考えると中～大規模案件では採用されない。

Larrabeeは詳細不明、リリース次期から逆算すると現時点でテープアウトしてなさそう。
後藤記事によると「“練習版”、本格的な製品とは言えない」(業界関係者)。とのことで、
実用化への道は長い。

5年後を予想すると、HPCクラスタ界隈はOpteronやXeonやPowerPCが引き続き使われ、
クライアント環境でのベクトル演算/SIMDはSSEの進化で間に合う。
0749デフォルトの名無しさん2007/06/27(水) 02:38:09
639 ：Socket774 [sage] ：2007/06/18(月) 23:35:29 ID:j/fCz3TG
http://it.nikkei.co.jp/business/news/release.aspx?i=162405
システム価格の安いｘ８６サーバーのクラスターシステムへの需要シフトが
継続するとＩＤＣではみています。
２００６年におけるｘ８６サーバーは前年比４０．６％増で、４年連続で前年比プラス
成長となりました。国内ＨＰＣ市場におけるｘ８６サーバーの出荷金額構成比は、
過去最高の３６．６％に達しました。
ＲＩＳＣサーバーからｘ８６サーバーに民間企業のＨＰＣ需要がシフトしたとみられ、
民間企業向けの大規模クラスターシステムが好調でした。

678 ：Socket774 [sage] ：2007/06/27(水) 01:35:36 ID:Kgk8gcuA
Sun，ペタフロップスを実現可能なSolaris機を披露へ
http://techon.nikkeibp.co.jp/article/NEWS/20070626/134833/
Rangerには米AMD社のクアッド・コアを6576個以上搭載する。
当初のピーク性能は105TFLOPSだが，2007年中にピーク性能を
421TFLOPSに引き上げる計画である。

IBM社の次世代BlueGene，米Argonne研が導入へ
http://techon.nikkeibp.co.jp/article/NEWS/20070626/134832/
今回のBlue Gene/Pの演算性能は114TFLOPS。
2007年秋には3万2768個のプロセサから成るシステムになる。
各プロセサは，4個のCPUコアを1チップ上に集積した，いわゆる
クアッド・コアである。
0750デフォルトの名無しさん2007/06/27(水) 02:39:19
670 ：MACオタ [sage] ：2007/06/26(火) 22:25:47 ID:E+b+TZBO
Blue Gene/Pのプレスリリースす。
http://www-03.ibm.com/press/us/en/pressrelease/21791.wss
　　---------------------
　　Four IBM (850 MHz) PowerPC 450 processors are integrated on a single Blue Gene/P
　　chip. Each chip is capable of 13.6 billion operations per second.
　　---------------------
　・PPC450: Quad 850MHz PPC440 core with "Double Hummer" FP-APU
　・1 petaflops at 294,912-processor
　・up to 884,736-processor
　・optical rack-to-rack interconnect

671 ：MACオタ＠補足 [sage] ：2007/06/26(火) 22:35:03 ID:E+b+TZBO
とりあえず884,736-processorの最大構成で2-PetaFlopsわ超えるす。同じPPC44xベースの
コアが90nmバルクCMOSで2GHzを超えることが可能なことも証明されているすから(>>392参照)、
Blue Geneわ、このままの設計でも数年以内に5-PetaFlopsを超えるロードマップわ現実的す。
0751デフォルトの名無しさん2007/06/27(水) 02:41:21
変なの沸きすぎ
0752・∀・）っ-○◎●2007/06/27(水) 04:23:26
俺Vista x64で8600GTだけどDirectXしかねーべ？
0753デフォルトの名無しさん2007/06/27(水) 05:29:45
Larrabeeってどうやって普及させるつもりなんだろうか。
0754デフォルトの名無しさん2007/06/27(水) 11:13:19
最終的にはCPUと統合らしいから
普通に次世代CPUとしてでしょ。
何となくチップセットに内蔵してきそうな気もする。

っていうか、単体で出さないでしょ？ｗ
科学技術分野に出すかも知れないけど、普及版は統合かと
0755デフォルトの名無しさん2007/06/27(水) 12:35:48
出るのは pcie gen 2 カードでだよ
価格は10万前後
0756デフォルトの名無しさん2007/06/27(水) 15:31:56
つかストリームコンピューティングって市場がそもそもないだろ
せいぜい研究機関とか大学で細々と使われるぐらいで
結局ソフトウェアが無ければ普及しない

リアルタイムレイトレがGPUラスタライザを凌駕するとか真顔で言ってる奴がいるけど
ポリゴンとピクセルが1:1に限りなく近付くようになるならまだしも
法線マップとかのイメージスペース技法の発明でそんなことはこの先起こらない
0757デフォルトの名無しさん2007/06/27(水) 16:43:33
GPUじゃないけど一番敷居が低いのはやっぱりCell?
07585362007/06/27(水) 16:56:17
>>757
思いっきり高い敷居を跨ぐ為に、誰もが俺様ライブラリを作っている状態ですが。
0759デフォルトの名無しさん2007/06/27(水) 17:06:03
>>756
＞つかストリームコンピューティングって市場がそもそもないだろ

あるけど言わない。飯の種だから。
潜在的需要はいくらでもある。

＞リアルタイムレイトレがGPUラスタライザを凌駕するとか真顔で言ってる奴がいるけど
＞ポリゴンとピクセルが1:1に限りなく近付くようになるならまだしも

それ以外にも、レンダリングパスが多くなりすぎるケースや、
ラスタ処理では不可能な処理や、誤魔化していた処理、
そういった高レベルの処理を入れていくと、ラスタライザでは限界がある。
光源が増え、シャドーが幾何級数的に増加したら、従来のラスタライザではどうしようもなくなる。
最終的にはレイトレとラジオシティを組み合わせたものしか生き残れない。
0760デフォルトの名無しさん2007/06/27(水) 18:14:04
>>759
> 潜在的需要はいくらでもある。

そりゃ潜在需要がなけりゃ誰も新規にストリームプロセッサに投資なんてしない
俺が言いたいのはGPUに対する3Dゲームのような決定的な市場があるのかってこと
詐欺まがいのソフト作って無知相手に売ってもせいぜい売り上げは数百～数千万円程度だろ

> 光源が増え、シャドーが幾何級数的に増加したら、
> 従来のラスタライザではどうしようもなくなる。

またまたご冗談を
勘違いしやすいがシャドーマップってのもコヒーレントレイだからな
ピクセル単位でシャドーレイ飛ばすのとシャドーマップ描画して参照するのとを比べれば
圧倒的に後者の方が効率的だし、そもそも光源数とシャドーの増加量に比例して
負荷も比例するのはレイトレも同じ
おまけにレイトレは動的シーンに致命的に弱い

俺はこの先もリアルタイム3DはGPUラスタライザで変態的テクニックを多用していくことに変わりないと考えるね
一次レイと一次シャドーレイだけで息切らしてるようなリアルタイムレイトレは期待できない
0761デフォルトの名無しさん2007/06/27(水) 19:06:27
>>760

>そりゃ潜在需要がなけりゃ誰も新規にストリームプロセッサに投資なんてしない
>俺が言いたいのはGPUに対する3Dゲームのような決定的な市場があるのかってこと

それを教えてほしけりゃ自分で探しな～

>詐欺まがいのソフト作って無知相手に売ってもせいぜい売り上げは数百～数千万円程度だろ

確かに数億～数百億のプロジェクトを仕切っているあなたにはたいした額ではないですね～
でも会社としてはそういう態度で仕事に望まれると困るんですが・・・

つか通常のGPUで盛り上がっているし。
意見は貴重だけどよそでやってくれないかな～？
0762デフォルトの名無しさん2007/06/27(水) 19:12:23
レイトレの話はさすがにスレ違いだけど、
「GPUに対する3Dゲームのような決定的な市場」があるのなら是非知りたいね。
0763デフォルトの名無しさん2007/06/27(水) 19:36:03
言う気無いならがんばるなよ。言わなきゃ論証にならないんだからさ。
0764デフォルトの名無しさん2007/06/27(水) 19:41:30
>763
誰に言ってるの？
07655362007/06/27(水) 20:15:23
少なくとも漏れの周りでは高速に演算したいと言う要求が色々ある。
「面倒だから1Uサーバ機を100台単位で並べろ」ってのから「4core2CPUは高いからなんとかならんか?」まで千差万別。
前者の場合でも、「1U機にGPU入れればラック筐体単位で節約できる可能性がある」となれば興味を示すだろう。
(他社のアクセラレータボードに較べて)安いことは充分刺激になっているよ。
0766デフォルトの名無しさん2007/06/27(水) 21:57:15
スーパーコンピュータTop500、IBMが依然トップ。日本勢はトップ10圏外に
http://www.itmedia.co.jp/news/articles/0706/27/news099.html

プロセッサ別で見ると、Intelプロセッサ搭載システムが57.8％を占めた。
前回の52.5％よりもわずかに増えている。次に多かったのはAMDで21％、
前回の22.6％からは減少した。IBMのPowerプロセッサは17％だった。

また、デュアルコアプロセッサ搭載システムが増えており、
IntelのWoodcrest搭載システムは前回の31台から205台に、
デュアルコアOpteron搭載システムは75台から90台に拡大した。
0767デフォルトの名無しさん2007/06/27(水) 23:16:43
>>760
＞ピクセル単位でシャドーレイ飛ばすのとシャドーマップ描画して参照するのとを比べれば

馬鹿じゃねーのか？シャドーレイなんて飛ばす必要ないぞ。

＞負荷も比例するのはレイトレも同じ

大雑把に、レイトレの負荷はピクセル数に比例する。
光源数やシャドーの数には影響されない。

＞おまけにレイトレは動的シーンに致命的に弱い

そりゃ今はレンダリング速度が遅いだけだ。
1/60秒で描画できるようになったら、逆転する。
0768デフォルトの名無しさん2007/06/27(水) 23:29:10
シャドーｗｗｗｗｗｗｗｗｗ
0769デフォルトの名無しさん2007/06/27(水) 23:34:49
そうなんだよね、折角「ラスタスキャンだとデータ量が増える」からとベクタデータになった処理が、
「解像度が上がるとベクタデータは級数的に増える」からと結局ラスタデータになったりしているしね。
尤も、今や8000x8000なんて画像のフィルタリング処理がオンメモリでできるからこそだけれども。
0770デフォルトの名無しさん2007/06/28(木) 00:11:21
>>767
> シャドーレイなんて飛ばす必要ないぞ。

素人か？1次レイ飛ばすだけでは影は出来ないってのも分からんのか？
誰もラジオシティの話なんてしてねぇぞ

> 大雑把に、レイトレの負荷はピクセル数に比例する。
> 光源数やシャドーの数には影響されない。

レイトレの負荷が解像度に比例するのは当たり前
光源数が増加してもレイトレは計算量が変わらないとでも思っているのか？

確かにラスタライザはレイトレと比較すれば光源1個あたりのコストが高いが
現状最速のコヒーレントレイ技法であるDeferred Shadingを使えば
RTRTが可能なほど高速なハード上では、それ以上に高速に動く（＝より高い複雑度のシーンを扱える）

> 1/60秒で描画できるようになったら、逆転する。

ラスタライザが生成するコーヒレントレイの圧倒的な速度と効率性という前提がある以上
繰り返すがRTRTが可能なほど高速なハード上では、ラスタライザはより高速に動作する
インコヒーレントレイをレイトレで処理して他は通常通り高速にラスタライザで処理するなら分かるが
大方の研究者の云う通りレイトレそれ自体がラスタライザを消し去ることはあり得ない
0771デフォルトの名無しさん2007/06/28(木) 00:13:13
レイトレーシングのスレはここですか？
0772デフォルトの名無しさん2007/06/28(木) 00:41:58
いちおうGPGPUネタではある。
0773デフォルトの名無しさん2007/06/28(木) 05:06:41
ヲタゲーCGはもうお腹一杯。
もっと単純に、天文物理の多体問題を解くみたいな
GRAPEや地球シミュレータとの比較で頼む。
0774デフォルトの名無しさん2007/06/28(木) 07:00:51
Grapeは事実上の敗北宣言が出てたじゃん。
「価格辺り消費電力が大きい」とか微妙な逃げ口上つきで。
0775デフォルトの名無しさん2007/06/28(木) 12:27:32
>>770
＞誰もラジオシティの話なんてしてねぇぞ

俺はしている。ラジオシティ使わずに、レイトレでソフトなライト処理は不可能だ。
0776デフォルトの名無しさん2007/06/28(木) 12:46:31
>>770
＞RTRTが可能なほど高速なハード上では、それ以上に高速に動く（＝より高い複雑度のシーンを扱える）

とは限らない。
例えば、ラスタライザ型では膨大な量の半透明の処理を「完全」に正しく処理するのは非常に困難。
PowerVRのような方法を使えば完全にできるのだが、タイル(チャンク)を細かくしたらレイトレ型と同じだ。
第一、一次レイに限定していないし、それ以上で作られる品質をラスタライザ型で作るのは不可能。

ラスタライザ型で表現できる品質レベルで言えば、そりゃRTRTが可能なハードで上で、
それ以上に高速に動くのはあたりまえ。そんなことは小学生でもわかるわ。
人間が考えうる高品質の画像を作っていく上で、無限の計算力があるなら、
ラスタライズ型の処理なんてあり得ない。
所詮、計算力が十分になるまでの、その場しのぎ、誤魔化しの手法にすぎないんだよ。
RTRTが可能になれば、ラスタライザは死滅する。パレットによるタイリング手法が死滅したようにね。
0777デフォルトの名無しさん2007/06/28(木) 13:48:46
非リアルタイムのアニメ映画でさえもRTはそれほど使われてないんだが・・・
0778デフォルトの名無しさん2007/06/28(木) 14:45:23
とりあえずレイトレしなくてもいいからオフラインレンダラ並の
アンチエイリアスできるようになってから話しろよ
0779デフォルトの名無しさん2007/06/28(木) 15:23:10
>>777
その通り
スキャンラインラスタライザは現在でも多数のオフラインCGで使用されている

まぁ>>776みたいな信者はオノレの信じたいことだけを信じる現実の見えない典型的な馬鹿だから
せいぜい海外の論文でも崇拝しながらRTRTをこのまま妄信し続けてもらいたいね

Larrabeeが出たら是非RTRTを実装してもらいたい
もっとも同時期の最新GPU上で動く最新デモの足元にも及ばんだろうが
品質の面でも解像度の面でもな
0780デフォルトの名無しさん2007/06/28(木) 15:28:11
> 無限の計算力があるなら

この前提も妄想だな

そもそも現在の半導体のドミナントデザインたるCMOSは
20nmプロセス前後で限界を迎えるという事実をお忘れか？
0781デフォルトの名無しさん2007/06/28(木) 16:02:26
>>780
忘れてないよ。でも、技術の発達により、膨大な計算量が扱える方向に進むのだから、
究極的にはどこを目指すかという点で、無限の計算力があるときどうなるかを考えることは無意味ではない。
３０年後のＣＰＵのスペックはどのレベルか考えてみるのもいい。
１００コア程度なら２０１０年前後で投入してくるだろうし。
0782デフォルトの名無しさん2007/06/28(木) 16:07:50
>>779
＞品質の面でも解像度の面でもな

鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングするのでも、
ポリゴンラスタライズ型が勝てるとでも思ってるの？
想定している品質や分野を意図的に制限すれば、そんなことはいくらでもいえる。
0783デフォルトの名無しさん2007/06/28(木) 16:13:04
> 鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングするのでも、
> ポリゴンラスタライズ型が勝てるとでも思ってるの？
> 想定している品質や分野を意図的に制限すれば、そんなことはいくらでもいえる。

「鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングする」ことなんてのはまさに
「想定している品質や分野を意図的に制限す」ることだわな

自己矛盾にすら気付かん馬鹿ですね
相手するだけ時間の無駄か
0784デフォルトの名無しさん2007/06/28(木) 16:24:45
だいだい反射や屈折等のインコヒーレントレイに関しては>>770で
「インコヒーレントレイをレイトレで処理して他は通常通り高速にラスタライザで処理するなら分かる」と言っているだろう

レイトレとラスタライザが「完全に」同調してレンダリングできる時点で
コヒーレントレイをレイトレで処理するなんてのは馬鹿馬鹿しいにも程がある

まさかとは思うが、コヒーレントレイに関してもレイトレがラスタライザより
高速に描画できるとでも思っているのか？
0785デフォルトの名無しさん2007/06/28(木) 16:34:55
>>783
＞「想定している品質や分野を意図的に制限す」ることだわな

だから、それを言っているのだが。
矛盾ではなく、そういう例を出しているのが読めない馬鹿か？それとも意図的に誤読しているのか？
本気で俺が「制限すること」でないと思って書いていると思うなら、お前は読解力がない。
0786デフォルトの名無しさん2007/06/28(木) 16:56:42
>>785
横レスだけどそんな皮相的な反応されても・・・

「意図的に制限すれば何とでもいえる」を批判の言葉として用いているということは、
「より制限の緩い、一般的な用途でRTの方が優秀である」という主張を内包している
としか思えないわけだけど、

「鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングする」という、
これまた意図的に制限された状況を持ち出しているのが矛盾だということ。

という流れなんじゃない？

Ice Age のスタッフがRTサイコーって言ってたよとか、そういう実分野での応用に
ついて検証するしかないんじゃないかな。
0787デフォルトの名無しさん2007/06/28(木) 17:20:19
>>786
＞「より制限の緩い、一般的な用途でRTの方が優秀である」という主張を内包している
＞としか思えないわけだけど、

そうではなく、膨大な計算量が使える環境で、
どのシーンにも使える究極の品質を目指すならＲＴ以外は論外って事。
ポリゴンラスタライズ型は、計算量が乏しい環境で、
上手く誤魔化す程度の品質においてアドバンテージがあるだけだ。

現状の計算機環境、要求品質でポリゴンラスタライズ型を否定しているわけではない。
が、そう遠くない将来、ＧＰＵもポリゴンラスタライズも死滅する。コプロがＣＰＵに取り込まれたように。
0788デフォルトの名無しさん2007/06/28(木) 17:55:12
「膨大な計算量」を何に使うかはデザイナやアーティストが決めるんじゃないかな。
0789デフォルトの名無しさん2007/06/28(木) 18:08:20
>>787
俺の質問に答えろよ
> まさかとは思うが、コヒーレントレイに関してもレイトレがラスタライザより
> 高速に描画できるとでも思っているのか？

一連のお前の発言からすると、コヒーレントレイはレイトレで描画してもラスタライザで描画しても
『数学的に完全に等価である』という大前提をお前は知らない/理解していないようだな

純粋に両者のアルゴリズムの本質(nature)により、コヒーレントレイの描画で
レイトレがラスタライザを速度で上回ることなど
（お前がいくら期待しようが）あり得はしないんだよ
あるとすれば、それは非本質的な部分がボトルネックになっているに過ぎない

ゆえにコヒーレントレイの描画でレイトレがラスタライザを駆逐することなど起こりはしない

お前の「そう遠くない将来、ＧＰＵもポリゴンラスタライズも死滅する」という主張は
全くもって希望的観測に基づいたドグマだ

重要なのはいかに同時期の市場情勢や需要に適合するかであって
シンプルで正確な技術が必ずしもスタンダードとはならないことは歴史が証明している
0790デフォルトの名無しさん2007/06/28(木) 18:40:09
>>789
＞> まさかとは思うが、コヒーレントレイに関してもレイトレがラスタライザより
＞> 高速に描画できるとでも思っているのか？

だから、俺はそんなことは言ってないだろ。
コヒーレントレイに限るなら、想定している品質や分野を意図的に制限しているといっているだけだ。

＞シンプルで正確な技術が必ずしもスタンダードとはならないことは歴史が証明している

シンプルで正確な技術がどっちのことを言っているのか知らんが、
将来のポリゴンラスタライズについても同様のことが言えるな。

ＲＴＲＴのゲームも出てきていることだし、
ＣＰＵパワーの使い道としても俺はＲＴＲＴの今後の発展に期待する。
どっちが残るかなんて歴史が証明すればいいし、今拘る気はない。
ＧＰＵとラスタライズが死滅する方が新しい発展があって面白そうだから、
俺が勝手に思っているだけでいいよ。
0791デフォルトの名無しさん2007/06/28(木) 18:45:20
ttp://www.hc.ic.i.u-tokyo.ac.jp/~kaki/SIGGRAPH2002/Panel_RT_vs_RAS.html
0792デフォルトの名無しさん2007/06/28(木) 19:52:56
GPUとラスタライザが死滅するほうが新しい発展があるって思える根拠に興味が
0793デフォルトの名無しさん2007/06/28(木) 19:56:39
思ってるだけでいいならだらだらと書き下すなと
0794デフォルトの名無しさん2007/06/28(木) 20:22:54
GPUの応用研究で食おうと思ってたらLarrabeeが出て人生オワタような必死さですね
0795デフォルトの名無しさん2007/06/28(木) 20:29:52
別にLarrabeeなり、CPUベースのレイトレなり、新しいものに期待をかけるのはいいと思うが、
なぜ、チャレンジの芽を摘むような批判をぶつけるのだろう。

GPUがなくなるとかラスタライズが死滅するとかは妄想に過ぎんかもしれんが、
そこに新しい技術の種があるかもしれないのに。

本当に死滅するならそれはそれでいいし、死滅しないとしてもそういう別のベクトルが
頑張るのはいいことだと思うぞ。妄想が原動力ならそれでもいいじゃないか。
0796デフォルトの名無しさん2007/06/28(木) 20:31:27
＞なぜ、チャレンジの芽を摘むような批判をぶつけるのだろう。

「Intel にとって良いことは、コンピュータ業界にとって良いことだ」から
0797デフォルトの名無しさん2007/06/28(木) 20:34:42
>>795
2chで吠えてないで結果を出せってことだろ。
0798デフォルトの名無しさん2007/06/28(木) 20:42:01
LarrabeeもTeslaもPCI-Eカードの時点で終わってる
CPUに統合されない限り可能性はない
0799デフォルトの名無しさん2007/06/28(木) 20:56:15
今現在結果を出そうとすることすら叶わないLarrabeeへの皮肉ですか
0800デフォルトの名無しさん2007/06/28(木) 21:10:20
このスレを一通り眺めて思ったこと。
CPUも互換性を考えなければすっげ早くなるのだろうか。
0801デフォルトの名無しさん2007/06/28(木) 21:17:40
>>800
それなんてCell？
0802デフォルトの名無しさん2007/06/28(木) 21:21:15
CPUに統合されても可能性はない
0803デフォルトの名無しさん2007/06/28(木) 21:22:24
誰かが20nmの壁を書いていたけれど、それを忘れてないと書きつつ100コアとか書いちゃうのが信じられない。
そしてまさしくその壁と戦っている人達が、実際にGPGPUにもLarrabeeにも興味を持っているわけなのだが。
0804デフォルトの名無しさん2007/06/28(木) 21:33:56
>>798
メモリ事情を考えろ
http://pc.watch.impress.co.jp/docs/2007/0131/kaigai332.htm
http://media.arstechnica.com/news.media/larrabee-pci.gif
0805デフォルトの名無しさん2007/06/28(木) 21:38:58
つか俺的には何FLOPSとかどうでもいいからメモリのレイテンシを改善しろと言いたい。
お前ら何年間横這いなんだよ、と。
0806デフォルトの名無しさん2007/06/28(木) 21:58:53
>>805
急に言われてもメモリも困る。
ちゃんとプリフェッチされるようなコードを書けば良い。
0807デフォルトの名無しさん2007/06/28(木) 22:07:50
コードについて以外のことについてぐだぐだ書くのはやめろよ。
板違いだ。

自作板にでもスレッド立ててやれば良いだろ。
0808デフォルトの名無しさん2007/06/28(木) 22:14:10
>>807
最近多いよな
こういう多分野にまたがって統合的にものが考えられない奴
0809デフォルトの名無しさん2007/06/28(木) 22:25:33
>>808
どっかのいいかげんなwebサイト仕込みのネタをの適当に口まねするのが
「総合的にものを考える」ことかよｗ　アホくさ。
0810デフォルトの名無しさん2007/06/28(木) 23:49:45
スレのびすぎ
0811デフォルトの名無しさん2007/06/29(金) 00:43:52
で、GPGPUで犬を洗えるようになるのか?
0812デフォルトの名無しさん2007/06/29(金) 00:48:03
>>804
考えた
http://amb.sakura.ne.jp/hanyou/img-box/img20070611224306.jpg
0813デフォルトの名無しさん2007/06/29(金) 01:41:37
>>803
１００コアの話はインテルのロードマップのことだろ。あっちでは数百コアって書いてあったけど。
0814デフォルトの名無しさん2007/06/29(金) 12:21:39
>>812
CSIが細くて笑った。

データの入りと出だけだから問題ないの･･･か？
0815・∀・）っ-○◎●2007/06/30(土) 00:37:10
要するにNUMAでしょ
CPU間のCSIはコヒーレントバス的に使って、たまに他のノードのメモリにアクセスする感じでは。
0816デフォルトの名無しさん2007/06/30(土) 12:03:02
ものすっごい初歩的な質問なのですが

for(int i=0;i<1024*1024;i++){
何か作業
}

の、何か作業をGPUに任せるのって
プログラム側からシェーダに対して
どういうコードを描けばいいのですか？Cgで
0817デフォルトの名無しさん2007/06/30(土) 14:40:47
>>816
つ[cuda]
0818デフォルトの名無しさん2007/06/30(土) 15:05:34
CUDA使えるGPUではないので無理です


ナニを読んだりググれば出てきますか？
0819デフォルトの名無しさん2007/06/30(土) 15:58:30
Cgで普通のグラフィックのプログラム書いた経験はある？
0820デフォルトの名無しさん2007/06/30(土) 16:19:54
今やろうとしているのが、まさにCgで普通のグラフィックプログラムやろうとしてるのですが
どうもわからなくて

はじめにどこ見ればいいですか？
0821デフォルトの名無しさん2007/06/30(土) 16:33:15
>>820
まずは鏡を見て「俺はなんて馬鹿なんだろう」と気付くことから始めよう。
0822デフォルトの名無しさん2007/06/30(土) 16:33:58
そうですね、バカだと思います
0823デフォルトの名無しさん2007/06/30(土) 16:52:22
もう来ません＞＜
0824デフォルトの名無しさん2007/06/30(土) 17:03:34
ぼくもやりたーい

　　　　　　　　　　　　　　　　　┌─┐
　　　　　　　　　　　　　　　　　｜も.｜
　　　　　　　　　　　　　　　　　｜う　|
　　　　　　　　　　　　　　　　　│来│
　　　　　　　　　　　　　　　　　│ね│
　　　　　　　　　　　　　　　　　│え .|
　　　　　　　　　　　　　　　　　│よ .|
　　　　　　ﾊﾞｶ　　　　ｺﾞﾙｧ　　│ !!.│
　　　　　　　　　　　　　　　　　└─┤　　　　ﾌﾟﾝﾌﾟﾝ
　　　　ヽ(`Д´)ﾉ　ヽ(`Д´)ﾉ　　(`Д´)ﾉ　　　 （　`Д）
　　　　|￣￣￣|─|￣￣￣|─|￣￣￣|─□（ ヽ┐U
～ ～　￣◎￣　　.￣◎￣　　￣◎￣　　 ◎－>┘◎
0825デフォルトの名無しさん2007/06/30(土) 21:31:04
GPGPU.ORG
0826デフォルトの名無しさん2007/06/30(土) 23:58:24
普通のグラフィックプログラムでループを1000回も回すことがあるのか
ちょっと興味あるな
0827デフォルトの名無しさん2007/07/01(日) 01:37:45
1000回じゃなくて百万回では？
0828デフォルトの名無しさん2007/07/01(日) 04:45:32
数百万ループって・・・
どんだけ広い空間を定義する気なんだ・・・
0829デフォルトの名無しさん2007/07/01(日) 04:52:17
別に広さの問題ではないと思うけど
0830デフォルトの名無しさん2007/07/01(日) 05:32:31
>>826
単に1024×1024のテクスチャの各ピクセルに対して同じ「何か作業」をしたいだけだろ
0831デフォルトの名無しさん2007/07/01(日) 17:03:08
そんな低レベルというか基本中の基本のことを他人に聞く
ような神経が考えられない。ゆとりか？
0832デフォルトの名無しさん2007/07/01(日) 21:10:16
基本中の基本は
どこを調べたら出てくるんですか＞＜
0833デフォルトの名無しさん2007/07/02(月) 11:02:30
>>832
>825
0834デフォルトの名無しさん2007/07/02(月) 16:33:11
ジャパニーズで教えてください＞＜
0835デフォルトの名無しさん2007/07/02(月) 16:40:38
つ[excite翻訳]
0836デフォルトの名無しさん2007/07/02(月) 17:10:10
英語読めないとかどんな低学歴…
0837デフォルトの名無しさん2007/07/02(月) 19:29:34
NVIDIA最強
http://pc.watch.impress.co.jp/docs/2007/0702/kaigai369.htm
0838デフォルトの名無しさん2007/07/02(月) 19:35:27
>837
お前個人は貧弱だけどな
0839デフォルトの名無しさん2007/07/02(月) 19:44:34
一人一人は小さな火だが
0840デフォルトの名無しさん2007/07/02(月) 19:44:39
なんでわかった？
0841デフォルトの名無しさん2007/07/02(月) 20:31:55
なんだよ、お前らみんな英語読んでやってるってのかよ！
このバカバカマンコ！！！！
お前らなんかチンコの皮をチャックに挟んでしんじゃえ！！！

早く、GPUでのプログラミング教えろよ！
0842デフォルトの名無しさん2007/07/02(月) 21:44:38
英語が嫌ならDirect3Dの日本語ドキュメントとかでHLSLとか勉強して、それをグラフィックス以外の用途に使えばいいやん
0843デフォルトの名無しさん2007/07/02(月) 23:32:53
ゲフォ8600とか買ってCUDAするのがよろしいかと
0844デフォルトの名無しさん2007/07/03(火) 10:33:42
8600GTSなら3万弱、8600GTなら1万円台中頃かな。
最早CUDA以外を勧める理由がないよ。
0845デフォルトの名無しさん2007/07/03(火) 12:59:22
CUDAで使えるjava処理系だせや>えぬびでぃあ
0846デフォルトの名無しさん2007/07/03(火) 14:19:49
>>844
x64やVistaに対応していないし、しそうにもない現状を考慮してもか？
流石に痛すぎるだろ・・・。
0847デフォルトの名無しさん2007/07/03(火) 14:35:40
>>846
需要があれば出すでしょ。現状、TeslaはLinuxをメインにしているようだからね。
#Linuxならx64もあるわけで。
0848デフォルトの名無しさん2007/07/03(火) 21:52:20
>>837
AMD K10最強
http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_13223,00.html?redir=CPBM01
0849デフォルトの名無しさん2007/07/04(水) 18:30:35
8600GTでCUDAって動くの？
0850デフォルトの名無しさん2007/07/04(水) 20:43:31
8800からじゃなかった？
0851デフォルトの名無しさん2007/07/04(水) 21:24:32
>>816
1024*1024のテクスチャをサイズが変わらないように描画しろ。
演算の中身がシェーダ。

GPGPUのHellowWorldってまさにこれだと思うんだけどどうよ。
0852デフォルトの名無しさん2007/07/05(木) 00:11:03
>>851
GPGPUなんだから、画像から離れてもいいんじゃない?

>>849>>850
CUDA1.0のAppendixにはこれだけ書かれている。
GeForce
8800Ultra
8800GTX
8800GTS
8600GTS
8600GT
8500GT

Quadro FX
5600
4600

Tesla
C870
D870
S870
GeForce 8シリーズとあるから、8400GSでもいけるんじゃなかろか。
08538522007/07/05(木) 00:16:02
ちなみに、8600GTSでhttp://pc11.2ch.net/test/read.cgi/tech/1167989627/47とおなじことやってみたら、
概ね1/3～1/2の速度が出た。メモ取るの忘れちゃっから細かい数字は不明だけど。
0854デフォルトの名無しさん2007/07/05(木) 01:50:35
>>852
816氏はCUDA使えなくてCgでやりたいって言ってるんだから、
テクスチャの概念を持ち出さないわけにもいかないだろうに。
08558522007/07/05(木) 05:45:12
>>854
あ、確かに。これは失礼。
0856デフォルトの名無しさん2007/07/05(木) 20:38:07
ビンゴ
http://jndb.pc.mycom.co.jp/articles/2005/09/06/siggraph2/002.html

要は、ループをまわすかわりにテクスチャ上にあるピクセル(テクセル)の
RGBで計算するってこと。ループ1回がピクセル1つに相当する。

とっても簡単に言えば、0x0000FFへ0x00FF00を足して0x00FFFFにする計算が、
青ピクセルへ緑ピクセルを加算合成してシアンのピクセルにすることで代用できる
って感じ?
0857デフォルトの名無しさん2007/07/05(木) 21:14:36
なんかすごいのが来た・・・
0858デフォルトの名無しさん2007/07/05(木) 21:48:06
>>856-857
ﾌﾟｯ
0859・∀・）っ-○◎●2007/07/06(金) 00:19:16
俺Vista x64なんだけどManaged DirectXが一番楽？
0860デフォルトの名無しさん2007/07/06(金) 00:22:17
// cudaに慣れるために作ったサンプル。改めて見たらC++とCが混ざった書き方になってる……orz
// 色とか座標だとか意識せずに書けるのがいいやね。
#include <stdio.h>
#include <math.h>
#include <cutil.h>
// ↓これで軽く1MiB
const int TableWidth = 512;
const int TableHeight = 512;

__global__ void setTable(float * table)
{
table[threadIdx.x + blockIdx.x * TableWidth]
= blockIdx.x / (float) TableHeight + sinf(2 * M_PI * (threadIdx.x / (float) (TableWidth - 1)));
}
int main()
{
float * cudaTable;
cudaMalloc((void **) & cudaTable, sizeof(float) * TableWidth * TableHeight);
setTable<<<TableHeight, TableWidth>>>(cudaTable); // ループの代わりに分散処理
// このままGPUで計算するだけなら↓の転送は不要
float values[TableWidth * TableHeight];
cudaMemcpy(values, cudaTable, sizeof(float) * TableWidth * TableHeight, cudaMemcpyDeviceToHost);
cudaFree(cudaTable);
for (int ih = 0; ih < TableHeight; ++ih) {
for (int ic = 0; ic < TableWidth; ++ic) {
printf("%g ", values[ic + ih * TableWidth]);
}
printf("\n");
}
return 0;
}
0861デフォルトの名無しさん2007/07/06(金) 00:22:30
なんかすごいのが来た・・・
0862デフォルトの名無しさん2007/07/06(金) 00:25:15
>>860-861
ﾌﾟﾌﾟｯ
0863・∀・）っ-○◎●2007/07/06(金) 00:25:37
Vista x64用管まだー？


XP 32bitを後から入れるのもなぁ
＃Vistaのブートセクタ壊れるし。
0864デフォルトの名無しさん2007/07/06(金) 01:12:24
KNOPPIXでも使ってddしろ
0865・∀・）っ-○◎●2007/07/06(金) 01:15:06
どっちかというとソフト作ってバンPに配布したい。
DirectX10ならVistaに最初から入ってるじゃん

→決定


だんごやさんのソフト（って言ったらまあアレくらいだ）に組み込むと言っておこう
0866デフォルトの名無しさん2007/07/06(金) 01:53:28
Vista and XP x64ユーザーな俺は無関係。



CUDAやる為に、地雷と言われてたGF8600GTS買ったのになああああ
88買う財力は無かった。
0867・∀・）っ-○◎●2007/07/06(金) 02:10:36
まあでも、いちおうCgやHLSLは使えるみたいだし
0868デフォルトの名無しさん2007/07/06(金) 16:07:53
俺はG92が出るまでCUDAは他の人間に露払いさせて
バージョンアップを待つね
0869デフォルトの名無しさん2007/07/11(水) 08:19:36
それはいつになるの
0870デフォルトの名無しさん2007/07/12(木) 04:19:46
その頃にはG100が発表される…
0871デフォルトの名無しさん2007/07/12(木) 22:37:07
来年４月
http://pc.watch.impress.co.jp/docs/article/980402/mgag100.htm
0872デフォルトの名無しさん2007/07/12(木) 22:53:35
おいおい、10年前スレかよw
0873未来人2007/07/20(金) 12:36:32
俺なんてG400持ってるもんね！
0874デフォルトの名無しさん2007/07/20(金) 12:42:10
laguna3d持ってる俺が通りますよ
0875デフォルトの名無しさん2007/07/20(金) 18:53:16
俺なんかすでに9801だぜ
0876デフォルトの名無しさん2007/07/20(金) 23:01:46
何このすれ
0877デフォルトの名無しさん2007/07/21(土) 03:41:21
CUDAやるのに
マルチスレッドプログラミングの知識は必須ですか?
0878デフォルトの名無しさん2007/07/21(土) 03:47:07
は？
0879デフォルトの名無しさん2007/07/21(土) 04:26:48
いや、だってGPUってメニイコアでしょ。
行列計算とかを速くできるようになるんでしょ。
それってマルチスレッドプログラミングともろかぶりじゃないんですか?
CUDAのAPIっーか、ライブラリ関数見た事無いから
想像ですが。
0880デフォルトの名無しさん2007/07/21(土) 04:29:05
Voodoo2買ってきたお（ ^ω^）
0881デフォルトの名無しさん2007/07/21(土) 15:25:57
>>879
CUDAのSDKは誰でもダウンロードすることができるので、興味が
あるのであれば、少しは自分で調べてみましょう。
あとはGPGPUに関しては、インプレスの後藤さんの記事もとても
参考になります。
0882デフォルトの名無しさん2007/07/21(土) 16:10:27
>GPGPUに関しては、インプレスの後藤さんの記事もとても参考になります。

（笑）
0883デフォルトの名無しさん2007/07/21(土) 18:06:12
>>GPGPUに関しては、インプレスの後藤さんの記事もとても参考になります。
(涙目)
0884デフォルトの名無しさん2007/07/22(日) 05:49:08
後藤記事は、2chにおいては失笑扱いらしいから気をつけてな。

ふつうに知識あれば彼の記事の読むべきところ流すべきところが
わかって、参考になるんだけどな。
0885デフォルトの名無しさん2007/07/22(日) 10:38:55
まぁ、GPGPUをいい始めたとき
多くの人は信じてはいなかったわけだが
0886デフォルトの名無しさん2007/07/22(日) 14:20:02
マルチスレッドプログラミングの知識はあるに越したことはないが、必要とまではいかない。
データバラレルくらいわかればとりあえずは十分でしょう。
0887デフォルトの名無しさん2007/07/22(日) 15:39:31
【派遣ネガティブ根性チェック】

3つ以上、チェックがつけばアナタの性格はひん曲がっており、
ネガティブ負け組派遣人生を歩んでいます。

□派遣先正社員の作った糞開発ツールはたとえ腐っててもマンセーして使う
□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□仕様とは正社員から口伝されるものだ
□耳で聞いた仕様を正確に覚えていないのは自分の責任だ
□昼食は必ず派遣先の社員と行くべきだ
□自分の仕事で問題が発生しても解決するのは派遣の仕事ではない
□派遣先から「いつまでもここで仕事してくださいね(安い金でｗ)」と言われて嬉しい
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにして反論する
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなくプライベートについてもグイグイ引っ張って欲しい
□奢ってくれる派遣先正社員を尊敬する
□自分の月額金額を知らないのは当然だ、単金を聞いてはいけない
□派遣先正社員より自分の生涯収入が低いのは当然だ
□チビは派遣先にかわいがってもらいやすから派遣には有利だ
0888デフォルトの名無しさん2007/07/22(日) 18:21:29
×データバラレル
○データパラレル

ちなみにgotoちゃんは
ろくなCS学位も持ってないただのなんちゃって屋さんだよ
0889デフォルトの名無しさん2007/07/22(日) 19:32:38
記者や評論家が本職で無いのは当然といえば当然
0890デフォルトの名無しさん2007/07/23(月) 02:26:59
安藤や大原の勝ち
0891・∀・）っ-○◎●2007/07/23(月) 03:14:02
安藤氏って学術関係の検索かけてみるといろいろ引っかかるけど同姓同名？


http://www.psi-project.jp/member/index.html

　サブサブテーマ３－①
氏名 ： 安藤壽茂
所属 ： 国立大学法人九州大学 情報基盤研究開発センター 客員教授
　　　　 富士通株式会社　サーバシステム事業本部　技師長
0892デフォルトの名無しさん2007/07/23(月) 10:07:08
>>889　　　　　　　　　 当然なんてのは文系のイイワケだよ。
ただ、文章を書けない理系が多いのも事実だから、仕方ない面はある。
0893MACオタ＞団子 さん2007/07/23(月) 19:38:07
>>891
本物のハイエンドプロセッサのアーキテクトなんすけど、知らずに後藤氏なんかと
比較してたすか？
http://mdfs.net/Docs/Comp/CPU/Archit.htm
　　------------------------
　　HaL SPARC64, 1995 - Hisashige Ando (design manager), Winfried Wilcke, and Mike Shebanow
　　------------------------
0894・∀・）っ-○◎○2007/07/23(月) 22:30:31
MYCOMの安藤とか書いてあるページもあるし同姓同名の別人でもいるのかと思っただけ。
とはいえ凡人にはあそこまで技術論は語れないわな。
氏の連載はそこらの院生が使ってるアカい薄い高い本よりよっぽど分かりやすい。
0895デフォルトの名無しさん2007/07/23(月) 23:28:48
>>888
なにが間違ってるのかわからなかったけど、やっとわかった。
パラレルね。携帯だから視認性が劣悪で、濁点と半濁点の区別がつかないんだよね。
しかもT9変換使っているからご変換されてるとほんとわからない。
0896デフォルトの名無しさん2007/07/25(水) 15:12:35
マルチスレッドの知識というより、並列プログラミングとか並列アーキテクチャの知識かなぁ。

CUDAはthreadとかwarpとかblockとかgridとかmultiprocessorとか
普段並列プログラミングで使っていない（違う意味で使っている）怪しい単語が並んでてうまく頭の中で整理できない私。
死んだほうがいいな。
0897デフォルトの名無しさん2007/07/25(水) 18:14:15
>>896
つ抗うつ剤
0898デフォルトの名無しさん2007/07/28(土) 00:52:01
Cgのサンプルで
パーティクル以降のOpenGLBasicのプロジェクトファイルが無いのって
仕様ですか？

パーティクルのところを見たいのに…メインのソースが無いとわかんねぇ
0899デフォルトの名無しさん2007/08/01(水) 21:23:41
ぁげ
0900デフォルトの名無しさん2007/08/02(木) 02:23:26
ageるなsageろ
0901デフォルトの名無しさん2007/08/03(金) 16:35:40
GPGPUって、ある文字列をソートするとか言う用途に使えそうなんですが
行列を使った効果的なソートのサンプルとかありませんか？

あと、BrookGPUに手を出そうと思ってるのですが、どこ探してもベンチマーク結果のようなものが見当たりませんが
どこかに無いでしょうか？
0902デフォルトの名無しさん2007/08/03(金) 17:47:22
なんで文字列のソートなんかに使えると思ったのか。
一番向いてない分野だと思うが。
0903デフォルトの名無しさん2007/08/03(金) 18:04:50
そうでもないよ。
GPGPUを使ったBWTは、割と発表されてる。

CPUだと、quickだが、GPUだとバケットソートを再帰的にやるのが賢いだろうな。
0904デフォルトの名無しさん2007/08/03(金) 23:30:18
>>903
割と向いた処理ってのは同意だが
GPUで再帰は無理
0905デフォルトの名無しさん2007/08/04(土) 08:04:49
有るよ。
並列ソートって研究分野で、教科書も出てる。

GPUじゃないけど、SIMD並列スパコンを使って
並列ソートで速度を競う、ってのが去年くらい
に東工大のプログラミングコンテストの課題
だった。
0906デフォルトの名無しさん2007/08/04(土) 10:23:19
>>905
教科書ともし公開されてたらプログラミングコンテストのソースがあるところを教えてほしい。
0907デフォルトの名無しさん2007/08/04(土) 10:34:59
NVIDIAならCUDAのサンプルにbitonicソートのサンプルがついてるね。
0908デフォルトの名無しさん2007/08/04(土) 16:32:46
"文字列"のソートにGPGPUが向いているの？
0909デフォルトの名無しさん2007/08/04(土) 16:54:00
文字列だって、結局数字に落とせるでしょ。
しかも、文字の配列として扱えるので、行列処理に強いGPUには格好の演算対象
もう少し動向を勉強してきなさい。
0910デフォルトの名無しさん2007/08/04(土) 16:57:30
せっかくの浮動小数点演算パワーを整数配列のソートという
しょうもない用途に浪費させることのナンセンスさを言っているんだろうｗ
0911デフォルトの名無しさん2007/08/04(土) 17:03:23
GPGPUの現状の利点って、専攻したメニィコアによる並列処理でしょ。
もはや、浮動小数点演算能力は、GPUの専売特許ではなくなってる事に気づくべき。
グラフィック処理用プロセッサだからって、騙されちゃいけないよ。
0912デフォルトの名無しさん2007/08/04(土) 17:04:58
少なくともピクセルシェーダーが扱うbitonicソートは、整数演算だな。
あれもGPUに特化した処理だし。何をいまさら・・・
0913デフォルトの名無しさん2007/08/04(土) 18:40:23
>>911
後藤の受け売り乙ｗ
2chだからアレだけどリアルではそういう事言わないほうがいいぞ

まぁとりあえずGPU+CUDAとCPUで整数配列ソートのベンチマークでも
取ってみることをオススメするよ
0914デフォルトの名無しさん2007/08/04(土) 19:02:39
普通に、どっかの論文でCPU(Pen4 2.8G)に対してGPU(Geforce6600)で48倍のソート結果出てたでしょ。
ついでに、バイオインフォマティクスのDNAマッチング(要するに文字列マッチング)では68倍
十分CPUに対してのアドバンテージだし、利用がナンセンスとかあふぉだろ。

実際俺がBrookGPUで作ったBWTのソートでも、CPUに対してちゃんとアドバンテージあったよ。
俺じゃなくても、ググったらいくらでも結果出てくるだろ。
0915デフォルトの名無しさん2007/08/04(土) 19:09:54
ftp://ftp.research.microsoft.com/pub/tr/TR-2005-183.pdf

ほい、GPUソートのちゃんとした論文
終了。

とどのつまり、ソートそのものが遅いとか浮動小数点使わないと意味が無いとか言う話に論点をずらしてるが
結局のところ、文字列ソートを数字ソートの問題に落とせないと勘違いした
プログラマにあるまじき馬鹿が居たって話だろ。

そこに問題が落とせないなら、そもそもCPUでの文字列ソートすら出来ない罠

結論言うと、別に浮動小数点じゃなくても、GPUのメリットはある。
CPUに負ける例があるなら、むしろ示せ。
0916デフォルトの名無しさん2007/08/04(土) 20:04:42
先日、CUDAに移植した(ってのも変な言い方だけど)プログラムは、
CPU版より速くするのに結構手間が掛かったよ。
メモリアクセスがgdgdなロジックだと、意外にCUDAは苦手なようだ。

そうそう、CPU版で使ってた三角関数のテーブル参照は、CUDAでは自前で演算した方が速かった。
超越関数ニモニックを持たないどこぞのDQNCPUのサブプロセッサよりも、その点ではずっと重宝だよ。
まぁ、どう足掻いてもLocalなメモリが250KBしかないから最初に書いたような
問題が発生しないと言う点ではそのDQNCPUのほうがマシと言えなくもないけどw
0917デフォルトの名無しさん2007/08/04(土) 20:05:52
おいおいギガバイト級データのソートの話なんて明らかにしてないだろ
20-100GBの文字列とかどんだけ～ｗｗｗ

せいぜい数MBの文字列をソートするためだけにわざわざGPU走らせるとか
演算そのものよりもカーネルのinvokeやread/writeのオーバーヘッド比がデカ過ぎ

俺はちょっと馬鹿らしくてやってられないなぁ
だから言うようにGPU+CUDAとCPUでベンチしてみて欲しいんだよねｗ
0918デフォルトの名無しさん2007/08/04(土) 20:11:59
>>917
おちつけ
話が支離滅裂

特に
>おいおいギガバイト級データのソートの話なんて明らかにしてないだろ
>20-100GBの文字列とかどんだけ～ｗｗｗ
ここ何が言いたいかわからん。
0919デフォルトの名無しさん2007/08/04(土) 20:20:09
GPGPUでの文字列ソートの時点で、多分やりたい分野はわかっちゃったけど・・・
(最近あちこちで論文出てるアレだよね？バイオインフォマティクスとか名前が出てきた時点で・・・ｗ)
確かに、上手くやれば良いんだけど、多分ここの人たちの考えてる文字列ソートって、せいぜい数M単位だと思うよ。
グラフィック肌の人が多いここで聞いても無駄
普通に論文読みなよ。
0920デフォルトの名無しさん2007/08/04(土) 20:52:13
>>918
まぁなんだ、論文嫁

グラフ見るだけでもいいけど
0921デフォルトの名無しさん2007/08/04(土) 20:52:57
ところで、ちょっと前のビデオカードで試したときは、入力データを
そのまま出力するだけで、内部精度の影響か最下位ビットが微妙に
変化してしまうことがあったけど、8800あたりだと問題ないの？
0922デフォルトの名無しさん2007/08/04(土) 21:04:51
>>921
キャストが原因じゃねぇの？
16bitの入れ物に32bitのデータを入れて、演算して
再び32bitのデータに戻したら、最下位ビットが変化する。


>>609
この辺りか
0923デフォルトの名無しさん2007/08/04(土) 21:18:58
>>921
floatは精度が24bitしかない。それはどんなGPUでも一緒。
CUDAなら整数型もあるから、8800に限らず8600,8500でも大丈夫だけどね。
0924デフォルトの名無しさん2007/08/04(土) 21:29:06
不定領域が出来るって話だよね？
予め、受け皿をゼロで埋めておけば良いんじゃね？
0925デフォルトの名無しさん2007/08/04(土) 22:26:09
あれ？NVIDIAは16bitと32bitじゃなかったっけ？
ATIは9800あたりは24bitだったけど、X10000から32bitじゃないの？
0926・∀・）っ-○◎●2007/08/04(土) 22:54:42
そもそも仮数精度のこと言ってるのか浮動小数フォーマット全体での精度のこと言ってるのか。
仮数精度24ビットと32ビットは同じ。
0927デフォルトの名無しさん2007/08/04(土) 23:33:57
どっちにしろ「どんなGPUでも同じ」ではないと思うけどね。
最低保証は9bitだったっけ？
0928デフォルトの名無しさん2007/08/04(土) 23:39:20
>>923
0929デフォルトの名無しさん2007/08/04(土) 23:40:21
ちなみにIEEEならmantissa 23 bits、exponent 8bits、sign 1 bit
0930・∀・）っ-○◎●2007/08/04(土) 23:50:33
たしかに仮数部23bitだけど、内部表現上の最上位は暗黙に1として省いてるだけだから、
実際にはエクセル64の24ビットに精度が劣るということはない。
09319062007/08/05(日) 10:48:28
おれのようなヘッポココード書きには論文はちと荷が重いよ。

http://www.amazon.com/s/ref=nb_ss_gw/105-1354175-8781247?initialSearch=1&url=search-alias%3Daps&field-keywords=bitonic+sort&Go.x=5&Go.y=11

並列ソートを理解するには、どの本がわかりやすいの？
0932デフォルトの名無しさん2007/08/05(日) 11:26:28
ダンゴさんがピシっと〆めてくれたな。
0933デフォルトの名無しさん2007/08/05(日) 12:14:25
さすが団子さん！かっくいい！！ー
0934デフォルトの名無しさん2007/08/14(火) 22:20:37
この前知り合いからGPGPUって名前を聞いて
今作ってるプログラムの高速化に使えないかと考えたんだが、
GPGPUは

「複雑な形状のブーリアン積の体積を近似的に求める」

って処理に使えそう？
使えそうなら今から勉強してくるぜ！
0935デフォルトの名無しさん2007/08/14(火) 23:32:20
>>935
並列演算できる部分があれば充分使える。
CUDAなら実装も簡単。
0936デフォルトの名無しさん2007/08/14(火) 23:58:41
>>935
ﾄﾝｸｽ
0937デフォルトの名無しさん2007/08/15(水) 00:06:13
　　┌───────────────────────────────┐
　　│935 名前：デフォルトの名無しさん[sage] 投稿日：2007/08/14(火) .23:32:20 │
　　│>>935　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
　　│並列演算できる部分があれば充分使える。 　　　　　　　　　　　　　　　　　　 │
　　│CUDAなら実装も簡単。 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
　　└───────────────────────────────┘
　│>>935　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
　│並列演算できる部分があれば充分使える。 　　　　　　　　　　　　　　　　　　 │
　│CUDAなら実装も簡単。 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
　└───────────────────────────────┘
│>>935　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
│並列演算できる部分があれば充分使える。 　　　　　　　　　　　　　　　　　　 │
│CUDAなら実装も簡単。 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
└───────────────────────────────┘
0938デフォルトの名無しさん2007/08/15(水) 04:56:04
荒らしうぜぇ
0939デフォルトの名無しさん2007/08/15(水) 19:47:47
CUDAなら実装も簡単とは言うがな、兄者

資料がなさ過ぎるんだよ、兄者
0940デフォルトの名無しさん2007/08/15(水) 19:59:07
とはいえ、BrookGPUのような既存のGPGPU専用言語では、
速度が出ないし、速度が出る実装も出来ないからなぁ。


この前BrookGPUで、CPUより40パーセントも遅い処理書いちゃって憤慨した。
鼻から色々出た。
0941デフォルトの名無しさん2007/08/15(水) 20:04:14
>>939
NVIDIAのドキュメントでは不足かい?
まぁ、書いてみろ｡いいもんだ。
#つーか、fftwやblas使いなら苦にもならんだろ｡
0942デフォルトの名無しさん2007/08/18(土) 11:14:07
>>748
> S3（VIA）その他の弱小グラフィックスが再び脚光を浴びる。

いよいよSiS/Mirageの出番がやってまいりますた！
http://arena.nikkeibp.co.jp/winpc/col/02/web_road_intel.pdf
0943デフォルトの名無しさん2007/08/18(土) 18:33:23
P4M900でChrome9がAGP接続な事に本気でビックリした
0944デフォルトの名無しさん2007/08/19(日) 14:40:52
CUDAって再帰出来ないの?
moe(){←GPU側の処理
}
hoge(){←CPU側の処理
foo();
bar();
moe();
for(;;)
hoge();
}
みたいな事って無理なの?
0945デフォルトの名無しさん2007/08/19(日) 15:08:40
CPU側はできるでしょ。ドキュメントを読めば、デバイス側はできないと書いてあったと思うけど。
0946デフォルトの名無しさん2007/08/19(日) 16:02:03
そうそう、>944のようなコードだと、moeの呼び出し部分を並列化することになると思う。
つまり宣言は
__global__ void moe(...);
であり、呼び出し部は
moe<<<blocks, threads>>>(...);
になるんじゃないかな。
再帰段数にも拠るけど、巧く考慮しておかないとパフォーマンスは出にくいと思われ。
0947デフォルトの名無しさん2007/08/20(月) 19:21:46
ttp://www.gpgpu.org/s2007/
SIGGRAPH 2007 GPGPU COURSE
0948デフォルトの名無しさん2007/08/21(火) 21:17:15
GPGPUってどういう処理に向いているの?
一つの処理をforkしてさばく場合?
それともやたら早く数値演算が出来るの?
0949デフォルトの名無しさん2007/08/21(火) 22:03:23
やたらとは速くないな。少なくともWoodcrestには負けると思う。
強いのは並列処理。例えば行列演算とか画像処理にはかなりの威力を発揮する。
意外なところでは、超越関数だけで言えばXeonを遥かに凌ぐ速度も出る。
0950デフォルトの名無しさん2007/08/22(水) 09:55:31
簡単に言えば、CPUより出来の悪いプロセッサが、大量にくっついてるから
数で勝負できる。ってだけ。

並列化出来なければ、何のメリットも無い罠
0951デフォルトの名無しさん2007/08/22(水) 12:02:54
文字列操作は出来ないんですか?
#include <stdio.h>
int main (int argc, const char * argv[]) {
char string[] ="Hello,World";
char stringat[13];
copy (string,stringat);
printf("%s¥n",stringat);
return 0;
}
__global__ void
copy (char *buff,char *buffat){
int i = 0;
while(buff[i]){
buffat[i] = buff[i];
i++;
}
buffat[i] = '¥0';
}
良く分からないですけれど、こんな感じで。
0952デフォルトの名無しさん2007/08/23(木) 01:06:13
>>951
・GPU側関数はGPU側メモリしか扱えない。
・並列化しなければパフォーマンスは出ない。

結論:単なる文字列のコピーには使えない。但し、文字列操作ができないと言うことではない。
0953・∀・）っ-○◎●2007/08/23(木) 01:55:37
ちきしょーCUDA使いたかったのでXP 32bit追加
0954デフォルトの名無しさん2007/08/23(木) 02:03:12
Linuxは64bit出てるけどWinはないんだっけ?
0955デフォルトの名無しさん2007/08/23(木) 02:53:32
やっぱCUDA使う研究者とかはLinux使う人が多いのかな。
VMが進化してきたのでいいけど。
0956デフォルトの名無しさん2007/08/23(木) 07:38:50
nvcc(CUDAのコンパイラ)とgcc(iccでも可)があれば開発できるからねぇ。
Windows版はVS2005との連携になるからちと面倒。
# 尤も、どうせコマンドライン版を使うんだけど。
0957デフォルトの名無しさん2007/08/23(木) 08:44:11
>>952
ありがとうです。
GPU側からは、CPU側のメモリは弄くれないと。
つまり、参照渡しが使えない訳か。
GPU側の演算結果を得るためには、
cudaMemcpyという専用の関数を使わないと
駄目な訳ですね。
自分はMacしかもってないんですけれど、
実験でLinuxマシンかおうかなぁ。
CUDAには夢を感じるので。
0958デフォルトの名無しさん2007/08/23(木) 10:18:03
・∀・）っ-○◎●
0959デフォルトの名無しさん2007/08/23(木) 22:42:23
G80 じゃなくて CUDA に夢？
Larrabee とかにも自然に使えるとかそういう願望？
0960デフォルトの名無しさん2007/08/24(金) 01:11:20
なぜダンゴがこのスレにいるんだ？
0961・∀・）っ-○◎●2007/08/24(金) 06:23:26
最初から居る
0962デフォルトの名無しさん2007/08/24(金) 07:11:05
G80じゃなくてCUDAに自分は夢を感じますねぇ。
自分GPUの仕組みについては全くさっぱりなので。
ところでGPUをグリッド?単位で扱うみたいな事が書いてあるんだけれど、
っーことはGPUをいくつかに切り分けて、
fork-execしたプロセスに別々に渡したりできるのかしら?
0963デフォルトの名無しさん2007/08/24(金) 07:41:43
>>962
その仕組みがCUDAでいう並列化の肝だ。
例えばこんなループを
for (int i = 0; i < N; ++i) {
func(array, i);
}
こんな風に書くわけだ。
func<<<1, N>>>(array);
0964デフォルトの名無しさん2007/08/24(金) 09:21:06
いや呼ぶ側が別プロセスで使えるか，って話だろ
0965デフォルトの名無しさん2007/08/24(金) 10:59:41
あー、そういう話か。
別プロセスから単純に使おうとしたら待たされたっぽいけど
分割数を制御すれば共存できるかな?
確かに巧く使えば便利そうだ。ちょっと調べてみよう。
0966デフォルトの名無しさん2007/08/24(金) 11:10:14
>>963,964,965
すいません。
そういう話です。
GPUを論理分割?して別々の処理をしているプロセスに割り当てられたら
夢が広がるかなぁと思って。
0967デフォルトの名無しさん2007/08/24(金) 14:24:47
TILE64ってどうよ？
PCIeカードが出るみたいだけどx4レーンに刺すタイプみたいな。

わざわざマザー買い換えたくないし、さてどうしたものか。
0968デフォルトの名無しさん2007/08/24(金) 14:55:05
しかも2スロット占有型でしょ。
コンパイラがどんなもんかも判らんし。
0969・∀・）っ-○◎●2007/08/24(金) 19:54:54
マザー側のx1レーンを削（ｒｙ

安く済ませるにはPowerEdge SC430のx8とx4
あとはx1に刺さるビデオカードを用意して・・・

嫌だこの構成・・・
0970デフォルトの名無しさん2007/08/28(火) 01:11:47
これって
大量のスレッドをぶん回す用途には使えないの?
0971・∀・）っ-○◎●2007/08/28(火) 01:19:36
そもそもスレッドってなに？みたいな。
GPUって基本的にピクセル数分並列化できるから、複数タスクを平行に動かすような用途には進化しなかった。
0972デフォルトの名無しさん2007/08/28(火) 14:30:20
SIMDだからなぁ。MIなプログラム/アルゴリズム
には向かないと桃割れ。
ちと三宮へゲフォなグラボ見に逝って来る。
0973デフォルトの名無しさん2007/08/28(火) 23:59:28
普通に疑問なんだけれど、
例えばGPUにメモリが640MB搭載されてるとき、
32bitOSが使用出来るメモリ領域って
4GB-640MB分?
それとも、4GB全部?
簡単に言うと、
大容量メモリを乗っけたグラボがあった場合、
OSのメモリマップてどうなるの?
0974デフォルトの名無しさん2007/08/29(水) 00:04:32
VistaだったらVRAMに載せられるメモリから溢れたら
メインメモリも侵食してくってことだから
単純にVRAM容量のデカいカードが有利ってこと。
DXのメモリサーフェスのようなものと思えば。
XPだと顕著な差は出ない。

もちろんVRAMの多いカードツンだからといって
アプリが使えるメモリが増えることはない。
0975デフォルトの名無しさん2007/08/29(水) 00:51:54
>>974
うぐぐ、いまいち分からんデス
GE80っていわゆるI/OマップドI/Oなんでしょうか?
それともメモリマップドI/Oなんでしょうか?
0976デフォルトの名無しさん2007/08/29(水) 02:26:15
>>975
質問の真意を取り違えてしまった。
メモリマップトだろうがアパーチャだろうが
疑問の通り4GBの領域を侵食するが
昨今のOSはPAE機構などによりRAM総容量4GBの壁はない。
プロセスがリニアにアクセスできる空間が4GBなのは相変わらずだが
このへんの話は話し出すとキリがなくスレ違い。

次スレ要るのか?
0977デフォルトの名無しさん2007/08/29(水) 14:12:27
CUDAだとメインメモリもVRAMもヒープ領域として扱えますか？
0978デフォルトの名無しさん2007/08/29(水) 14:29:49
なにか勘違いしてるきがす
0979デフォルトの名無しさん2007/08/29(水) 15:17:51
ですか…やっぱ買って試さないとだめっすね
0980デフォルトの名無しさん2007/08/29(水) 15:34:57
妄想しすぎ
0981デフォルトの名無しさん2007/08/29(水) 16:36:06
そりゃ、トランジスタ数が6億8,100万もあれば妄想もしたくなるわ。
Power4の1億7400万でも、出たとき「スゲー、コレ」って思ったのに。
0982デフォルトの名無しさん2007/08/29(水) 17:11:46
次スレ建てますた。「GPUで汎用コンピューティングを行うスレ」は
話題がスレ違いの方向に向かって過疎ってるし、こっちに統合しま
しょう。その他、テンプレとかフォローよろしこ。

GPGPU#2
http://pc11.2ch.net/test/read.cgi/tech/1188374938/l50
0983デフォルトの名無しさん2007/08/29(水) 19:26:09
>>981
そうかなぁ・・・
ブロック図みたり、シェーダちょっとでもいじりゃ
どんなもんか予想できるだろ
0984デフォルトの名無しさん2007/08/29(水) 23:24:36
単に調べもせず妄想してる/夢抱いてるってことじゃね？
0985デフォルトの名無しさん2007/08/30(木) 00:09:19
取り敢えずCUDAのドキュメントに目を通せば判ることだし。
0986デフォルトの名無しさん2007/08/30(木) 03:24:18
でも、現状の仕様のままだったらかなり色物だよなぁ。
Teslaって売れてんのか?
なんつーか、「こんな処理には向いていないと思われてたけれど、
実際にコード書いてみたら、意外と処理が爆速でした」
って言うものを見つけないと、いつまでたってもGPGPUってはやらん気がする。
0987デフォルトの名無しさん2007/08/30(木) 04:51:36
Larrabeeはあと3年後
CUDAはさっぱり
Fusion？なにそれ？
GPGPUｵﾜﾀ
0988デフォルトの名無しさん2007/08/30(木) 20:17:22
GPGPUを研究してる人って日本国内に何人くらい居るんだろう?
3000人くらいかなぁ?
っーか、この分野は何に分類されるの?
CG?
0989デフォルトの名無しさん2007/08/30(木) 20:36:35
HPCだろう。でも、本気でやってる人はいないかと。
半分ギャグみたいなものだし。
0990・∀・）っ-＜コ:彡-2007/08/31(金) 02:19:18
WiiでLinux動かそうとかやってる人よりマイナーだわな
0991デフォルトの名無しさん2007/08/31(金) 10:46:33
団子さんのさりげない一言がビシッとキマりましたね。
0992デフォルトの名無しさん2007/08/31(金) 12:50:29
どうでもいい話ではあるが、客がTeslaC870を発注した。
問題は、TeslaはGPUといっていいのか悪いのかw
0993デフォルトの名無しさん2007/08/31(金) 12:52:34
グピグピウ、って読んでいいですか？
0994デフォルトの名無しさん2007/08/31(金) 13:25:46
ぐぷうぐぷ
レス数が950を超えています。1000を超えると書き込みができなくなります。