05/10/08 23:18:48
２
3:デフォルトの名無しさん
05/10/08 23:23:53
メモリーに関してはだんだんスパコンのアーキに近づいてるからなぁ。
4:デフォルトの名無しさん
05/10/09 03:46:05
ラデX1800のようにメモリレイテンシをあまり気にしなくていいというのは羨ましいな
5:デフォルトの名無しさん
05/10/09 11:50:01
ShとBrook期待age
6:デフォルトの名無しさん
05/10/09 13:11:52
CPU→GPU→CPUって経路でデータ流せるんだっけ?
7:デフォルトの名無しさん
05/10/09 14:06:12
出来なかったら、画面のキャプチャーとか出来ないだろ。
8:デフォルトの名無しさん
05/10/09 17:05:54
今現在、計算結果を持って帰るには一度フレームバッファに書いたのを吸い出すしかない。
今後改善されるとは思うけど、これじゃあ使えねぇよ。
でもXBOX360はメインメモリに直接アクセスする方法が用意されているらしい。
実用段階になったら、まずはトリップ計算機から誰か作ってよ。
9:デフォルトの名無しさん
05/10/09 17:21:09
>>8
ソース公開してる奴ってどれ？＞計算機
ちとやってみたい
10:デフォルトの名無しさん
05/10/10 14:05:01
これからはJavaやC#のようなオブジェクト指向言語をベースに
速度が重要な部分はシェーダー(GPGPU)でなんて流れになるのでしょうか？
11:デフォルトの名無しさん
05/10/10 14:58:23
なりません
12:デフォルトの名無しさん
05/10/11 14:13:56
GPGPUって過渡的なものであって、今後はXbox360/Cellに代表される
ヘテロジーニャスなマルチコアプロセッサの流れだろうな
13:デフォルトの名無しさん
05/10/11 14:43:51
360はホモ臭い
14:デフォルトの名無しさん
05/10/11 15:22:02
あぁたしかに360はハードウェアアーキはホモだけど、ソフトウェアアプリで
ヘテロっぽく使うんだった.
15:デフォルトの名無しさん
05/10/11 20:31:37
小泉風に言えばGPUでできることはGPUに、CPUでなければいけないところはCPUでってこと？
16:デフォルトの名無しさん
05/10/11 21:53:02
その言い方だと今までのアプローチとなんら変わらんがな
17:デフォルトの名無しさん
05/10/11 22:59:09
OpenGLとかで流行ったBASICにできることは（ｒｙ、Cでなければ（ｒｙと変わらんね。
18:デフォルトの名無しさん
05/10/11 23:55:23
それって>>10と同じじゃね？
19:デフォルトの名無しさん
05/10/12 00:04:04
未だにオブジェクト指向と速度を関連させる奴がいるのか。
20:デフォルトの名無しさん
05/10/12 00:24:44
JavaやC#が速いとはあんまり思えないけどな
21:デフォルトの名無しさん
05/10/13 21:17:35
age
22:デフォルトの名無しさん
05/10/13 21:32:40
情報が少なすぎて。。
23:デフォルトの名無しさん
05/10/15 00:38:51
RGBA8bitの32ビットフォーマットのテクスチャに対し、
各位置のビットが1のピクセルの個数を数える、見たいな処理って出来ませんかね。
Rの3ビット目が1のピクセルは150個、みたいな感じで。
RGBA4種類の個数とかだったら簡単に出来るんですが、
各ビット合計32個のデータを取り出す方法がおもいつかない。。
24:デフォルトの名無しさん
05/10/15 08:50:52
>>23
8bit パレット画像として扱うとかどう？
二アレスとサンプリングにして。
１回に１チャンネルしか処理できないけど。
25:デフォルトの名無しさん
05/10/15 12:41:23
>>24
やっぱり複数回に分けて処理するしかないですかねー。
せっかくデータをまとめたんだから、1度に処理できないかと考えたけど無理か。
26:デフォルトの名無しさん
05/10/15 14:27:28
bsf・・・はx86だしな
27:デフォルトの名無しさん
05/10/23 20:29:04
保守
28:デフォルトの名無しさん
05/10/24 02:06:59
JavaとGPGPUのコラボ最強と思ってるのはたぶん漏れだけ
29:デフォルトの名無しさん
05/10/25 01:53:53
GPUは基本的にストリームプロセッサだからCPUのような複雑な
分岐や少量のデータ処理を多数行うような仕事だと効率悪い。
現実は厳しいよ。
30:デフォルトの名無しさん
05/10/25 15:42:06
そういう仕事をGPUに投げるのが間違い。
31:デフォルトの名無しさん
05/10/25 23:21:53
>>29
大量のデータをひたすら単純処理する仕事はJavaの苦手とするとことだと思うのですが
32:デフォルトの名無しさん
05/10/25 23:39:54
C++とGPGPUこれ最強
33:デフォルトの名無しさん
05/10/26 01:58:39
>>1
語りたい事もないのに糞スレ立てるな
34:デフォルトの名無しさん
05/10/26 02:11:17
GPUってなんの計算をしてくれるのよ。
35:デフォルトの名無しさん
05/10/26 08:52:24
ようはSIMD
36:デフォルトの名無しさん
05/10/31 01:05:14
>>34
いまならシェーダーさえ書けばどんな計算だってしてくれる
向き不向きはあるが、膨大な量の単純計算繰り返しなら
最新のCPUよりもGPUのほうが早い
37:デフォルトの名無しさん
05/10/31 01:16:46
向き不向きなんてレベルじゃない。
かなりのレベルの並列性が無いとダメだし、入出力もかなり限定された形でしか出来ん。
どんな計算でもなんてとても言えん。
が、条件にはまる物ならばパフォーマンスの高さに驚く。
38:デフォルトの名無しさん
05/10/31 01:28:46
結局GPGPUの使いどころとしては画像処理(2D)・映像処理・音声処理あたりに落ち着くんでしょうかね
もともとGPUの得意分野だし
39:デフォルトの名無しさん
05/10/31 01:39:01
物理演算はねーの？？
40:デフォルトの名無しさん
05/10/31 21:15:21
GPU演算での精度はどれぐらいまで期待できるんでしょうかね？
41:デフォルトの名無しさん
05/10/31 22:43:58
丸めの方向を制御できなかったり、なんていう困った点もあるみたいよ＞GPGPU
42:デフォルトの名無しさん
05/11/08 00:19:25
保守
43:デフォルトの名無しさん
05/11/13 01:46:21
age
44:デフォルトの名無しさん
05/11/13 15:32:56
発想としては面白いし、昔からこういうハードを本来の目的以外に使うって話は好きなんだけど
(キャラクタ表示機能しかないマシンでビットマップ表示とかFM音源でPCM多重再生みたいな）
なんかあんまり現実的に聞こえないんだけど。。
ハイエンドなGPUなんてゲーマー以外もってないじゃん。
CAD用のGPUなんてもっと少数派だし。
そのくせ、3d表示で使ってる間は当然使えないわけだろうし。
だいいち各GPUの違いを吸収する負担は誰が負うのよ。
CPUのマルチコア化の流れを受けてのことなのかな。
昔のコプロみたいにCPUの中にそういうGPU的なアーキテクチャを組み入れていこう、
って展望でもあるのか？
45:デフォルトの名無しさん
05/11/13 16:05:04
3D表示使わないアプリで使えば無問題だし、
最近じゃハイエンドじゃなくてもシェーダが動く。
GPUの違いはシェーディング言語そのものでバージョン管理と、
そのラッパーであるライブラリで十分埋まる。
46:デフォルトの名無しさん
05/11/13 20:08:06
>>44
とても現状を理解しての発言には思えない。
47:デフォルトの名無しさん
05/11/13 20:15:55
PhysXもそろそろ出るね
CPU以外のパワーを利用するのって
一時的かと思ってたけど時代の潮流かな
48:デフォルトの名無しさん
05/11/22 18:01:21
URLﾘﾝｸ(staraxis.kazelog.jp)
ATIのAVIVOエンコード機能は凄い!!
DVD映像5分（720x480）をDivXやwmvにエンコードするのが25秒で終わるとか早すぎ！！！
GPGPUを使った物らしいです
49:デフォルトの名無しさん
05/11/22 22:17:01
いや、Theaterっていう専用チップが乗ってるよ
URLﾘﾝｸ(www.4gamer.net)
50:デフォルトの名無しさん
05/11/25 12:27:04
FAQ - GPGPU.org Wiki
URLﾘﾝｸ(www.gpgpu.org)
51:デフォルトの名無しさん
05/11/29 00:05:32
GPU GEMS2の日本語版が出たようだ
URLﾘﾝｸ(www.shader.jp)
52:デフォルトの名無しさん
05/11/29 00:06:17
sageたままだった・・・orz
53:デフォルトの名無しさん
05/11/29 00:09:53
AGPメモリにフレームバッファ確保できなかったっけ？
54:デフォルトの名無しさん
05/11/29 01:22:55
>>10
Javaチップ、Javaアクセラレータ
なんてものがあるしな。
考えられなくもないな
55:デフォルトの名無しさん
05/11/29 01:24:29
>>19
むしろVMと速度だな。
C言語の中の人は
オブジェクト指向を使うと速度が遅くなる
から使わない方がいいとか未だにいっているからね。
56:デフォルトの名無しさん
05/11/29 01:25:23
>>28
JavaのGUI, Swing APIやJava3D APIの3Dレンダリングの
部分だけGPUに任せられたらいいねえ。
57:デフォルトの名無しさん
05/11/29 01:29:20
>>31
それも微妙なところではあるが。
Java SE 5 Tigerからかなりの高速化が実現されているし
Java SE 6 Mustangからはさらに高速化する。
Javaアプリ初回起動だけVM上で動いて
２回目以降からはネイティブで動くってことがあるわけで。
Javaアプリを起動するたびにVMをいくつも起動するという
問題も解消されるし。
それとJavaは他の言語と比べレスポンス性能が
極端に遅いことからクライアントサイドでは普及が
一時停滞した。ところがJavaは代わりに
スループット性能が高いという利点があったりする。
他の言語が戦術的短距離走タイプであるのに対し、
Javaは戦略的マラソンランナータイプ、ってところだろうか。
58:デフォルトの名無しさん
05/11/29 11:54:36
>>56
Java3DはOpenGLかDirect Xがバックエンドになっているんだが。
ちなみに、SwingをGPUに描画させるという考えは、Swingの
設計思想(全部Javaで描画)に反するから実現不可能。
59:デフォルトの名無しさん
05/11/29 16:23:09
これってグラボ変えたら動かなくなるんでしょ？
グラボなんてドンドン新しいのが出るんだからそんなの使えネェじゃん。
60:デフォルトの名無しさん
05/11/29 16:42:24
それを避けるための高級言語じゃないの？
61:デフォルトの名無しさん
05/11/29 17:11:03
自作板の雑談と何も変わらんな
62:デフォルトの名無しさん
05/11/29 17:42:26
大抵はグラボを変えても動きます
特に新しいものに変える場合は可能性は高いです
例えるなら>>59は「MMXってCPU変えたら動かないよね？」みたいな質問です
63:デフォルトの名無しさん
05/11/30 00:55:00
＞大抵はグラボを変えても動きます
大抵って？
＞例えるなら>>59は「MMXってCPU変えたら動かないよね？」みたいな質問です
MMXは、世に機能公開して広範なアプリを作らせた以上、
後継CPUでは完全互換を取って当たり前、という位置にいるわけだが、それと同等と？
MMXが出たのは１０年くらい前で、今でもまだ動くんだが、それと同等と？
64:デフォルトの名無しさん
05/11/30 01:01:32
>>63
既にShaderはほぼ標準装備ですが何か？
65:デフォルトの名無しさん
05/11/30 01:12:41
>>63
並列アルゴリズムの実装のために少しでも安くて速い計算リソースを使おうという研究なんで、
互換性を気にして「10年後に動かなかったらどうするんだよ」という向きには用は無い。
66:デフォルトの名無しさん
05/11/30 01:25:58
そもそもGLSLはOpenGLドライバ側でコンパイルされてGPUのコードに変換されるものだから
原則的にはGPUが変わっても動くと考えても問題ない。
(バグや仕様で動かない可能性は100%否定できないが)
ARBあたりから互換性のないシェーダー言語が出てきて、
どっかのGPUメーカーが今のGLSLをサポートしなくなるということがあれば問題になるが
ここまできてARBやGPUメーカーが今の仕様を完全放棄するのは難しいと思われ
67:デフォルトの名無しさん
05/12/01 19:23:35
今までのGPUは後方互換をほぼ意識しないで拡張してきたからこれだけの性能が出たのだと思う。
今後もちゃんと動くかはかなり疑問に感じる。（GPGPUが一過性のような気がする。
＃最近のボードでも過去のDXは動くけど、ネーティブに動いてるわけではなくて、ドライバ辺りのエミュレートだったと思う。
68:デフォルトの名無しさん
05/12/01 20:10:14
まぁ一過性というのはそのとおりでGPUは通過点でしかないだろうね。
今はいろいろ試して、問題点を出したり適応範囲を模索したりしてる段階。
それを元にハードウェアも含めてだんだん方向性が決まってくるわけで。
69:デフォルトの名無しさん
05/12/01 21:17:17
GPUに本当に有用なアーキテクチャがあるならコプロと同じ運命をたどるでしょ。
リレースイッチをブザー代わりに使うような技術に発展性があるわけがない。
70:デフォルトの名無しさん
05/12/11 06:22:53
age
71:デフォルトの名無しさん
05/12/13 05:47:10
>>69
浮動小数点演算はコプロというか専用エンジンが無いとどうしようも無いぞ。
それはCELLとかも同じ。
72:デフォルトの名無しさん
05/12/13 19:53:50
整数演算もできるようになるのはいつ？
73:デフォルトの名無しさん
05/12/13 21:27:15
>>71
意味わからん。話が噛み合ってないな。
どうでもいいけど、コプロがない時代はPCは浮動小数点演算ができなかった、
とでも思ってるのかなw
74:デフォルトの名無しさん
05/12/14 16:26:15
マシンに本物のFPU積んだ時には、嬉しくって毎日レイトレしてたな。
75:デフォルトの名無しさん
05/12/14 16:41:40
コプロ積んでもBASICが全く速くならなかった時には、orzだったな。
76:デフォルトの名無しさん
05/12/15 20:19:33
>>69
しかしブザーが出回るまでの間は有用だし生き延びるだろうさ。
77:デフォルトの名無しさん
05/12/17 09:48:59
コプロ無しの少数演算って遅すぎだろ
78:デフォルトの名無しさん
05/12/17 09:56:39
それよりGPGPUの話をしよう
79:デフォルトの名無しさん
05/12/17 14:40:11
先生！誰もわかってないので話すことがありません！
80:デフォルトの名無しさん
05/12/17 18:07:10
GPGPUは手段であって、目的じゃないからな。
なにか高速に計算したいものがあって、その手段としてGPGPUが良ければ使う。
目的がないのにGPGPUやろうぜとか言われても盛り上がらん。
手段のために目的を探すのはアホだしな。
81:デフォルトの名無しさん
05/12/17 18:47:17
目的がないから手段も学ぶ必要ないもんな・・・・
日本発のGPGPUを使ったDivXエンコーダーとか作れれば盛り上がるのだろうが。
82:デフォルトの名無しさん
05/12/17 20:29:41
GPGPU = Game Programming Gems(ﾌﾟ
83:デフォルトの名無しさん
05/12/18 03:24:22
>>47
GRAPEは専用プロセッサのままなので他では使われないね。
コプロにしたほうが広がりやすい気がするけど帯域が問題なのかな。
URLﾘﾝｸ(www.itmedia.co.jp)
そして東工大のOpteronグリッドにはClearSpeedのSIMDアクセラレータが乗る
URLﾘﾝｸ(www.itmedia.co.jp)
URLﾘﾝｸ(japan.cnet.com)
84:デフォルトの名無しさん
05/12/19 15:18:34
Scoutって一番興味あるんですが、まだ公開はされていないんですか?
Los Alamos National Labsのサイトに行ってもPDFの論文にしかリンク貼ってない。
85:デフォルトの名無しさん
05/12/21 01:05:14
>>84
Brook for GPU じゃだめなの？
86:デフォルトの名無しさん
05/12/21 13:29:13
Vista時代で、常に3D使うようになったらGPGPUも終わりな気がするのは
俺だけかな。
87:デフォルトの名無しさん
05/12/22 17:50:35
AeroGlassをEnableにすれば大丈夫じゃない？
88:86
05/12/22 18:09:05
AeroGlassをEnableにすると、常にシェーダーが使われているわけだから
GPGPUには使えないのではないかと思ったんだけど。
89:デフォルトの名無しさん
05/12/22 20:22:33
>>86
GPGPUって科学技術計算等の激しく重い演算用だろ？
普通のアプリ走らせてる横でやる必要もないと思うが。
90:デフォルトの名無しさん
05/12/22 20:29:13
聞きたいのは二つのシェーダー使うアプリを同時に使用できるかと言うこと。
できるのならWindowsがGPU使っていてもGPGPUできるだろう。
もしできないのであったら、GPGPUするときはAeroGlassをオフにしなければならない。
>>89が言うことももっともだが、いちいちそんなことが必要になるなら価値は少し下がる。
91:デフォルトの名無しさん
05/12/23 00:15:44
GPUにもコンテキストスイッチは存在するんじゃね？
92:87
05/12/23 00:16:23
ごめん、英語間違ってますた…disableだ…＿|￣|○
93:デフォルトの名無しさん
05/12/23 00:34:05
VistaではGPUが仮想化されて、DirectXのデバイスロストが無くなる。
GPGPUとAeroGlassの併用も可能と思われ。
94:デフォルトの名無しさん
05/12/25 18:37:14
>>90
GUIは(ゲームなどの描画と違って)四六時中描画してるわけではない。
95:デフォルトの名無しさん
05/12/26 05:54:47
>>90
多分できるだろうけど、切り替えが発生したら猛烈に遅くなる予感。
GPGPUの唯一の価値＝速度だから、あんまりそういう用途には向いてないような・・・
96:デフォルトの名無しさん
05/12/26 19:08:48
計算用に、もう一枚刺す。
97:84
05/12/26 19:49:18
>>85
いや、なんか紹介記事見てたら、簡単そうで。
C*の情報がないので言語仕様がわからないけど。
Vista時代には、PCI-ExpressにGPUどんどん追加していける仕様にするのでは。
x1でもパフォーマンス出るように工夫する必要があるけど。
98:デフォルトの名無しさん
05/12/26 21:46:14
>多分できるだろうけど、切り替えが発生したら猛烈に遅くなる予感。
CPUはそれなりに現実的にマルチタスクできてるんだから
GPUだけできない理由は何もないような。
ドライバがそこらへんに対応してれば。
99:デフォルトの名無しさん
05/12/27 16:55:05
>>98
並列性が高い分、タスクスイッチに伴うペナルティコストが、CPUに比べて
馬鹿にならないと思われ。
100:デフォルトの名無しさん
05/12/27 17:07:20
並列動作可能なら、CPU側のタスクに合わせてタスクスイッチする必要はないんじゃない？
OS分の描画やりながら、遊んでるユニットでGPGPUの計算するとかできんの？
101:デフォルトの名無しさん
05/12/27 19:25:35
VistaになってもUIは2kスタイルに設定するから問題ない。
102:デフォルトの名無しさん
05/12/27 22:44:45
>>100
ローカリティの問題があるから、かなりVRAM積まないと違う作業はやりにくいと思うよ。
別カードにした方が賢いね。OSの描画はUMA、GPGPUはPCI-Eとか。
103:デフォルトの名無しさん
05/12/27 22:56:31
結果はどの道メインメモリに書き戻すんだからそれほど大きなワークは必要なさそうな気もするが。
scatter&gatherつってもその範囲は高が知れてるし。
まあ用途次第だけど。
104:デフォルトの名無しさん
05/12/28 21:03:56
GPGPUを使ったプログラムを誰かうｐしてくれよ
105:デフォルトの名無しさん
06/01/08 11:27:22
だれかエンコーダー作ってよ。
sf.net探したけど見つからないし。
106:デフォルトの名無しさん
06/01/21 15:20:00
保守。
107:デフォルトの名無しさん
06/01/21 16:23:17
>>89
MFLOPS単位で処理能力公表してるし、浮動小数計算するのがメインっぽいね。
代表的なのとしては、動画再生支援くらい？
画像音楽動画エンコくらいしかおもいつかね。
他に浮動少数が活躍する場面ってなにがあるかな？
>>90
3Dならそれぞれのオブジェクトに対するシェーダーをロードして描画って感じだから、
それぞれのパイプラインが処理して同時に出力できるってな感じじゃねの？
108:デフォルトの名無しさん
06/01/22 11:00:38
今こそGPGPUを活用するときではなかろうか。
URLﾘﾝｸ(pc.watch.impress.co.jp)
109:デフォルトの名無しさん
06/01/22 13:01:49
H.264はAMDがYAMATOでデモってたけど、
やっぱ70Mbpsまでいくとコマ落ちするんだろうか。
110:デフォルトの名無しさん
06/01/22 22:42:33
PureVideoとか待ってられないから、オープンソースで
シェーダ実装のH.264デコーダーとかでないかな。
111:デフォルトの名無しさん
06/01/22 22:46:15
つかここム板なんだからGPGPUでhello, worldくらいやれ
112:・∀・）っ-○●◎- ◆Pu/ODYSSEY
06/01/22 23:00:21
だめだろ文字列を描画する以上の複雑な計算が無い
描画を豪華にしたいなら普通にシェーダ普通に使えって話
113:デフォルトの名無しさん
06/01/25 09:18:55
ATI X1900スゲー化け物だね。
ただ例によってSM3.0といってもフル実装ではないのかな。
GPGPUというとどうしてもnVIDIAという印象があるから
手を出すのは勇気が要るのだけど・・・。
114:デフォルトの名無しさん
06/01/25 22:46:15
純粋にグラフィック扱うならHDRでもAA効くATiの方がいいと自分は思ってるけど
VTFとか見てるとほかにも問題ありそうで怖い。
115:デフォルトの名無しさん
06/01/25 22:47:57
まだまだ実用的ではないな
116:デフォルトの名無しさん
06/01/25 23:16:11
X1800の時の爆熱問題を解決しないまま、
さらに熱い物を出してくるのは凄い。
117:デフォルトの名無しさん
06/01/25 23:30:00
実際X1900なんてメディアのベンチ掲載用にとりあえず作ったやつでしょ。
数出さなければ、いくらでもできるよ。
普通のCPUだとただコア増やすだけじゃ意味無いけどGPUなんて増やせば増やすだけいいしね
まぁ一つが小さくて単純だからできるんだろうけど。
118:デフォルトの名無しさん
06/01/26 02:34:56
3DMarkだけスコアが高いなんてさすがATIだな
119:デフォルトの名無しさん
06/01/26 03:55:46
それでも48基って一度触ってみたいﾊｧﾊｧ
120:デフォルトの名無しさん
06/01/26 12:43:18
>>119
お熱いのがお好き?
121:デフォルトの名無しさん
06/01/26 19:11:38
Intelが45nm製造に成功って書いてあったけど、
実用化されれば90nmの製品がまったく同じものだと1/4の面積になるの？
122:・∀・）っ-○●◎- ◆Pu/ODYSSEY
06/01/26 19:53:37
原子・分子のサイズの限界もあるからまったく同じにはならない筈だよ。リーク電流対策とか必要だし。
123:デフォルトの名無しさん
06/01/27 10:13:52
>>10
速度が重要で、かつこれからやる処理の中でGPUだと著しく速い命令で解決できる処理を内包する時だろ？
124:デフォルトの名無しさん
06/01/27 18:20:22
GPGPUをやってみうと思い、試行錯誤しているのですが、
floatの配列を画像に変換してテクスチャとして貼り付け
オフスクリーンに出力された画像をfloatの配列に戻すまでは出来たのですが
シェーダー上ではテクスチャや出力する色情報がvec4やfloat4となっていて、
そのままfloatとして扱うことができません。どうすればいいのでしょうか？
125:デフォルトの名無しさん
06/01/27 18:31:18
>>124
つ スウィズル演算子
まあ並列で処理しないとGPGPUの魅力が4分の1になるんだが。
126:デフォルトの名無しさん
06/01/27 18:39:12
カタカナだと出ないな
URLﾘﾝｸ(www.microsoft.com)
127:デフォルトの名無しさん
06/01/27 18:50:10
>>125-126
即レスありがとうございます。
これを参考にいろいろ調べてみます。
128:デフォルトの名無しさん
06/01/28 02:14:37
スレ立て以来初めてム板らしいやりとりが成立したなｗ
129:デフォルトの名無しさん
06/01/28 16:48:11
次はCPCPUの時代
130:デフォルトの名無しさん
06/01/28 17:03:46
みんなこれ読んだか?
URLﾘﾝｸ(grape.astron.s.u-tokyo.ac.jp)
131:デフォルトの名無しさん
06/01/29 02:08:39
>>130
説明は面倒くさいが、その記事には同意しかねる。
GPGPU が万能じゃないなんて当たり前な話で、使いどころが分かってない奴は使わなければいいだけの話だ。
俺はゲーム屋だから、やらせることはいくらかある。だからやらせる。
132:デフォルトの名無しさん
06/01/29 13:28:06
なあ最近ひらめいたアイデアなんだけど聞いてくれる？
普通テクスチャをシェーダにバインドするときの最大でも16ぐらいまででしょ？
でもテクスチャの代わりにキューブテクスチャを使えばx6枚使えることにならん？
例えばR32Fのシャドウマップを普通にバインドすると16だけど
RGBA32Fのキューブマップとしてバインドすれば16x6x4=384になる。ﾅｲｽｰｱｲﾃﾞｰｱじゃね？
133:デフォルトの名無しさん
06/01/29 13:46:53
>>132
キューブの境界に連続性が無いデータだと、ちと不安だな。
あと、rgba にするのは、チャンネル間移動が無いことが前提だな。
いざというときには使える tips かもね。
134:デフォルトの名無しさん
06/01/30 13:05:44
>>121
原子分子のサイズが主要な問題ではないんだけどな。
半導体製品の製造工程は理解できている?
#つーか、原子分子のサイズだけを問題にできるような製造技術があったら一財産築けるぞ。
135:デフォルトの名無しさん
06/01/31 23:43:28
URLﾘﾝｸ(v-infinity.seesaa.net)
GPGPUを使っていると思われるエンコードソフト
ATIとnVidiaのビデオカードで動作するらしい。
136:デフォルトの名無しさん
06/01/31 23:58:44
>>135
>>48
137:デフォルトの名無しさん
06/02/01 15:17:52
記事先では、GPUではなく、CPU処理って書いてるけど
ぶっちゃけ、単なるシェーダーで処理してるだけなら、現行のGF/ATiのGPUでGPU処理できると思うんだが・・・。
138:デフォルトの名無しさん
06/02/01 18:18:42
GPUはUIの表示以外に使ってない。将来的には使う予定だろうけど。
じゃあ最初にCPU用コード書く必要ないじゃんね。もしかしてOSSのぱくり？
139:亀レスだが
06/02/13 02:25:14
>>31
> 大量のデータをひたすら単純処理する仕事はJavaの苦手とするとことだと思うのですが
そんなことはない。
GPUが得意なことではあるが、
CPUが得意なことでJavaが不得意なことはない。
むしろHotspotの登場で数値計算などの分野での活躍が他言語より目立ってる。
システムよりな事、例えばアプリの起動速度、は苦手なこと多いが。
140:デフォルトの名無しさん
06/02/13 09:54:38
>>139
おまえはJavaでソフトウェアレンダーでも書いてろ。
141:デフォルトの名無しさん
06/02/13 10:54:25
確かに多少ゆがんでるようだが>>31よりは事実に近いな
142:デフォルトの名無しさん
06/02/13 14:35:11
Java厨は消えろ。どうせシェーダなんて叩けないだろ。
143:デフォルトの名無しさん
06/02/14 22:43:23
Java氏ねPCの動作を重くする害虫ソフトめ！
144:デフォルトの名無しさん
06/02/14 23:49:16
重くなるのか？
145:デフォルトの名無しさん
06/02/15 13:05:37
>>139
単語に反応するだけじゃなくて、議論の流れを読めよ。
146:すだこ
06/02/27 03:45:54
実際問題として例えば
LAPCKが動いた
とか
姫野ベンチがいくらだったとか
そういうのって、どっかにあるんですかね？
147:デフォルトの名無しさん
06/02/27 12:07:53
JavaのJITがGPGPUを使用するコードを吐くと嬉しい。
これが出来たら、ネイティブコード系の言語がいらなくなるかも。
性能面で。
148:デフォルトの名無しさん
06/02/27 15:22:15
>>147
JavaからGPU使えばいいだけでは？
149:デフォルトの名無しさん
06/02/27 16:15:47
実行環境が対応することで
開発した当初は存在してないGPUも
活用できるようになるだろ。
WORAの思想もそのまま生かされる。
150:デフォルトの名無しさん
06/02/27 16:19:09
そのためのCgでは？
151:デフォルトの名無しさん
06/02/27 18:39:33
Cgは演算結果をメインメモリに書き出せない。
だから、基本的にはグラフィック処理にしか使えない
152:デフォルトの名無しさん
06/02/27 20:05:18
メインメモリに書き出すのはシェーダではなくAPIの役目では？
153:デフォルトの名無しさん
06/02/27 20:44:31
そういう仕組ができれば自然とCgやHLSLもサポートするだろう。
問題はいつサポートされるのかということと、まともなスピードで
出せるかということだ。
154:デフォルトの名無しさん
06/02/27 20:49:46
Direct3D10のOutputStreamみたいな話？
155:デフォルトの名無しさん
06/02/27 22:02:15
>>148
透過的にして欲しいということだろ？
現状VMもSSE2とか自動判別してつかうようになったり
ハードウェアアクセラレーションもDirectXやらOpenGLやら使えてる
WinだとNT4対応のためにDirectDrawがデフォだが描画時テクスチャの
コピーをメモリからVRAMに自動的に作って高速にブリット、
オフスクリーンイメージが失われたらメインメモリから復旧とか全自動だ
もちろん、VRAMにおいておく優先順位が設定できて自動的にVRAMから
おいだされたりとかわりとすばらしい
156:デフォルトの名無しさん
06/02/27 23:24:09
Java3Dでシェーダ使えるんじゃないの？
157:デフォルトの名無しさん
06/02/27 23:34:47
なぜゆえこのスレでJavaにこだわるんだ
158:デフォルトの名無しさん
06/02/27 23:36:08
極度に抽象化されているがゆえに知らないうちに使われている
という状況が一番あるからでは？
159:デフォルトの名無しさん
06/02/27 23:51:55
JITにGPGPU使わせるよりも、
シェーダをJavaで記述する方向で開発した方がいいだろう。
160:デフォルトの名無しさん
06/02/28 00:07:10
5.0で追加されたatomicAPIとかみたあとではもう何が来ても驚かん。
161:デフォルトの名無しさん
06/02/28 12:52:32
CoreImageもGPGPU？
162:デフォルトの名無しさん
06/03/03 18:51:04
わけねーだろ
163:デフォルトの名無しさん
06/03/03 22:20:09
GPGPU = 食べるための研究ネタ + 趣味
164:デフォルトの名無しさん
06/03/04 11:40:46
でも、かつての「コプロセッサ」みたく、
ベクトル演算用のプロセッサを
メインプロセッサの他に持つのって
たぶん正解の一つだよな。
バスがハイパートランスポートだと最高かな。
165:デフォルトの名無しさん
06/03/04 12:08:02
>>164
その考え方だといつかはCPUに取り込むのが普通
という結論になっちまうぞ
感覚的には非対称型マルチプロセッサのほうが近いのでは
166:デフォルトの名無しさん
06/03/04 13:44:50
>>164
＞ベクトル演算用のプロセッサを
＞メインプロセッサの他に持つのって
その目的は何だ？
167:・∀・）っ-○●◎- ◆Pu/ODYSSEY
06/03/04 15:31:49
暗号とかゲーム用物理演算のアクセラレーション
168:デフォルトの名無しさん
06/03/04 22:13:25
それって、CELLじゃん。
169:デフォルトの名無しさん
06/03/04 22:14:53
>>168
orz
車輪の再発明スレに行ってくるか....
170:・∀・）っ-○●◎- ◆Pu/ODYSSEY
06/03/04 22:26:06
でもIntelのMany Core構想ってCellにも通じるものがあるよ。
汎用プロセッサだから当分はメインコアのリッチ化は進行するだろうけど。
171:デフォルトの名無しさん
06/03/05 02:02:27
つーか、ＤＳＰ搭載やらｘｘコントローラ搭載なんてＣＰＵはありふれてるし、それらと今のＧＰＵはちょっと違うだろ。
依存性の無い並列処理がたまたま最近（ちょっと昔？）の頂点処理や画素処理にあるわけだ。
Cell なんかは、あまりＧＰＧＰＵっぽくはない。ＤＳＰを７つとか８つ積んでるようなもんだ。
ゲーム屋には面白いけど、ＧＰＧＰＵらしい並列演算を念頭に置くなら、ヘテロなんてどうでもいい。ＧＰＧＰＵのパワーの源は、同じコンテキストの演算を別パラメータで同時に実行するトコにあるわけだから。
172:デフォルトの名無しさん
06/03/05 12:12:59
昔パソコンのCPUが貧弱な時代にはプロセッサボードというのがわりとありまして
拡張スロットにCPUより性能のよい石とメモリがのっておりました。
歴史は繰り返してるだけ
173:デフォルトの名無しさん
06/03/05 13:10:09
それいうならコプロw
つーかガイシュツ杉
174:デフォルトの名無しさん
06/03/05 13:20:07
このスレでGPGPU以前にシェーダプログラミングやったことある奴って
２・３人しかいなさそうだな
175:デフォルトの名無しさん
06/03/05 14:42:12
>>173
コプロだとコプロインターフェース経由でのアクセスという意味だから
外部にあるプロセッサとは別物だろう
そしてGPUはそっちの方式
176:デフォルトの名無しさん
06/03/05 17:50:21
O・D・P！O・D・P！
177:デフォルトの名無しさん
06/03/05 22:25:24
組み替え可能ハードウェアはどうよ
FPGAで組むと、クロックは半分くらいになるらしいけど、
特定用途なら１サイクル当たり倍以上の性能だせるっしょ
178:デフォルトの名無しさん
06/03/05 23:05:11
数百MHz～数GHzクラスのクロックで動かせる一般向けFPGAってあるのか？
179:デフォルトの名無しさん
06/03/05 23:47:43
通常300MHzくらいまでだな
ただし、腕による
180:デフォルトの名無しさん
06/03/06 00:54:43
URLﾘﾝｸ(www.xilinx.co.jp)
これは５００MHzってなってるね
フリーの高速実装とか出回ればよさげ。
181:デフォルトの名無しさん
06/03/06 01:18:40
ハードウェア加速という訳がきらい
182:デフォルトの名無しさん
06/03/12 10:18:08
ハードウエアブーストってのはどうだ？
183:・∀・）っ-○●◎- ◆Pu/ODYSSEY
06/03/12 19:51:14
ハードウェアｋｓｋ
184:デフォルトの名無しさん
06/03/17 02:42:33
GPGPUって
文字列の計算とかできる。
AAAABBAACCAAAにCは何個含まれているかとか計算できるの？
いまいちどんな計算できるかわからない
185:デフォルトの名無しさん
06/03/17 19:20:23
文字だって、１つ１つは数値でしょ。アスキーコードの
普通に出来るっしょ
186:・∀・）っ-○●◎- ◆Pu/ODYSSEY
06/03/17 22:18:32
整数演算性能には期待しないほうがいい気もするんだが・・・
187:デフォルトの名無しさん
06/03/18 00:11:39
期待するとかしないではなくて可能か不可能かしりたい
現状Pentiumの100Mhzぐらいの処理性能でもいいから
可能かどうか知りたい
サンプルとか全然なくて書き方すら解らず困り気味
188:デフォルトの名無しさん
06/03/18 01:32:06
文字コードを実数に変換して処理するとか（ｗ
189:デフォルトの名無しさん
06/03/18 03:03:19
可能かどうかで言ったら、むしろ不可能なことの方が少ないだろう。
ただ184の処理は明らかにGPU向きではない。
というより184は>>131の2行目でも読んでくれ。
190:デフォルトの名無しさん
06/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 のゲームはお蔵入りしたｗｗｗｗｗｗ
今ＤＳやってるｗｗｗｗｗ
おまいらはテクスチャフェッチのレイテンシ隠すのに涙目になってればいいさ、ばーかばーかｗｗｗｗｗｗ
191:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 22:16:50
TextSS のWindowsXP(Professional)64bit対応化おながいします
もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？
192:デフォルトの名無しさん
06/03/18 23:19:37
>>190
あー
お前特定できちゃいました
193:デフォルトの名無しさん
06/03/19 02:03:09
興味あるのですがどこから入門すればいいのでしょうか
194:デフォルトの名無しさん
06/03/19 09:41:45
>>190のVRAMアドレッシングの話って、詳しい説明あるとこない？
195:デフォルトの名無しさん
06/03/19 20:42:58
>>194
知らん。
しかしピクセルがＶＲＡＭ上で何故ジグザグに配置されているかを理解してれば問題ないんじゃないだろうか。
それ以上は機器固有の話だから、実測するしかない。
196:デフォルトの名無しさん
06/03/19 23:05:06
havok fx
URLﾘﾝｸ(www.shader.jp)
197:デフォルトの名無しさん
06/03/20 01:47:19
>>195
ジグザグに配置って初めて知ったんだけど、どういうこと？
URLﾘﾝｸ(spin.s2c.ne.jp)
の、ヒルベルト曲線順ラスタライズみたいな話ですか？
198:デフォルトの名無しさん
06/03/20 09:58:10
通りすがり＆スレ読んでなくて悪いけど、これはガイシュツ？
GPU コンピューティングの動向と将来像
URLﾘﾝｸ(www.jaist.ac.jp)
199:デフォルトの名無しさん
06/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 のような人にとって喜ばしいことだ。
200:デフォルトの名無しさん
06/03/21 02:28:18
>>198のは>>196の管理人が書いた物だ
201:デフォルトの名無しさん
06/03/21 13:15:32
プログラミングはどこから始めたらいいのでしょうか。
GPGPUの技術的な背景とかは解りましたが、
とりあえずプログラム組んでみてどこまで可能か調査
してみたいのですがみなさんはどこから学んだのでしょうか
202:デフォルトの名無しさん
06/03/21 22:16:46
>>201
アバウトすぎだ。
何が知りたいのかサッパリわからん。
URLﾘﾝｸ(www.redout.net)
nVidia のサイトでも行けば？
203:デフォルトの名無しさん
06/03/21 23:29:42
いやもうHelloWorldレベルでいいんですけど
204:デフォルトの名無しさん
06/03/21 23:55:15
・・・・。
がんがれｗ
205:デフォルトの名無しさん
06/03/22 01:51:25
>>203
URLﾘﾝｸ(msdn.microsoft.com)
これで不満なら、どこまで出来てどこで詰まってるのか説明しろ。
他の連中は知らんが、俺はエスパーじゃねぇ。
206:デフォルトの名無しさん
06/03/22 13:56:48
↑それは、GPGPUというよりDirectXのHelloWorld
要するにGPUで1+1を計算させて2という値をメインメモリに
持ってくるようなのがGPGPUのHelloWrldじゃないのかな。
207:デフォルトの名無しさん
06/03/22 17:28:42
NVIDIA、GPUによる物理シミュレーションをGDCでデモ
URLﾘﾝｸ(pc.watch.impress.co.jp)
208:デフォルトの名無しさん
06/03/22 23:28:39
>>206
じゃあお前が説明してやれよ。
アレやったら、描画先を変更してサーフェスをロックして持ってくるだけだろ？
演算方法なんざ、最初はレンダーステートの設定だけで十分だろ。
つーか、ナンセンスな回答だってのは承知してんだよ。
何が分からんのか分からねーんだから答えようがねーよ。
財力もプラットフォームも言語知識もハードウェア知識も分かんねーのにどんなアドバイスができるってんだ。
つーか GPGPU で Hello World つったら、Hello World って書いたテクスチャをフレームバッファにレンダリングすることじゃないか？
フレームバッファこそ、GPGPU の標準出力としては相応しいだろう。
なんでそんなに俺をイラつかせるんだ、ってスレが昔あったなあ。マ板だっけ？
209:デフォルトの名無しさん
06/03/23 02:01:06
Brookとかｓｈとか使ってプログラム組んでみた方いますか？
今ちょっと勉強してます。
210:デフォルトの名無しさん
06/03/23 11:58:18
レンダリングするだけじゃ普通の描画じゃんか。
211:デフォルトの名無しさん
06/03/24 01:10:12
>>210
何が不満なんだ？ Hello World と同じくらいには役に立つと思うが。
212:デフォルトの名無しさん
06/03/24 04:49:25
クダ巻くだけならどっかいけ。
213:デフォルトの名無しさん
06/03/24 12:58:06
>>211
>1を読めよ
>いつの間にやらCPUを超える演算性能を持ってしまったGPUに計算させてみるという
>GPGPUについて語りましょう
214:デフォルトの名無しさん
06/03/24 14:11:29
>>213
演算結果の出力がレンダリング結果じゃないか。
エッジ抽出や DCT とかしたら、フレームバッファに転送して目視確認するだろ？
何が足りないんだ？ それとも何かが蛇足なのか？ 「入門」がスレ違いなのか？
215:デフォルトの名無しさん
06/03/24 14:34:21
じゃあDirectXスレでいいじゃん
このスレ要らんね
終了か？
216:デフォルトの名無しさん
06/03/24 15:32:51
GPUで計算してフレームバッファに書き出して、そのフレームバッファを
メインメモリに持ってきて、それを構造体に格納していくくらいのことしないと
HelloWorldとは言えない。
そして、いまでは専用言語で簡単にできるじゃないか。
217:デフォルトの名無しさん
06/03/24 20:46:13
行列演算が簡単に出来れば応用範囲が広がりそう
218:デフォルトの名無しさん
06/03/24 21:40:10
俺もHelloWorldを欲してるクチでGPUを使う方法が分からないから何とも言えんが
行列演算はSIMD向きじゃん。文字列処理に比べれば簡単だと思う。
問題は、どれだけGPUにデータを留めたまま大量に演算出来るかじゃないか?
1演算してはCPUが使うようだと、GPU間のデータ転送に時間を食われる。
219:デフォルトの名無しさん
06/03/24 22:48:22
みんな、DSP的に使いたいのでしょ？
メディアンフィルタとかエンコーダーとかやってみたいね。
俺もやり方はよくしらんが。
220:デフォルトの名無しさん
06/03/25 01:54:11
はっきり言ってDSP的に使う以外、GPUに興味ないな
だれか教えてくれないのですか？ケチしないで教えてくださいよ
221:デフォルトの名無しさん
06/03/25 03:04:58
>つーか GPGPU で Hello World つったら、Hello World って書いたテクスチャをフレームバッファにレンダリングすることじゃないか？
ﾜﾛﾀ
222:デフォルトの名無しさん
06/03/25 05:02:12
>>215
> じゃあDirectXスレでいいじゃん
いいアイデアだ。入門はヨソの描画ライブラリスレに任せよう。
このスレは入門に限ったスレじゃないから、話題がある限りは不要ということも無いだろう。
>>216
ロックして持ってくるだけだろ。入力データもロックして書き込まないと認めないということか？
専用言語とやらを入門とすることについては、君が説明する分には俺に異論は無い。
>>221
楽しんでいただけたようでまことに結構。
223:デフォルトの名無しさん
06/03/25 05:44:20
定番の波動シミュレーションあたりが、Hello World的存在じゃないかな。
GPGPU的には全く面白くないネタだけど、Hello Worldってそんなもんだろう。
224:デフォルトの名無しさん
06/03/25 12:03:44
よし決めた。
最初の目標はGPUでπの計算することだ。
225:デフォルトの名無しさん
06/03/25 17:53:00
>>223
おれはそういうのは、最初の演習問題にはふさわしいけれども、Hello World 的だとは思えないのだが。
ちょっとのお約束と、なんらかの出力、という程度が Hello World 的ではあるまいか。変数や制御構文の前にやるものだし。
描画はできる、というのを前提とするのなら、プラットフォームやライブラリを越えて一般化できる具体的（ソースつき）な入門はありえない、という結論になるだろうか。それとも専門言語の人に期待するか。
226:デフォルトの名無しさん
06/03/25 21:14:14
なにこのヘタレの素靴
227:デフォルトの名無しさん
06/03/27 04:59:04
>>226
ようこそ
228:デフォルトの名無しさん
06/03/27 14:23:17
GPGPUって、
ベクトル演算器→たけーよ→グラボ使えるじゃね?→できるもんならやってみろ
の世界だろ。
229:デフォルトの名無しさん
06/03/27 23:44:08
うんそう
230:デフォルトの名無しさん
06/03/28 12:16:07
だからフレームバッファに描画さえすればhello worldとか言うのはおかしい
231:デフォルトの名無しさん
06/03/29 09:04:50
うんこう
232:デフォルトの名無しさん
06/03/29 17:33:43
>>230
あとはロックするコードだけ晒せばいい？
他には何かある？
そもそも DirectX 限定というはおかしいと思うのだが、そういう指摘は無いの？
それとも Hello World の定義が違うなら、>225 に書いた、「最初の演習問題の前」「変数や制御構文の前」とは違う定義をしてくれ。
233:デフォルトの名無しさん
06/03/29 18:23:34
1+1, 1+2+3+...+10を計算するコード
234:デフォルトの名無しさん
06/03/30 13:44:56
どちらか？ それとも２つとも？
235:デフォルトの名無しさん
06/03/30 13:46:57
後者がいいな。ループも使うし。
236:デフォルトの名無しさん
06/03/30 17:44:06
トリップサーチはどう？
237:1/3
06/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>]
238:2/3
06/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
239:3/3
06/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
240:デフォルトの名無しさん
06/03/32 20:06:09
乙。アセンブリでシェーダ書いてるあたりがプロ臭い。
241:デフォルトの名無しさん
06/03/32 20:49:58
プロならコードを出すわけがない。
著作権は自分にないからな。
242:デフォルトの名無しさん
06/03/32 20:53:22
普通にアプロダにあげてくれないか？
243:デフォルトの名無しさん
06/03/32 21:08:06
おまえらuudecodeもできないの？
俺はLinuxだから標準でできるけどコンパイルはできないというふざけた奴だ。
244:デフォルトの名無しさん
06/04/02 00:48:55
乙。
D3DTSS_TEXCOORDINDEXにハマったが、ようやく2つのテクスチャを足せるようになった。
俺のグラボじゃPixelShader1.xだし8bitしか対応してない。ちっ。
245:デフォルトの名無しさん
06/04/22 04:42:08
おまえらもしかしてコレ↓で十分だったのか？
URLﾘﾝｸ(www.gpgpu.org)
散々叩いといてさ。
どーでもいいけど PS3 か 360 の仕事くれ。安くてもいいから。
ＤＳはもう飽きた。仕事が来ても倍の人月でふっかける。
246:デフォルトの名無しさん
06/04/23 23:24:33
brook良さげですよ。環境構築が面倒ですが。。
URLﾘﾝｸ(gpgpu.jp)
247:デフォルトの名無しさん
06/04/24 01:00:04
Linuxで開発する方法教えてください。
Windowsってキモクて真で欲しいのでお願いします
248:デフォルトの名無しさん
06/04/24 01:52:02
Linuxでコンパイルする。
それだけ。OpenGL系ならそれでいいじゃん
249:デフォルトの名無しさん
06/04/24 08:47:21
>>247
glut 使ってコーディングできるなら
URLﾘﾝｸ(www.gpgpu.org)
へ池。
それができないなら
くだすれOpenGL（超初心者用）
ｽﾚﾘﾝｸ(tech板)l50
OpenGLスレ Part10
ｽﾚﾘﾝｸ(tech板)l50
あたりへ行け。
250:デフォルトの名無しさん
06/04/24 15:14:53
>>246
アラッ、いいページですね
参考になりました
251:デフォルトの名無しさん
06/04/25 01:44:54
brookコンパイルしたいLinuxでしたいです。
Windowsはきもくて嫌ですお願いします
252:デフォルトの名無しさん
06/04/25 22:38:48
>>251
つ URLﾘﾝｸ(www.gpgpu.org)
253:デフォルトの名無しさん
06/05/09 02:04:36
ﾓｼﾞﾚﾂｦｱﾂｶｲﾀｲ
254:デフォルトの名無しさん
06/05/11 00:56:38
１文字１文字をfloatにするとか？
いずれにしろどう処理したいかによるか。
255:デフォルトの名無しさん
06/05/11 01:50:32
60ＧＢのデータをソートするのに90MB/secって遅すぎだろ
大して速くないよなＧＰＧＰＵ
256:デフォルトの名無しさん
06/05/11 02:13:37
文字列処理ライブラリを作りたいのか？
それとも探してるのか？
257:デフォルトの名無しさん
06/05/11 02:14:21
文字列処理ライブラリを作りたい ＹＹＹＹＹＹＹＹＹＹＹＹ
探している ＮＮＮＮＮＮＮＮＮＮＮ
という感じです。最近徹夜でテンションがＡＧＥＡＧＥです
258:デフォルトの名無しさん
06/05/11 12:00:41
基本的には複数の文字列に対して一斉に同じ関数を適用することしかできないがそれでいいのか？
（コマンドリストを作るとかもできなくはないが）
シェーダアレイ内で一番遅いピクセルに律速されるのでばらつきが大きいデータはパフォーマンスが出ないがいいか？
DirectX のシェーダアセンブラしか知らない俺でよければ手伝えるかもしれないが。
259:デフォルトの名無しさん
06/05/12 01:16:26
うーん、ちょっとまだ解ってないこと山積みだけど
あるデータないから、特定のデータを探すとかができればいいですよね
たとえば特定の方法で解析すると意味ができるようなものとか
ツリー構造のデータ
線形リストデータ
そんな感じのデータを検索したりすることができないかと考えていろいろ調べてはいますが結果はいまだ０
260:デフォルトの名無しさん
06/05/12 01:46:29
>>259
strchr ならできるが、フェッチ量を考えるとかなり具合が悪い気がするな。
同様に正規表現検索なんかも、DFA にしたのをシェーダ言語にコンバートできそうな気もするが、汎用 CPU みたいな気合入ったキャッシュ機構がないと具合が悪そう。
ツリーやリストはまだなんとかなりそうかな。
つーか、いろいろ調べてるなら、アセンブラしか使えない俺は用無しか。
261:デフォルトの名無しさん
06/05/12 01:56:44
アセンブラでもいいんですけど、何せ効率が悪いので
できれば、C++からインラインで留めておきたいと考えてます
262:デフォルトの名無しさん
06/06/16 08:52:22
GPUとCPUで、得意不得意な処理があると聞きます。
GPUが得意な処理はCPUの何倍も高速に処理できると聞きましたが
具体的にはGPUが得意な処理と言うのはどういったものなのでしょうか？
動画のエンコードやデコード、ファイルの圧縮・解凍や、ハッシュ生成や暗号化などが高速なのでしょうか？
263:デフォルトの名無しさん
06/06/16 11:58:05
依存性の少ないストリームデータを横に並べてベコベコ叩くような処理が得意です。
264:デフォルトの名無しさん
06/06/16 18:49:30
ぶはは、馬鹿ばっか（核爆）
265:デフォルトの名無しさん
06/06/16 19:03:32
自称研究者の単なる情報収集家とかいるしなｗ
266:デフォルトの名無しさん
06/06/16 21:13:46
日本の大学でgpgpu系の研究室って有りますか
267:デフォルトの名無しさん
06/06/16 21:30:24
>>266
無い。日本の研究者連中はどいつもこいつも馬鹿。
素直に欧米の大学行け。
268:デフォルトの名無しさん
06/06/16 22:10:31
別にGPGPUの研究してないから馬鹿ってわけでもないと思うが・・・
むしろ、GPGPUの研究してるようなやつの方が有る意味馬鹿に見える。
もちろんこの場合の馬鹿は、変態的な手段で目的を達する事に喜びを得る馬鹿って意味だけどな。
269:デフォルトの名無しさん
06/06/16 22:31:22
GPGPUﾊｧﾊｧ…
270:デフォルトの名無しさん
06/06/20 16:41:54
こと半導体に関しては、大学よりも企業の研究所のほうがレベル上なんじゃないの？
271:デフォルトの名無しさん
06/06/21 00:17:43
>>270
誤爆？
272:270
06/06/21 09:49:22
>>271
誤爆じゃねって
ぶっちゃけどーなの？
273:デフォルトの名無しさん
06/06/21 11:34:09
>>270
GPGPUは半導体プロセスよりも情報処理の方が分野が近いとおもふ
274:デフォルトの名無しさん
06/06/22 09:55:34
いいたいことはわかる。
ハードウェアアーキテクチャ屋ね
275:デフォルトの名無しさん
06/06/22 12:18:19
一時はもてはやされてたが、今どーなんだ？
どんなに素晴らしいアイディアでも普及しなきゃ意味ないからなぁ
276:デフォルトの名無しさん
06/06/22 15:49:36
誰かGPUをC++から扱う事が出来るクラスライブラリのSh使ったことある？
関連書籍も無いし、途方にくれてる・・・orz
277:デフォルトの名無しさん
06/06/22 16:02:07
ぐぷぐぷ
278:デフォルトの名無しさん
06/06/22 16:24:42
>>277
俺もスレタイ見てそう読んだ
279:デフォルトの名無しさん
06/06/23 02:33:40
>>275
普及ってお前、どのレベルで言ってんの？ HPC が必要な分野なんてそうないだろ。
マジレスついでに言っておくと、ゲームでよく使われてるよ。
280:デフォルトの名無しさん
06/06/23 21:07:00
URLﾘﾝｸ(www.geocities.jp)
皆さんの参考になりませんか？俺が書いた訳じゃないけど。
281:デフォルトの名無しさん
06/06/24 02:40:17
>>280
続きが見たい。
282:デフォルトの名無しさん
06/06/24 13:33:19
情報処理学会あたりで検索かけると何件かネタが見つかる
URLﾘﾝｸ(www.bookpark.ne.jp)
著者なり研究室なりをたどれば少しは情報が出てくるんじゃなかろうか
283:デフォルトの名無しさん
06/08/03 08:48:51
あげてみる
284:デフォルトの名無しさん
06/08/03 20:15:00
GPGPUはれいめい期なの？
参考書籍はないの？
285:デフォルトの名無しさん
06/08/04 18:49:12
GPUはあと3年もすればコプロセッサという名前になります。
286:デフォルトの名無しさん
06/08/04 19:35:23
AMDにそんな業界を作り変える力は無いぞｗ
287:デフォルトの名無しさん
06/08/04 22:00:29
intelとnVidiaはどうするんだろう？
288:デフォルトの名無しさん
06/08/05 02:36:55
Intelは業界１位のグラフィックスチップメーカー＆CPUメーカー
nVIDIAは業界１位の単体グラフィックスチップメーカー
AMDは、グラフィックスチップ部門を持たないメーカー＆２位のCPUメーカー
ATiは、業界２位の単体グラフィックスチップメーカー
どう考えても、AMDとATiが組んだところでそんな業界の仕組みを変えれるとは思えない。
２位同士が組んでどうやって１位同士が確立しているシステムを潰すってんだ。
289:デフォルトの名無しさん
06/08/05 20:00:12
最終的にはIntelがそういう流れを決定付ける。
290:デフォルトの名無しさん
06/08/15 22:50:30
まあな
291:デフォルトの名無しさん
06/08/16 02:06:00
GPGPUで動画のエンコードとか聞いたけどさ
そういう前後の依存関係が関係する処理ってGPUで出来るの？
一旦、処理した内容をメインメモリに戻して、その結果を元に次の処理って事をしないといけないと思うんだけど・・・。
292:デフォルトの名無しさん
06/08/16 02:51:53
動画圧縮における「前後フレームとの依存関係」と
アルゴリズムにおける「データの依存関係」は違う。
293:デフォルトの名無しさん
06/08/27 04:43:49
GPGPU的Hello Worldとして何から手をつければいい？
ちなみに現時点でGPGPUについては概要しか知らないんだが。
294:デフォルトの名無しさん
06/08/27 07:27:52
ハロワルは視覚的にわかるものが好ましいから
適当なテクスチャデータ→GPU→ピクセルズーム→メインメモリ→BMP出力
こんな感じでどうよ？
295:デフォルトの名無しさん
06/08/27 15:29:09
>>293
URLﾘﾝｸ(www.gpgpu.org)
URLﾘﾝｸ(www.gpgpu.org)
このスレで Hello World の話題が出たことあるんだから、それを踏まえた上での質問をして欲しいものだが。
296:デフォルトの名無しさん
06/08/27 18:12:14
ATIのGPUがFolding@homeに参戦
URLﾘﾝｸ(slashdot.jp)
こういうのが本命かな
297:デフォルトの名無しさん
06/09/09 15:59:23
URLﾘﾝｸ(channel9.msdn.com)
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..
298:デフォルトの名無しさん
06/09/10 01:35:24
>>297
ぱっと見ではプログラム中の一部の処理をピクセルシェーダに置き換えられるようにしただけに見えるんだが
どうも要領を得ないので読み直すか
299:デフォルトの名無しさん
06/09/11 00:48:37
URLﾘﾝｸ(www.shader.jp)
300:デフォルトの名無しさん
06/09/20 11:11:02
URLﾘﾝｸ(www.gpgpu.org)
が見えないんだけど、どうしちゃったんだろ？
301:デフォルトの名無しさん
06/09/26 19:47:06
URLﾘﾝｸ(journal.mycom.co.jp)
DX10では今までと比べ物にならんほど汎用性が増すみたいだね。
302:デフォルトの名無しさん
06/09/28 22:51:28
浮動小数点数のバッファに1.0より大きな値を記録する事は出来ないのでしょうか。
試してみたら1.0で飽和されてしまって。
303:デフォルトの名無しさん
06/09/29 08:49:41
シェーダー言語使ってるかどうかとか、情報少なすぎ。
どっかで8bitとかのフォーマットに変換されてたりするんじゃないか？
304:302
06/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で飽和しているという印象を受けました。
305:302
06/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枚のテクスチャを加算するピクセルシェーダのコードはこれで間違いないでしょうか。
306:デフォルトの名無しさん
06/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 のコードは合ってる。
307:デフォルトの名無しさん
06/11/09 19:24:06
URLﾘﾝｸ(pc.watch.impress.co.jp)
308:デフォルトの名無しさん
06/11/11 08:31:59
>>307
これで、おれのようなへっぽこコード書きでも使えるようになった。
309:デフォルトの名無しさん
06/11/11 12:33:04
Geforce8800GTXのSLIで1TFlopsが30万円くらいだしすげーよな。
はやく開発環境ほすぃ
310:デフォルトの名無しさん
06/11/11 15:54:43
ここまでくると、もうGPGPUとは呼べないよね。
311:デフォルトの名無しさん
06/11/11 17:01:11
今までシェーダーでやってた人が馬鹿みたい
メモリー周りはどうなってるのかな？
312:デフォルトの名無しさん
06/11/11 17:11:54
そんなことよりもなぁ、演算プロセッサボードで作ってた連中が不憫で不憫でw
313:デフォルトの名無しさん
06/11/11 17:14:11
あーもう要らないね、GPU内で全部計算できるし、転送しなくてすむし。
グラフィック以外の計算にも使えそうなキガスルがどうだろう。
314:デフォルトの名無しさん
06/11/11 17:17:43
>>313
フーリエ変換に使えないか、調査予定。巧くすれば、プロセッサボード屋に払う分をこっちの仕事にできそうな希ガス。
315:デフォルトの名無しさん
06/11/11 18:13:55
GPU内でDSP的でない処理がモリモリできるのであれば、
メインメモリとの転送量も少なくできるかな。
もしそうなら、x16じゃなくてx1レーンに沢山のっけてもいいかも。
できるかどうか知らんけど妄想。
316:デフォルトの名無しさん
06/11/12 18:44:29
Cで扱えるようになるっていうのは、ハードウェア的な新機能なの？
旧型のGPUも、ドライバーで扱えるようになるのかな？
317:デフォルトの名無しさん
06/11/12 19:10:51
GPUのアーキテクチャーが大きく変わったことでCでプログラミングできるような
構造となった。だからコンパイラー付き
よって旧型チップじゃ使えないよ。
318:デフォルトの名無しさん
06/11/12 20:08:45
なるほど・・・、THX
ドライバ側っつーか、ライブラリ側でかなーり頑張れば旧GPUも対応出来そうな感じもするんだけどなぁ。
もちろんパフォーマンス的なものが変わってくるだろうけど。
319:デフォルトの名無しさん
06/11/12 20:36:07
無理。
320:デフォルトの名無しさん
06/11/12 20:54:48
これってやっぱ単精度なんだよね？
321:デフォルトの名無しさん
06/11/13 14:13:59
ちゃんと嫁よ
プロセッサ内蔵してそこが実行してるんだから旧も新もあるか。
322:デフォルトの名無しさん
06/11/14 23:08:50
>>320
（独自）Cコンパイラ使えます
けどdouble使えません
単精度浮動小数演算器に桁上げ回路？くっつけて
できないのかねぇ？
ソフト的にやったら性能ガタ落ちだろうし。
323:デフォルトの名無しさん
06/11/14 23:37:33
URLﾘﾝｸ(www.4gamer.net)
CUDAの詳細どぞ。
324:デフォルトの名無しさん
06/11/15 10:26:20
ほんと今までグラフィック屋さんでもないのにCgいじくってひーひー言ってたのがｳﾞｧｶみたい…
まぁ、8800は素直にすげーと思うけど
325:デフォルトの名無しさん
06/11/15 11:06:38
これもGPGPUですか？
URLﾘﾝｸ(www.itmedia.co.jp)
326:デフォルトの名無しさん
06/11/15 19:37:40
ソフトウェアレンダとハードウェアレンダの境目が取っぱらわれるわけでもないのかな?
とりあえずこの傾向が進めば、GPUの扱いは
Cバス用のPC-9801-16に乗ったMC68kみたいになるわけだな。
327:デフォルトの名無しさん
06/11/15 20:08:42
ソフトレンダはdoubleで計算してるからねぇ。
floatでレイトレったらすごい結果になるしｗ
328:デフォルトの名無しさん
06/11/17 18:17:32
Mpegのエンコードにおける、動きベクトルの算出に
GPUが使えたらと考えています。
参考になるようなサイト等ありましたら教えてください。
329:デフォルトの名無しさん
06/11/28 04:54:51
GPGPUなMP3エンコーダー作ってください
330:デフォルトの名無しさん
06/11/29 08:20:07
URLﾘﾝｸ(www.kvraudio.com)
こんなのきたよ
GPGPUでサウンド用DSP的なことをやるみたい。
この場合はDelayだけだけどｗ
331:デフォルトの名無しさん
06/11/29 10:23:22
オフセットしてaddするだけやん！
332:デフォルトの名無しさん
06/11/29 13:11:45
CUDAがでてきたから来年にはGPGPUの状況も変わるかもね。
333:デフォルトの名無しさん
06/12/06 00:15:51
うちの大学で、GPUでレイトレやってる人がいる・・・・
334:デフォルトの名無しさん
06/12/06 21:37:13
レイトレなんて久しぶりに聞いた単語だ。
335:デフォルトの名無しさん
06/12/06 23:46:12
>>333
一昨年俺がやったぜ
GeForce6シリーズなら十分
SM2.0だとループができないから
6800GT初売りに予約して買った。
研究費だけどね。
今だと、海外もボコスカ論文出てるから
新規性アピールするのむずいかな。
あ、研究とは言ってないのか
336:デフォルトの名無しさん
06/12/07 13:15:17
ごめん、GPUじゃなくて、PPUっぽい・・・
337:デフォルトの名無しさん
06/12/07 14:57:30
GPUPPURか
URLﾘﾝｸ(d.hatena.ne.jp)
最近進捗ないけどどうなんだろうね。
338:デフォルトの名無しさん
06/12/07 23:02:24
ファミコンのPPUを演算に使うのは難しそうだけどな。
339:デフォルトの名無しさん
06/12/11 00:54:33
ソフト的に倍精度の研究やってる俺がきました
2007年後半にハード的に実装されるみたいですねー
340:デフォルトの名無しさん
06/12/11 21:46:48
>>337
レイトレーシングでStanford bunnyとかレンダリングできるけど、遅い。
341:デフォルトの名無しさん
06/12/12 00:59:27
>>339
あの，大変申しにくいのですが
今年のSIGGRAPHのポスターでドンピシャなのが…
Extended-Precision Floating-Point Numbers for GPU Computation
URLﾘﾝｸ(cs.allegheny.edu)
悪気はないんです，担当教官から言われるよりはよっほどマシだと思いますし．
頑張ってください
342:デフォルトの名無しさん
06/12/12 01:36:50
>>342
俺ｵﾜﾀ＼(＾o＾)／
343:デフォルトの名無しさん
06/12/12 01:48:58
読んできました。
難しい内容じゃないし誰かがやっててもおかしくないですよね
近々中間発表があるのでそれまでになんとかしないと・・・
情報提供ありがとうございましたm(_ _)m
344:デフォルトの名無しさん
07/01/14 22:05:03
すみませんお聞きしたいことが
nvidiaのCg言語はATIのチップ上でも動くのでしょうか？
GPUプログラミングをやってみたいと思っているのですが
手持ちがATIしかなくて
345:デフォルトの名無しさん
07/01/15 20:05:39
>>344
ATIのチップでやったことないけど、できたと思う。
NVIDIA SDKでも落としてサンプルを走らせてみたらいいと思うよ
346:デフォルトの名無しさん
07/01/16 01:49:39
>>345
ありがとうございます。試してみますー
347:デフォルトの名無しさん
07/02/20 09:13:53
CUDA使ってる人居ません？
興味があって、GF88GTSのメモリが少ないやつを無理して買ってきたんですけど
コンパイラが手に入らない・・・orz
もしかして、ベータテスターや関係者じゃないと、まだ配ってもらえない？
348:デフォルトの名無しさん
07/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.
って書いてあるけど。
349:デフォルトの名無しさん
07/02/20 10:24:16
GPUで汎用コンピューティングを行うスレ
ｽﾚﾘﾝｸ(tech板:16番)
URLﾘﾝｸ(developer.nvidia.com)
350:デフォルトの名無しさん
07/02/20 15:34:52
>>347
お、動いたら感想よろしく。
351:デフォルトの名無しさん
07/02/20 17:10:05
昨日か一昨日くらいにCUDAコンパイラのパブリックベータが始まった。
誰でも落とせるようになったはず
352:347
07/02/21 12:08:21
情報THXです！
でも、うちx64のVistaマシンなので…orz
まだ開発環境は32bit版しか出てないみたいで、ドライバに強く依存するらしく32bitアプリ側からは64bitドライバが見えないようです。
ドライバが入ってないというメッセージが出て、インストールすら出来ない…orz
早く64bitバージョンでませんかねぇ・・・。
353:デフォルトの名無しさん
07/02/21 13:34:37
>>352
英語版のnVIDIAのサイトからGO!
日本語版のサイトのvistaドライバのページは何故かNot Fount
多分最新のドライバ入れれば、有効になると思われ。
Vistaでは試してないけど、XPのx64でCUDA SDKは使えたから・・・(ただしグラボがGF66なのでインストールしただけｗ)
354:デフォルトの名無しさん
07/02/21 14:51:53
Supports Linux and Windows XP operating systems
とかいてあるからVistaはまだ無理なのかも
355:デフォルトの名無しさん
07/02/21 14:54:32
NVIDIA CUDA Homepage
URLﾘﾝｸ(developer.nvidia.com)
356:デフォルトの名無しさん
07/02/22 11:02:37
Vistaまだっぽいな。。
357:デフォルトの名無しさん
07/02/24 22:27:08
とりあえず動かしてみたいけどG80廉価版待ち
358:デフォルトの名無しさん
07/02/25 13:00:56
初歩的な質問です。
GPGPUにチャレンジしてみようと思い、BrookGPUを使ってるんですが
ループの並列化がイマイチどのようにすればいいかがわかりません。
例えば、ループの部分で前回回した処理結果に加算を行う処理をする場合
前後関係が出てくるので、GPGPUに適した並列化は出来ないと思うのですが、こういうのは何か解決方法があるのでしょうか？
359:デフォルトの名無しさん
07/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に向かない。
360:デフォルトの名無しさん
07/02/25 14:15:44
>>358
依存関係がなくなるように計算式を変更するか、
並列させる方向を変えるような工夫が必要。
でもって、そういう工夫は実はSSEを使ったベクタ化やOpenMPによる並列化にも適しているので、
ますますGPUを使うメリットが活き難くなる罠。
361:デフォルトの名無しさん
07/02/25 18:34:02
並列計算はいいんだけど
計算の中間結果を保持する為の
テンポラリバッファが大きくなって
すぐ頭打ちになりそうなイメージ
362:デフォルトの名無しさん
07/02/25 21:41:38
演算精度が悪すぎて使い物にならない印象しかないんだが…。
363:デフォルトの名無しさん
07/02/25 22:13:06
明日G80にダイブしてみるよ！
飽きたら速攻で売り払わないと
364:デフォルトの名無しさん
07/02/25 23:03:53
>>362
URLﾘﾝｸ(mypage.odn.ne.jp)
もうじき倍精度サポート
現状でも型としてはサポートしてるからコーディングは可能
365:デフォルトの名無しさん
07/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には向かないってこと？
366:デフォルトの名無しさん
07/02/26 22:15:27
その処理は、コンパイラが優秀ならばCPUでもGPUでも
まあまあ効率よく実行されそうだが。
367:デフォルトの名無しさん
07/02/26 23:57:20
>>365
その処理は問題ない。むしろ超得意なくらい。
368:デフォルトの名無しさん
07/02/26 23:58:42
>>365
それは前後の処理結果は関係ないでしょ。
imgに代入するならともかく、imgと言うデータがあらかじめあるのなら、そのままVRAMに転送すりゃいいわけだし。
369:デフォルトの名無しさん
07/02/27 12:16:50
>>365 を Cg で書くとどんな感じ？
370:デフォルトの名無しさん
07/02/27 12:25:46
今はCgよりCUDAの方が。。。
まぁ古いGPU(俺を含めて)の人には仕方ないが。
371:デフォルトの名無しさん
07/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の内容を開放する関数は無いのかな？
372:デフォルトの名無しさん
07/02/27 14:02:44
じゃあCUDAで書くとどうなるの？
373:デフォルトの名無しさん
07/02/27 14:32:25
>>371
手抜きするなーｗ
外側のループもはずせるだろ。
いや、面倒だから俺はやらないけどなｗ
VRAMは自動開放だからな…、俺もよくフリーズさせてしまう。正確にはフリーズじゃなくて単に低速化するだけなんだろうけど
プロセスも殺せなくなるのが嫌だな
374:デフォルトの名無しさん
07/02/28 01:06:47
Brookでやるからだよ。
頑張って自分でCgとか使ってゴリゴリ動的にメモリを管理するんだ。
って言うか、あれは隠蔽されすぎてて何やってるのかわからんし、パフォーマンスが出るような組み方ができないので
遅すぎる。BrookGPU使ってCPU処理より速い処理ってかけるの？どう頑張ってもReadBackである意味速度差がつけられちゃうよ。
375:デフォルトの名無しさん
07/02/28 01:17:19
何度見てもスレタイをゲプゲップと読んでしまう
376:デフォルトの名無しさん
07/02/28 02:16:30
ぐぷぐぷってよんでる
377:デフォルトの名無しさん
07/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でやる場合、どういう風にすればいいのでしょうか？
378:デフォルトの名無しさん
07/02/28 05:24:56
あ、ｽﾏｿ
単純ミス。。。
GPU側にfloatで値を渡してたから、2重に変換されてた・・・
379:デフォルトの名無しさん
07/02/28 14:07:17
GPUにint型をfloatで送っちゃった時点で、桁落ち発生するでしょ。
380:デフォルトの名無しさん
07/02/28 15:29:00
桁落ちするの？
381:デフォルトの名無しさん
07/02/28 21:34:28
assert((float)0x7FFFFFFF != (float)0x7FFFFFFE);
382:デフォルトの名無しさん
07/02/28 22:11:09
Brookもint型が扱えればな…。
floatとintだと、個人的にはfloatの方が高度なものだと思うんだけど
なんで、float扱えて、int型が扱えないのかなぁ・・・
383:デフォルトの名無しさん
07/02/28 22:47:15
>>377
キャストしてGPU側に送って、GPU側で更にint型にキャストじゃ駄目なん？
って、GPGPUの言語名に使ってるかわからんけど、大抵intは無理なんかな
384:デフォルトの名無しさん
07/03/01 16:20:02
ところで、おまいらAMDのフュージョンは期待してますか？
385:デフォルトの名無しさん
07/03/01 16:29:50
AMDはコンパイラが期待出来ないから駄目
ここは嫌でもIntelやnVIDIAと共同で第3機関を作り、命令セットの仕様を管理させた方が良い。
じゃなきゃ3D NOWの二の舞さ。
どうせIntelもGPUコアとの統合を考えてるんだろ？
そうなった場合、どうせどこかで命令セットが共通化するんだから(しなかったら終わってる)
最初からそういう機関を作っとけよ。
386:デフォルトの名無しさん
07/03/01 17:39:38
そうなるよりチップセットにプログラマブル演算機能があった方がいいな。
メインメモリへ近いしCPUである程度処理して
並列化できる処理ではCPUがそのメモリアドレスを投げて
結果をCPUに戻すかGPUなどのバスに転送させる。
定数時間で出来る処理ならメモリ転送の代わりにできる。
387:デフォルトの名無しさん
07/03/01 17:45:11
チップセットにCPUくっつけたらいいんじゃね？
388:デフォルトの名無しさん
07/03/01 17:51:27
>>387
すでにAMDのCPUはメモリに直接つながってるからその状態では。
389:デフォルトの名無しさん
07/03/02 00:22:20
>>385
> じゃなきゃ3D NOWの二の舞さ。
AMD64はよくがんばったと思わないか?
390:デフォルトの名無しさん
07/03/02 00:29:55
あれは先にIA64が大コケして自爆しただけ。
391:デフォルトの名無しさん
07/03/02 00:48:26
IA-64はよくｶﾞﾝｶﾞｯﾃﾙお
Itanium2プロセッサベースのサーバ上で動作するアプリケーションの数が1万種類を超えた
URLﾘﾝｸ(www.itmedia.co.jp)
Itaniumベースのサーバが急成長を続けており71.5%成長で11億ドル市場
URLﾘﾝｸ(journal.mycom.co.jp)
Itanium搭載サーバ、売上ベースのシェアが国内RISCサーバの6割相当に拡大
URLﾘﾝｸ(www.rbbtoday.com)
Montecito搭載、HP Integrity SuperdomeがTPC-Cで世界記録
URLﾘﾝｸ(www.tpc.org)
392:デフォルトの名無しさん
07/03/02 01:12:33
>>389
あれは殆どマイクロソフト主導じゃん
ＭＳの戦うプログラマの人がAMD64自体の開発に関わってたし
後は、あれはあくまでx86命令の拡張で、今までのCPUの延長線上のものだが
今回のフュージョンは、アーキ的には全然比べ物にならないくらいの大改造だから…
393:デフォルトの名無しさん
07/03/03 03:45:34
CPUコアに統合されれば、GPGPUの最大の問題点であるReadBackの遅さが解決するな。
そもそも、CPUの命令に自然に溶け込む形みたいなので、GPGPUとか意識せずとも、勝手にコンパイラがやってくれそうな気もする。
394:デフォルトの名無しさん
07/03/04 00:53:22
粒度はどんなのになるんだ？
現行GPUでいうところ quad とか batch とかにあたるもの。
395:デフォルトの名無しさん
07/03/04 01:06:43
自分でループ展開して並列化して、各GPUをプログラマに管理させたりしてｗ
まぁ、コンパイラが勝手にやってくれるんじゃないかな。
それ以外の場所は、一般的なクラスタリングシステムみたいにやってくれるって事はないと思われ
そういうことは研究されてるけど、まだまだ一般的なコンパイラ1発でやってくれる仕組みは完成しているとは言いがたい。
最適な粒度をコンパイル時に調べてくれるとかやっても、別環境で実行する場合変わるしなぁ。
396:デフォルトの名無しさん
07/03/04 12:47:40
いや、俺が知りたいのは、それぞれのユニットがプログラムカウンタを持つのか、コプロセッサ命令でシェーダアレイコントローラに命令するのか、ということなんだ。
全部のユニットにプログラムカウンタがあったら、そりゃサブプロセッサが沢山載ったマルチコアでしかないじゃん。
コプロセッサ命令になるにしても、拡張命令で１度に１つのユニットに１命令送るだけじゃ意味ないから、適当なグルーピングが必要だと思うんだけど。
x86ISAの拡張ってんだから、後者ではあるんだろう。
で、その粒度はどんなのになるんだろうな、と。
>395 の話題も面白そうだけど、他のプロセスなりスレッドとのユニットの取り合いとかも考えるとやってらんないね。
397:デフォルトの名無しさん
07/03/04 15:14:04
偉そうな口調で頓珍漢な事言ってる人は、出て行って欲しい。
んがぁ、無理なんだよね。
ひろぽんは、殺伐とした方が情報の濃度が上がるとか言うけど、
白痴や馬鹿が沢山いるのに、そりゃああり得ない話。
頓珍漢なこと言ってると理解出来るレベルの人にとっては、
その情報って情報価値を持たない情報だったりするし。
398:デフォルトの名無しさん
07/03/04 15:27:13
日本語でおｋ
399:デフォルトの名無しさん
07/03/04 15:28:36
ウォッカはストロワヤが一番。やっぱりウォッカはロシアだね。
スレ違いスマソ。
自分の、これはダメかもわからんねは、
バイクで50キロぐらいで2車線目を走っていた。
するといいきなり目の前に1車線目に止まっていた車が右に、
フルブレーキするまもなく追突（前輪あたり）
10m程飛ばされて頭、ほんとにてっぺんからアスファルトに直撃。
その瞬間首が変な方向に、ぐにっとなった時。
結果は頭を支点にそのまま背中をまたアスファルトに直撃。
シボンヌ・・・、と思ったら生きてる。
その瞬間、車に腹が立って立ち上がり走っていってボンネットの上に飛び乗った。
運転手ポカーン、
んで警察に行って、病院行って、CT撮って診察の時。
他に痛い所は？と先生。
タンクで金タマ打って少し痛い。と言うと
顔色を変えてそれはいかんな、チョット見せて
（看護婦ちょっとはにかんだ様な顔でカーテンを引く）
先生、漏れの金玉をうねうねコロコロして。
ん～、大丈夫でしょう。しばらくすると痛みも引きます。
と言いながらカルテにカキコしてるのを見ると
睾丸hit
これはだめかもわからんね・・・
400:デフォルトの名無しさん
07/03/04 15:58:53
朝鮮語でおｋ
401:デフォルトの名無しさん
07/03/04 22:07:30
>>397
流れ的に俺のことなんだろうが、フロントエンドにしか興味ないのか？
402:デフォルトの名無しさん
07/03/04 22:14:46
ネットワークのスレとかにも現れる
「おまえらバカばっかりだな」系の人だろ
もちろん具体的な議論はしません
403:デフォルトの名無しさん
07/03/05 15:18:23
>>401
何処の人か分からないけど、ごめん。
イント、フロートでごちゃごちゃ言ってた人のこと。
404:デフォルトの名無しさん
07/03/05 18:45:01
それも多すぎてわからん。
405:デフォルトの名無しさん
07/03/05 23:09:11
【キーワード抽出】
対象スレ： GPGPU
キーワード： イント
403 名前：デフォルトの名無しさん[sage] 投稿日：2007/03/05(月) 15:18:23
>>401
何処の人か分からないけど、ごめん。
イント、フロートでごちゃごちゃ言ってた人のこと。
抽出レス数：1
406:デフォルトの名無しさん
07/03/05 23:32:35
イント人もびっくり
407:未来人
07/03/07 16:29:31
GPUってCPUに取り込まれて無くなってたよ。
CPUは、FPUとSPUとGPUで構成されてたよ。
408:デフォルトの名無しさん
07/03/07 20:51:05
>>396
「何時の時代の人だ（と言ってもたかだか数年前だが・・）」的な
ことを今更「俺が知りたいのは」とか書くから荒れる。勉強しろ。
409:デフォルトの名無しさん
07/03/08 01:13:12
>>408
url か検索ワードくらい教えてくれ。
英語でなんて表現したらたどり着くのか見当も付かん。
410:デフォルトの名無しさん
07/03/08 03:00:48
【Penryn】次世代モバイルCPU雑談ｽﾚ 3【Nehalem】
ｈｽﾚﾘﾝｸ(notepc板:537番)
537 名前：[Fn]＋[名無しさん][sage] 投稿日：2007/03/07(水) 17:10:43 ID:o4rB4JJN
GPUだからコプロセッサではない。
同様にデュアルコアだからデュアルCPUではない。
たしかに正しい。
でもこの視野の狭さがアホな言動につながるのです。
プログラムから見るとどう見える?
概念レベルではどう見える?
そんな視点は一切ない。
411:デフォルトの名無しさん
07/03/08 05:54:39
GPGPUの研究発表を聞いた
CPUのみに比べて若干早くなっている程度
たぶんプログラミングレベルが低いのもあるんだろう
コストパフォーマンスについて聞いたら
「将来的には」を連発してた
CPUよりコストパフォーマンスの伸びが良い予定らしい
412:デフォルトの名無しさん
07/03/08 06:29:53
だってさ、1度でもGPGPUでコーディングした人ならわかるでしょ。
GPUを活かせる箇所が少ない事に…。
GPUといえども、1つあたりのストリームプロセッサの能力はCPUに比べて鼻くそだし、ReadBackのコストも馬鹿みたいにかかるんだから
並列化できなけりゃ意味がない・・・。そんな都合の良いループ部分が現状のコードや計算式見てそんなにあるか？
413:411
07/03/08 06:57:00
早起きなのか徹夜かどうかはさておき、さっそくどうも。
うちのソースは機械系で有限要素的なので割とあるんだな。
PS2の時に1GFlops程度出たけどP4のSSEにトータルで負けた。
CellとGPGPUは期待してるけど過剰期待は禁物だと思ってる。
いちおうGeForce8800買ってみるよ。
Cellはソフト作る気にもならないのでライブラリ充実待ち。
414:デフォルトの名無しさん
07/03/08 07:33:26
私のところも並列できる応用は色々ある。
実際、ClearSpeedやXTrillionのようなアクセサレータボードで速度が出ている。
それらに較べれば、コストはGPGPUなら桁違いに掛からないわけで。
#CELLも評価対象になってるけどね。
415:デフォルトの名無しさん
07/03/08 09:02:04
ムダ毛対策にもGPUによる並列処理が効果的らしい。
416:デフォルトの名無しさん
07/03/08 11:01:34
>>415
全身大やけどしました
417:デフォルトの名無しさん
07/03/21 18:20:19
>>412
動画のエンコードだと1つのキーフレームを1つのストリームプロセッサに
担当させることによって、簡単に並列化できる。
418:デフォルトの名無しさん
07/03/22 17:50:05
標準的なグラボは
VRAM128M
ストリームプロセッサは64基
１コアあたり2Mしか使えん。(それ以前に128M丸々使えるわけが無い)
丸々割り当てるのは辛いんじゃないか？
419:デフォルトの名無しさん
07/03/23 02:50:52
メモリ容量は768MBを想定してたから確かに128Mの場合は辛いなぁ。
GPU側のメモリを使いきるごとにCPU側のメモリに渡すというやり方で
なんとかなりそうな気はするけど。
420:デフォルトの名無しさん
07/03/23 03:07:17
完全にCUDA世代のグラボ前提の話になってるな
まだ遠い話だ・・・
421:デフォルトの名無しさん
07/03/23 07:20:12
URLﾘﾝｸ(fah-web.stanford.edu)
GPGPU遅いとかいうのはnVIDIAのG7x前提だからだったんだね・・・
ATIのR580速いや・・・
Cellの倍の実パフォーマンス・・・
1台あたりは
PS3 30GFLOPS
GPU 60GFLOPS
422:デフォルトの名無しさん
07/03/23 10:07:36
そのCellもフルパワー出てるかわからないけどね
423:デフォルトの名無しさん
07/03/23 10:43:06
>>421
俺、G7xに限らず、G80でも試したが、結果は似たようなもんだったぞ。
ぶっちゃけGPGPUは、もはや言葉だけが先行した流行りモノに過ぎない気が・・・
実際、BrookGPUとか使えばC使える人なら簡単にGPGPU出来るようになったのに
誰も使ってないし、使ってる人は割りと失望してる人が多い・・・
424:デフォルトの名無しさん
07/03/23 12:59:13
G80持ってる人ここのヤツ試してくれん
URLﾘﾝｸ(gpgpu.jp)
URLﾘﾝｸ(gpgpu.up.seesaa.net)
URLﾘﾝｸ(gpgpu.up.seesaa.net)
姫野ベンチ その２
URLﾘﾝｸ(gpgpu.jp)
brookbench ver.0.01
URLﾘﾝｸ(gpgpu.jp)
G80とG7xでそんなに違わないって>>423の発言が気になる。
G70とRV530で十倍近い差有るし・・
じつは、G80もG70同様遅いのかな？
425:デフォルトの名無しさん
07/03/23 13:31:21
上手く全てのコアを綺麗に動かせれば、当然差が出るけど
実際の場面で、汎用処理でそういうことをするのは難しい。
姫野ベンチのようなプログラムだと差が出るだろうけどな
426:デフォルトの名無しさん
07/03/24 22:24:06
いい加減ナントカシェーダという呼び方はやめなさい
427:デフォルトの名無しさん
07/03/25 02:00:17
既に定着してしまっているモノを変えたければ、
より多くの人に共感してもらえて説得力のある代替案を出さなきゃ。
428:デフォルトの名無しさん
07/03/25 02:08:48
David Kirk 「この命名はおかしいと自分も思う。Shader(プロセッサ)はプロセッサと呼ぶべきだと思う」
URLﾘﾝｸ(pc.watch.impress.co.jp)
429:デフォルトの名無しさん
07/03/25 02:46:49
nvidiaはストリームプロセッサと呼んでるじゃん
430:デフォルトの名無しさん
07/03/25 05:51:54
シェーダーって元々影処理専門だったんだっけ？
431:デフォルトの名無しさん
07/03/25 06:59:56
それはシェイドシェイダーユニットの役割ですね
432:デフォルトの名無しさん
07/03/25 14:44:57
shade (r)だから影erみたいなもんだろ。
433:デフォルトの名無しさん
07/03/25 17:09:13
元が3DCG用語だからな
それをgenericな用途に使おうとしてるんだから
呼び方に違和感が出てくるのはしかたあるまい
434:デフォルトの名無しさん
07/03/25 19:00:37
3DCGの範疇であるvertex shaderの時点でもうおかしいわけなんだが
435:デフォルトの名無しさん
07/03/25 19:44:42
ピクセル影er
頂点影er
プログラム可能な影er
436:デフォルトの名無しさん
07/03/25 22:56:05
CG用語のシェーダーっていうのは凄く広い意味を持ってるからややこしい。
基本的に与えられたデータを元にピクセル出力するためのプログラムは全てシェーダー。
頂点処理をするのもそうだし、毛を生やしたりするのもシェーダーと言ったりする。
437:デフォルトの名無しさん
07/03/25 23:08:12
「シェーダ」は元々はRenderManとかmental rayとかの用語でしょ
438:デフォルトの名無しさん
07/03/26 04:57:07
vertex shaderはピクセルの出力と全く関係ないような
439:デフォルトの名無しさん
07/03/26 09:44:43
CUDAを使ってトリップ検索させると速いですか？
440:デフォルトの名無しさん
07/03/26 09:46:56
そういうのには向いてません。
高速にcryptを実行するってのは前に試したけど
いい感じにかきなおせなかったわ。
441:440
07/03/26 09:49:34
ちなみに、cryptの能天気な話は
URLﾘﾝｸ(www.gpgpu.org)
ここみてちょ。
ここに載ってるパワポは見た上で試したが…。
こいつら、分かってて書いてるんだろうけどさ・・・。
442:デフォルトの名無しさん
07/03/26 10:09:49
>>439
8800GTSで試したんだけど遅くはないけど激速じゃない。(4M程度)
コストパフォーマンスではC2Dよりちょっと分が悪い。
春に廉価版が出揃って、CUDAのバージョンが上がったらモノになるかな?
整数演算のイマイチ度については各方面から突き上げが激しいので
次アーキでは劇的に改善される可能性はなきにしもあらず。
>>440
俺はLUTで試したけど、MP内にてLoadネックで
並列度が頭打ちになってる感じ。>>440が試した結果をもすこし詳しくきぼん
443:デフォルトの名無しさん
07/03/26 10:59:36
■後藤弘茂のWeekly海外ニュース■
CPUとGPUの大きな違い
●汎用コンピューティングで近づくCPUとGPU
URLﾘﾝｸ(pc.watch.impress.co.jp)
444:デフォルトの名無しさん
07/03/26 19:18:04
>>442
C2DでもTrip-Monaで500k程度だから4Mでも十分じゃん
445:・∀・）っ-{}@{}@{}@
07/03/26 19:38:01
やきとり屋さんだよ
446:デフォルトの名無しさん
07/03/26 20:56:14
utripperはathlon64 2GHzで動かすよりCeleron 1.3GHzの方が速かったんだけどそんなもん？
447:・∀・）っ-○◎●
07/03/26 21:06:48
アレはキャッシュのレイテンシ依存だし
PS3で10Mうめぇｗｗｗｗとか言ってるの俺だけ？
448:デフォルトの名無しさん
07/03/26 21:14:43
>>447
Cellで？
449:・∀・）っ-○◎●
07/03/26 21:48:56
RSX使わせてくれないから、まあそうなるかな
450:デフォルトの名無しさん
07/03/26 23:23:18
>>442
GTSで4Mか。
GTXのSLIだとどれぐらいになるかな…。
また、理論ピークと、トリップ検索の性質を鑑みるに、まだ性能向上の余地はかなりありそう。
今後に期待だ。
まあカネも電力もバカみたいにかかるけど。
Woodcrest@3.0GHz×2でTripcode Explorer v1.2.3を動かすと10.3Mtrips/sらしいので、
Woodcrestを二機積んだマシンでGTXのSLIを使えばチョー最強？
451:・∀・）っ-○◎●
07/03/26 23:25:58
（・∀・）
452:デフォルトの名無しさん
07/03/27 10:26:11
>>450
電源が死にそうだね。つーか、熱対策か。
453:・∀・）っ-○◎●
07/03/28 01:25:33
CPUはClovertownの50W版でよくね？
454:デフォルトの名無しさん
07/03/28 03:45:24
取り敢えず、8800GTXの動く環境はできた。
#CPUは1coreXeonだけど。
さて、来月から実験だ。
455:デフォルトの名無しさん
07/03/28 18:10:27
URLﾘﾝｸ(sourceforge.net)
brookgpuの更新が止まってるように見えるんだけど、
とりあえずダウンロードしてみた。
サンプルプログラムどこ？
仕様はわかったんだけど、動作イメージが掴めねえ。
456:デフォルトの名無しさん
07/03/28 22:28:46
BrookはCVSで更新は続いてるよ。
で話は変わるがPeakStream Free Trial Download
URLﾘﾝｸ(www.peakstreaminc.com)
GPUとしてはFireStream,R580(?)
URLﾘﾝｸ(www.peakstreaminc.com)
Supported GPUs
AMD Stream Processor
ATI Radeon x1950 (Supported for evaluation purposes only)
457:デフォルトの名無しさん
07/03/28 22:30:06
PeakStreamはCTMしようか
458:デフォルトの名無しさん
07/03/30 00:30:52
>>455
ヒント：brook/prog の下
あとここの解説も分かりやすい。
URLﾘﾝｸ(www.mi.tj.chiba-u.jp)