GPGPU

いつの間にやらCPUを超える演算性能を持ってしまったGPUに計算させてみるという
GPGPUについて語りましょう

参考リンク

総本山? gpgpu.org
http://www.gpgpu.org/
GPUをCPU的に活用するGPGPUの可能性
http://pcweb.mycom.co.jp/articles/2005/09/06/siggraph2/

２

メモリーに関してはだんだんスパコンのアーキに近づいてるからなぁ。

ラデX1800のようにメモリレイテンシをあまり気にしなくていいというのは羨ましいな

ShとBrook期待age

CPU→GPU→CPUって経路でデータ流せるんだっけ?

出来なかったら、画面のキャプチャーとか出来ないだろ。

今現在、計算結果を持って帰るには一度フレームバッファに書いたのを吸い出すしかない。
今後改善されるとは思うけど、これじゃあ使えねぇよ。

でもXBOX360はメインメモリに直接アクセスする方法が用意されているらしい。
実用段階になったら、まずはトリップ計算機から誰か作ってよ。

>>8
ソース公開してる奴ってどれ？＞計算機
ちとやってみたい

これからはJavaやC#のようなオブジェクト指向言語をベースに
速度が重要な部分はシェーダー(GPGPU)でなんて流れになるのでしょうか？

なりません

GPGPUって過渡的なものであって、今後はXbox360/Cellに代表される
ヘテロジーニャスなマルチコアプロセッサの流れだろうな

360はホモ臭い

あぁたしかに360はハードウェアアーキはホモだけど、ソフトウェアアプリで
ヘテロっぽく使うんだった.

小泉風に言えばGPUでできることはGPUに、CPUでなければいけないところはCPUでってこと？

その言い方だと今までのアプローチとなんら変わらんがな

OpenGLとかで流行ったBASICにできることは（ｒｙ、Cでなければ（ｒｙと変わらんね。

それって>>10と同じじゃね？

未だにオブジェクト指向と速度を関連させる奴がいるのか。

JavaやC#が速いとはあんまり思えないけどな

age

情報が少なすぎて。。

RGBA8bitの32ビットフォーマットのテクスチャに対し、
各位置のビットが1のピクセルの個数を数える、見たいな処理って出来ませんかね。
Rの3ビット目が1のピクセルは150個、みたいな感じで。

RGBA4種類の個数とかだったら簡単に出来るんですが、
各ビット合計32個のデータを取り出す方法がおもいつかない。。

>>23
8bit パレット画像として扱うとかどう？
二アレスとサンプリングにして。
１回に１チャンネルしか処理できないけど。

>>24
やっぱり複数回に分けて処理するしかないですかねー。
せっかくデータをまとめたんだから、1度に処理できないかと考えたけど無理か。

bsf・・・はx86だしな

保守

JavaとGPGPUのコラボ最強と思ってるのはたぶん漏れだけ

GPUは基本的にストリームプロセッサだからCPUのような複雑な
分岐や少量のデータ処理を多数行うような仕事だと効率悪い。
現実は厳しいよ。

そういう仕事をGPUに投げるのが間違い。

>>29
大量のデータをひたすら単純処理する仕事はJavaの苦手とするとことだと思うのですが

C++とGPGPUこれ最強

>>1
語りたい事もないのに糞スレ立てるな

GPUってなんの計算をしてくれるのよ。

ようはSIMD

>>34
いまならシェーダーさえ書けばどんな計算だってしてくれる
向き不向きはあるが、膨大な量の単純計算繰り返しなら
最新のCPUよりもGPUのほうが早い

向き不向きなんてレベルじゃない。
かなりのレベルの並列性が無いとダメだし、入出力もかなり限定された形でしか出来ん。
どんな計算でもなんてとても言えん。
が、条件にはまる物ならばパフォーマンスの高さに驚く。

結局GPGPUの使いどころとしては画像処理(2D)・映像処理・音声処理あたりに落ち着くんでしょうかね
もともとGPUの得意分野だし

物理演算はねーの？？

GPU演算での精度はどれぐらいまで期待できるんでしょうかね？

丸めの方向を制御できなかったり、なんていう困った点もあるみたいよ＞GPGPU

保守

age

発想としては面白いし、昔からこういうハードを本来の目的以外に使うって話は好きなんだけど
(キャラクタ表示機能しかないマシンでビットマップ表示とかFM音源でPCM多重再生みたいな）
なんかあんまり現実的に聞こえないんだけど。。

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

CPUのマルチコア化の流れを受けてのことなのかな。
昔のコプロみたいにCPUの中にそういうGPU的なアーキテクチャを組み入れていこう、
って展望でもあるのか？

3D表示使わないアプリで使えば無問題だし、
最近じゃハイエンドじゃなくてもシェーダが動く。
GPUの違いはシェーディング言語そのものでバージョン管理と、
そのラッパーであるライブラリで十分埋まる。

>>44
とても現状を理解しての発言には思えない。

PhysXもそろそろ出るね
CPU以外のパワーを利用するのって
一時的かと思ってたけど時代の潮流かな

http://staraxis.kazelog.jp/okiraku/2005/11/atiavivo_49a9.html
ATIのAVIVOエンコード機能は凄い!!

DVD映像5分（720x480）をDivXやwmvにエンコードするのが25秒で終わるとか早すぎ！！！
GPGPUを使った物らしいです

いや、Theaterっていう専用チップが乗ってるよ
http://www.4gamer.net/news.php?url=/news/history/2005.09/20050920190000detail.html

FAQ - GPGPU.org Wiki
http://www.gpgpu.org/wiki/FAQ

GPU GEMS2の日本語版が出たようだ

http://www.shader.jp/xoops/html/modules/wordpress/index.php?p=166

sageたままだった・・・orz

AGPメモリにフレームバッファ確保できなかったっけ？

>>10
Javaチップ、Javaアクセラレータ
なんてものがあるしな。
考えられなくもないな

>>19
むしろVMと速度だな。
C言語の中の人は
オブジェクト指向を使うと速度が遅くなる
から使わない方がいいとか未だにいっているからね。

>>28
JavaのGUI, Swing APIやJava3D APIの3Dレンダリングの
部分だけGPUに任せられたらいいねえ。

>>31
それも微妙なところではあるが。
Java SE 5 Tigerからかなりの高速化が実現されているし
Java SE 6 Mustangからはさらに高速化する。
Javaアプリ初回起動だけVM上で動いて
２回目以降からはネイティブで動くってことがあるわけで。
Javaアプリを起動するたびにVMをいくつも起動するという
問題も解消されるし。

それとJavaは他の言語と比べレスポンス性能が
極端に遅いことからクライアントサイドでは普及が
一時停滞した。ところがJavaは代わりに
スループット性能が高いという利点があったりする。
他の言語が戦術的短距離走タイプであるのに対し、
Javaは戦略的マラソンランナータイプ、ってところだろうか。

>>56
Java3DはOpenGLかDirect Xがバックエンドになっているんだが。

ちなみに、SwingをGPUに描画させるという考えは、Swingの
設計思想(全部Javaで描画)に反するから実現不可能。

これってグラボ変えたら動かなくなるんでしょ？
グラボなんてドンドン新しいのが出るんだからそんなの使えネェじゃん。

それを避けるための高級言語じゃないの？

自作板の雑談と何も変わらんな

大抵はグラボを変えても動きます
特に新しいものに変える場合は可能性は高いです
例えるなら>>59は「MMXってCPU変えたら動かないよね？」みたいな質問です

＞大抵はグラボを変えても動きます
大抵って？

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

MMXは、世に機能公開して広範なアプリを作らせた以上、
後継CPUでは完全互換を取って当たり前、という位置にいるわけだが、それと同等と？　
MMXが出たのは１０年くらい前で、今でもまだ動くんだが、それと同等と？

>>63
既にShaderはほぼ標準装備ですが何か？

>>63
並列アルゴリズムの実装のために少しでも安くて速い計算リソースを使おうという研究なんで、
互換性を気にして「10年後に動かなかったらどうするんだよ」という向きには用は無い。

そもそもGLSLはOpenGLドライバ側でコンパイルされてGPUのコードに変換されるものだから
原則的にはGPUが変わっても動くと考えても問題ない。
(バグや仕様で動かない可能性は100%否定できないが)

ARBあたりから互換性のないシェーダー言語が出てきて、
どっかのGPUメーカーが今のGLSLをサポートしなくなるということがあれば問題になるが
ここまできてARBやGPUメーカーが今の仕様を完全放棄するのは難しいと思われ

今までのGPUは後方互換をほぼ意識しないで拡張してきたからこれだけの性能が出たのだと思う。
今後もちゃんと動くかはかなり疑問に感じる。（GPGPUが一過性のような気がする。

＃最近のボードでも過去のDXは動くけど、ネーティブに動いてるわけではなくて、ドライバ辺りのエミュレートだったと思う。

まぁ一過性というのはそのとおりでGPUは通過点でしかないだろうね。
今はいろいろ試して、問題点を出したり適応範囲を模索したりしてる段階。
それを元にハードウェアも含めてだんだん方向性が決まってくるわけで。

GPUに本当に有用なアーキテクチャがあるならコプロと同じ運命をたどるでしょ。
リレースイッチをブザー代わりに使うような技術に発展性があるわけがない。

age

>>69
浮動小数点演算はコプロというか専用エンジンが無いとどうしようも無いぞ。
それはCELLとかも同じ。

整数演算もできるようになるのはいつ？

>>71
意味わからん。話が噛み合ってないな。

どうでもいいけど、コプロがない時代はPCは浮動小数点演算ができなかった、
とでも思ってるのかなw

マシンに本物のFPU積んだ時には、嬉しくって毎日レイトレしてたな。

コプロ積んでもBASICが全く速くならなかった時には、orzだったな。

>>69
しかしブザーが出回るまでの間は有用だし生き延びるだろうさ。

コプロ無しの少数演算って遅すぎだろ

それよりGPGPUの話をしよう

先生！誰もわかってないので話すことがありません！

GPGPUは手段であって、目的じゃないからな。
なにか高速に計算したいものがあって、その手段としてGPGPUが良ければ使う。
目的がないのにGPGPUやろうぜとか言われても盛り上がらん。
手段のために目的を探すのはアホだしな。

目的がないから手段も学ぶ必要ないもんな・・・・
日本発のGPGPUを使ったDivXエンコーダーとか作れれば盛り上がるのだろうが。

GPGPU = Game Programming Gems(ﾌﾟ

>>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

Scoutって一番興味あるんですが、まだ公開はされていないんですか?

Los Alamos National Labsのサイトに行ってもPDFの論文にしかリンク貼ってない。

>>84
Brook for GPU じゃだめなの？

Vista時代で、常に3D使うようになったらGPGPUも終わりな気がするのは
俺だけかな。

AeroGlassをEnableにすれば大丈夫じゃない？

AeroGlassをEnableにすると、常にシェーダーが使われているわけだから
GPGPUには使えないのではないかと思ったんだけど。

>>86
GPGPUって科学技術計算等の激しく重い演算用だろ？
普通のアプリ走らせてる横でやる必要もないと思うが。

聞きたいのは二つのシェーダー使うアプリを同時に使用できるかと言うこと。
できるのならWindowsがGPU使っていてもGPGPUできるだろう。
もしできないのであったら、GPGPUするときはAeroGlassをオフにしなければならない。
>>89が言うことももっともだが、いちいちそんなことが必要になるなら価値は少し下がる。

GPUにもコンテキストスイッチは存在するんじゃね？

ごめん、英語間違ってますた…disableだ…＿|￣|○

VistaではGPUが仮想化されて、DirectXのデバイスロストが無くなる。
GPGPUとAeroGlassの併用も可能と思われ。

>>90
GUIは(ゲームなどの描画と違って)四六時中描画してるわけではない。

>>90
多分できるだろうけど、切り替えが発生したら猛烈に遅くなる予感。
GPGPUの唯一の価値＝速度だから、あんまりそういう用途には向いてないような・・・

計算用に、もう一枚刺す。

>>85

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

Vista時代には、PCI-ExpressにGPUどんどん追加していける仕様にするのでは。
x1でもパフォーマンス出るように工夫する必要があるけど。

>多分できるだろうけど、切り替えが発生したら猛烈に遅くなる予感。
CPUはそれなりに現実的にマルチタスクできてるんだから
GPUだけできない理由は何もないような。
ドライバがそこらへんに対応してれば。

>>98

並列性が高い分、タスクスイッチに伴うペナルティコストが、CPUに比べて
馬鹿にならないと思われ。

並列動作可能なら、CPU側のタスクに合わせてタスクスイッチする必要はないんじゃない？
OS分の描画やりながら、遊んでるユニットでGPGPUの計算するとかできんの？

VistaになってもUIは2kスタイルに設定するから問題ない。

>>100

ローカリティの問題があるから、かなりVRAM積まないと違う作業はやりにくいと思うよ。
別カードにした方が賢いね。OSの描画はUMA、GPGPUはPCI-Eとか。

結果はどの道メインメモリに書き戻すんだからそれほど大きなワークは必要なさそうな気もするが。
scatter&gatherつってもその範囲は高が知れてるし。
まあ用途次第だけど。

GPGPUを使ったプログラムを誰かうｐしてくれよ

だれかエンコーダー作ってよ。
sf.net探したけど見つからないし。

保守。

>>89
MFLOPS単位で処理能力公表してるし、浮動小数計算するのがメインっぽいね。
代表的なのとしては、動画再生支援くらい？
画像音楽動画エンコくらいしかおもいつかね。
他に浮動少数が活躍する場面ってなにがあるかな？

>>90
3Dならそれぞれのオブジェクトに対するシェーダーをロードして描画って感じだから、
それぞれのパイプラインが処理して同時に出力できるってな感じじゃねの？

今こそGPGPUを活用するときではなかろうか。
http://pc.watch.impress.co.jp/docs/2006/0120/mobile321.htm

H.264はAMDがYAMATOでデモってたけど、
やっぱ70Mbpsまでいくとコマ落ちするんだろうか。

PureVideoとか待ってられないから、オープンソースで
シェーダ実装のH.264デコーダーとかでないかな。

つかここム板なんだからGPGPUでhello, worldくらいやれ

だめだろ文字列を描画する以上の複雑な計算が無い
描画を豪華にしたいなら普通にシェーダ普通に使えって話

ATI X1900スゲー化け物だね。

ただ例によってSM3.0といってもフル実装ではないのかな。
GPGPUというとどうしてもnVIDIAという印象があるから
手を出すのは勇気が要るのだけど・・・。

純粋にグラフィック扱うならHDRでもAA効くATiの方がいいと自分は思ってるけど
VTFとか見てるとほかにも問題ありそうで怖い。

まだまだ実用的ではないな

X1800の時の爆熱問題を解決しないまま、
さらに熱い物を出してくるのは凄い。

実際X1900なんてメディアのベンチ掲載用にとりあえず作ったやつでしょ。
数出さなければ、いくらでもできるよ。
普通のCPUだとただコア増やすだけじゃ意味無いけどGPUなんて増やせば増やすだけいいしね
まぁ一つが小さくて単純だからできるんだろうけど。

3DMarkだけスコアが高いなんてさすがATIだな

それでも48基って一度触ってみたいﾊｧﾊｧ

>>119
お熱いのがお好き?

Intelが45nm製造に成功って書いてあったけど、
実用化されれば90nmの製品がまったく同じものだと1/4の面積になるの？

原子・分子のサイズの限界もあるからまったく同じにはならない筈だよ。リーク電流対策とか必要だし。

>>10
速度が重要で、かつこれからやる処理の中でGPUだと著しく速い命令で解決できる処理を内包する時だろ？

GPGPUをやってみうと思い、試行錯誤しているのですが、
floatの配列を画像に変換してテクスチャとして貼り付け
オフスクリーンに出力された画像をfloatの配列に戻すまでは出来たのですが
シェーダー上ではテクスチャや出力する色情報がvec4やfloat4となっていて、
そのままfloatとして扱うことができません。どうすればいいのでしょうか？

>>124
つ　スウィズル演算子

まあ並列で処理しないとGPGPUの魅力が4分の1になるんだが。

カタカナだと出ないな
ttp://www.microsoft.com/japan/msdn/library/ja/DirectX9_c/directx/graphics/reference/shaders/ps_swizzling.asp

>>125-126
即レスありがとうございます。
これを参考にいろいろ調べてみます。

スレ立て以来初めてム板らしいやりとりが成立したなｗ

次はCPCPUの時代

みんなこれ読んだか?
ttp://grape.astron.s.u-tokyo.ac.jp/~makino/articles/future_sc/note011.html

>>130
説明は面倒くさいが、その記事には同意しかねる。
GPGPU が万能じゃないなんて当たり前な話で、使いどころが分かってない奴は使わなければいいだけの話だ。
俺はゲーム屋だから、やらせることはいくらかある。だからやらせる。

なあ最近ひらめいたアイデアなんだけど聞いてくれる？
普通テクスチャをシェーダにバインドするときの最大でも16ぐらいまででしょ？
でもテクスチャの代わりにキューブテクスチャを使えばx6枚使えることにならん？
例えばR32Fのシャドウマップを普通にバインドすると16だけど
RGBA32Fのキューブマップとしてバインドすれば16x6x4=384になる。ﾅｲｽｰｱｲﾃﾞｰｱじゃね？

>>132
キューブの境界に連続性が無いデータだと、ちと不安だな。
あと、rgba にするのは、チャンネル間移動が無いことが前提だな。
いざというときには使える tips かもね。

>>121
原子分子のサイズが主要な問題ではないんだけどな。
半導体製品の製造工程は理解できている?
#つーか、原子分子のサイズだけを問題にできるような製造技術があったら一財産築けるぞ。

http://v-infinity.seesaa.net/article/11073754.html
GPGPUを使っていると思われるエンコードソフト

ATIとnVidiaのビデオカードで動作するらしい。

>>135
>>48

記事先では、GPUではなく、CPU処理って書いてるけど
ぶっちゃけ、単なるシェーダーで処理してるだけなら、現行のGF/ATiのGPUでGPU処理できると思うんだが・・・。

GPUはUIの表示以外に使ってない。将来的には使う予定だろうけど。
じゃあ最初にCPU用コード書く必要ないじゃんね。もしかしてOSSのぱくり？

>>31
> 大量のデータをひたすら単純処理する仕事はJavaの苦手とするとことだと思うのですが

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

システムよりな事、例えばアプリの起動速度、は苦手なこと多いが。

>>139
おまえはJavaでソフトウェアレンダーでも書いてろ。

確かに多少ゆがんでるようだが>>31よりは事実に近いな

Java厨は消えろ。どうせシェーダなんて叩けないだろ。

Java氏ねPCの動作を重くする害虫ソフトめ！

重くなるのか？

>>139
単語に反応するだけじゃなくて、議論の流れを読めよ。

実際問題として例えば

　　LAPCKが動いた

とか

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

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

JavaのJITがGPGPUを使用するコードを吐くと嬉しい。
これが出来たら、ネイティブコード系の言語がいらなくなるかも。
性能面で。

>>147
JavaからGPU使えばいいだけでは？

実行環境が対応することで
開発した当初は存在してないGPUも
活用できるようになるだろ。
WORAの思想もそのまま生かされる。

そのためのCgでは？

Cgは演算結果をメインメモリに書き出せない。
だから、基本的にはグラフィック処理にしか使えない

メインメモリに書き出すのはシェーダではなくAPIの役目では？

そういう仕組ができれば自然とCgやHLSLもサポートするだろう。
問題はいつサポートされるのかということと、まともなスピードで
出せるかということだ。

Direct3D10のOutputStreamみたいな話？

>>148
透過的にして欲しいということだろ？
現状VMもSSE2とか自動判別してつかうようになったり
ハードウェアアクセラレーションもDirectXやらOpenGLやら使えてる

WinだとNT4対応のためにDirectDrawがデフォだが描画時テクスチャの
コピーをメモリからVRAMに自動的に作って高速にブリット、
オフスクリーンイメージが失われたらメインメモリから復旧とか全自動だ
もちろん、VRAMにおいておく優先順位が設定できて自動的にVRAMから
おいだされたりとかわりとすばらしい

Java3Dでシェーダ使えるんじゃないの？

なぜゆえこのスレでJavaにこだわるんだ

極度に抽象化されているがゆえに知らないうちに使われている

という状況が一番あるからでは？

JITにGPGPU使わせるよりも、
シェーダをJavaで記述する方向で開発した方がいいだろう。

5.0で追加されたatomicAPIとかみたあとではもう何が来ても驚かん。

CoreImageもGPGPU？

わけねーだろ

GPGPU = 食べるための研究ネタ + 趣味

でも、かつての「コプロセッサ」みたく、
ベクトル演算用のプロセッサを
メインプロセッサの他に持つのって
たぶん正解の一つだよな。

バスがハイパートランスポートだと最高かな。

>>164
その考え方だといつかはCPUに取り込むのが普通

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

感覚的には非対称型マルチプロセッサのほうが近いのでは

>>164
＞ベクトル演算用のプロセッサを
＞メインプロセッサの他に持つのって
その目的は何だ？

暗号とかゲーム用物理演算のアクセラレーション

それって、CELLじゃん。

>>168
orz
車輪の再発明スレに行ってくるか....

でもIntelのMany Core構想ってCellにも通じるものがあるよ。
汎用プロセッサだから当分はメインコアのリッチ化は進行するだろうけど。

つーか、ＤＳＰ搭載やらｘｘコントローラ搭載なんてＣＰＵはありふれてるし、それらと今のＧＰＵはちょっと違うだろ。
依存性の無い並列処理がたまたま最近（ちょっと昔？）の頂点処理や画素処理にあるわけだ。
Cell なんかは、あまりＧＰＧＰＵっぽくはない。ＤＳＰを７つとか８つ積んでるようなもんだ。
ゲーム屋には面白いけど、ＧＰＧＰＵらしい並列演算を念頭に置くなら、ヘテロなんてどうでもいい。ＧＰＧＰＵのパワーの源は、同じコンテキストの演算を別パラメータで同時に実行するトコにあるわけだから。

昔パソコンのCPUが貧弱な時代にはプロセッサボードというのがわりとありまして
拡張スロットにCPUより性能のよい石とメモリがのっておりました。

歴史は繰り返してるだけ

それいうならコプロw
つーかガイシュツ杉

このスレでGPGPU以前にシェーダプログラミングやったことある奴って
２・３人しかいなさそうだな

>>173
コプロだとコプロインターフェース経由でのアクセスという意味だから
外部にあるプロセッサとは別物だろう


そしてGPUはそっちの方式

O・D・P！O・D・P！

組み替え可能ハードウェアはどうよ
FPGAで組むと、クロックは半分くらいになるらしいけど、
特定用途なら１サイクル当たり倍以上の性能だせるっしょ

数百MHz〜数GHzクラスのクロックで動かせる一般向けFPGAってあるのか？

通常300MHzくらいまでだな

ただし、腕による

http://www.xilinx.co.jp/products/silicon_solutions/fpgas/virtex/virtex4/index.htm
これは５００MHzってなってるね
フリーの高速実装とか出回ればよさげ。

ハードウェア加速という訳がきらい

ハードウエアブーストってのはどうだ？

ハードウェアｋｓｋ

GPGPUって

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


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

いまいちどんな計算できるかわからない

文字だって、１つ１つは数値でしょ。アスキーコードの
普通に出来るっしょ

整数演算性能には期待しないほうがいい気もするんだが・・・

期待するとかしないではなくて可能か不可能かしりたい
現状Pentiumの100Mhzぐらいの処理性能でもいいから
可能かどうか知りたい
　サンプルとか全然なくて書き方すら解らず困り気味

文字コードを実数に変換して処理するとか（ｗ

可能かどうかで言ったら、むしろ不可能なことの方が少ないだろう。
ただ184の処理は明らかにGPU向きではない。

というより184は>>131の2行目でも読んでくれ。

>>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 のゲームはお蔵入りしたｗｗｗｗｗｗ
今ＤＳやってるｗｗｗｗｗ
おまいらはテクスチャフェッチのレイテンシ隠すのに涙目になってればいいさ、ばーかばーかｗｗｗｗｗｗ

TextSS　のWindowsXP(Professional)64bit対応化おながいします

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

そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？

>>190
あー

お前特定できちゃいました

興味あるのですがどこから入門すればいいのでしょうか

>>190のVRAMアドレッシングの話って、詳しい説明あるとこない？

>>194
知らん。
しかしピクセルがＶＲＡＭ上で何故ジグザグに配置されているかを理解してれば問題ないんじゃないだろうか。
それ以上は機器固有の話だから、実測するしかない。

havok fx
ttp://www.shader.jp/xoops/html/modules/wordpress/index.php?p=230

>>195
ジグザグに配置って初めて知ったんだけど、どういうこと？
http://spin.s2c.ne.jp/stoday03.html
の、ヒルベルト曲線順ラスタライズみたいな話ですか？

通りすがり＆スレ読んでなくて悪いけど、これはガイシュツ？

GPU コンピューティングの動向と将来像
ttp://www.jaist.ac.jp/~masa-t/publications/GPU_final.pdf

>>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 のような人にとって喜ばしいことだ。

>>198のは>>196の管理人が書いた物だ

プログラミングはどこから始めたらいいのでしょうか。
GPGPUの技術的な背景とかは解りましたが、
とりあえずプログラム組んでみてどこまで可能か調査
してみたいのですがみなさんはどこから学んだのでしょうか

>>201
アバウトすぎだ。
何が知りたいのかサッパリわからん。
http://www.redout.net/data/osietekun.html

nVidia のサイトでも行けば？

いやもうHelloWorldレベルでいいんですけど

・・・・。
がんがれｗ

>>203
http://msdn.microsoft.com/library/ja/jpdx8_c/hh/directx8_c/_dx_directx_graphics_c_c_tutorials_graphics.asp
これで不満なら、どこまで出来てどこで詰まってるのか説明しろ。
他の連中は知らんが、俺はエスパーじゃねぇ。

↑それは、GPGPUというよりDirectXのHelloWorld

要するにGPUで1+1を計算させて2という値をメインメモリに
持ってくるようなのがGPGPUのHelloWrldじゃないのかな。

NVIDIA、GPUによる物理シミュレーションをGDCでデモ
http://pc.watch.impress.co.jp/docs/2006/0322/nvidia.htm

>>206
じゃあお前が説明してやれよ。


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

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

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

なんでそんなに俺をイラつかせるんだ、ってスレが昔あったなあ。マ板だっけ？

Brookとかｓｈとか使ってプログラム組んでみた方いますか？
今ちょっと勉強してます。

レンダリングするだけじゃ普通の描画じゃんか。

>>210
何が不満なんだ？ Hello World と同じくらいには役に立つと思うが。

クダ巻くだけならどっかいけ。

>>211
>1を読めよ

>いつの間にやらCPUを超える演算性能を持ってしまったGPUに計算させてみるという
>GPGPUについて語りましょう

>>213
演算結果の出力がレンダリング結果じゃないか。
エッジ抽出や DCT とかしたら、フレームバッファに転送して目視確認するだろ？
何が足りないんだ？ それとも何かが蛇足なのか？ 「入門」がスレ違いなのか？

じゃあDirectXスレでいいじゃん
このスレ要らんね
終了か？

GPUで計算してフレームバッファに書き出して、そのフレームバッファを
メインメモリに持ってきて、それを構造体に格納していくくらいのことしないと
HelloWorldとは言えない。
そして、いまでは専用言語で簡単にできるじゃないか。

行列演算が簡単に出来れば応用範囲が広がりそう

俺もHelloWorldを欲してるクチでGPUを使う方法が分からないから何とも言えんが
行列演算はSIMD向きじゃん。文字列処理に比べれば簡単だと思う。

問題は、どれだけGPUにデータを留めたまま大量に演算出来るかじゃないか?
1演算してはCPUが使うようだと、GPU間のデータ転送に時間を食われる。

みんな、DSP的に使いたいのでしょ？
メディアンフィルタとかエンコーダーとかやってみたいね。
俺もやり方はよくしらんが。

はっきり言ってDSP的に使う以外、GPUに興味ないな
だれか教えてくれないのですか？ケチしないで教えてくださいよ

>つーか GPGPU で Hello World つったら、Hello World って書いたテクスチャをフレームバッファにレンダリングすることじゃないか？
ﾜﾛﾀ

>>215
> じゃあDirectXスレでいいじゃん
いいアイデアだ。入門はヨソの描画ライブラリスレに任せよう。
このスレは入門に限ったスレじゃないから、話題がある限りは不要ということも無いだろう。

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

>>221
楽しんでいただけたようでまことに結構。

定番の波動シミュレーションあたりが、Hello World的存在じゃないかな。
GPGPU的には全く面白くないネタだけど、Hello Worldってそんなもんだろう。

よし決めた。
最初の目標はGPUでπの計算することだ。

>>223
おれはそういうのは、最初の演習問題にはふさわしいけれども、Hello World 的だとは思えないのだが。
ちょっとのお約束と、なんらかの出力、という程度が Hello World 的ではあるまいか。変数や制御構文の前にやるものだし。

描画はできる、というのを前提とするのなら、プラットフォームやライブラリを越えて一般化できる具体的（ソースつき）な入門はありえない、という結論になるだろうか。それとも専門言語の人に期待するか。

なにこのヘタレの素靴

>>226
ようこそ

GPGPUって、
ベクトル演算器→たけーよ→グラボ使えるじゃね?→できるもんならやってみろ
の世界だろ。

うんそう

だからフレームバッファに描画さえすればhello worldとか言うのはおかしい

うんこう

>>230
あとはロックするコードだけ晒せばいい？
他には何かある？
そもそも DirectX 限定というはおかしいと思うのだが、そういう指摘は無いの？
それとも Hello World の定義が違うなら、>225 に書いた、「最初の演習問題の前」「変数や制御構文の前」とは違う定義をしてくれ。

1+1, 1+2+3+...+10を計算するコード

どちらか？ それとも２つとも？

後者がいいな。ループも使うし。

トリップサーチはどう？

ほらよ。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>]

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

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

乙。アセンブリでシェーダ書いてるあたりがプロ臭い。

プロならコードを出すわけがない。
著作権は自分にないからな。

普通にアプロダにあげてくれないか？

おまえらuudecodeもできないの？
俺はLinuxだから標準でできるけどコンパイルはできないというふざけた奴だ。

乙。
D3DTSS_TEXCOORDINDEXにハマったが、ようやく2つのテクスチャを足せるようになった。
俺のグラボじゃPixelShader1.xだし8bitしか対応してない。ちっ。

おまえらもしかしてコレ↓で十分だったのか？
http://www.gpgpu.org/developer/#tutorial
散々叩いといてさ。

どーでもいいけど PS3 か 360 の仕事くれ。安くてもいいから。
ＤＳはもう飽きた。仕事が来ても倍の人月でふっかける。

brook良さげですよ。環境構築が面倒ですが。。
http://gpgpu.jp/category/1411192.html

Linuxで開発する方法教えてください。
Windowsってキモクて真で欲しいのでお願いします

Linuxでコンパイルする。
それだけ。OpenGL系ならそれでいいじゃん

>>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
あたりへ行け。

>>246
アラッ、いいページですね
参考になりました

brookコンパイルしたいLinuxでしたいです。
Windowsはきもくて嫌ですお願いします

>>251
つ http://www.gpgpu.org/w/index.php/Brook#Installing_Brook

ﾓｼﾞﾚﾂｦｱﾂｶｲﾀｲ

１文字１文字をfloatにするとか？
いずれにしろどう処理したいかによるか。

60ＧＢのデータをソートするのに90MB/secって遅すぎだろ
大して速くないよなＧＰＧＰＵ

文字列処理ライブラリを作りたいのか？
それとも探してるのか？

文字列処理ライブラリを作りたい　ＹＹＹＹＹＹＹＹＹＹＹＹ
探している　ＮＮＮＮＮＮＮＮＮＮＮ
という感じです。最近徹夜でテンションがＡＧＥＡＧＥです

基本的には複数の文字列に対して一斉に同じ関数を適用することしかできないがそれでいいのか？
（コマンドリストを作るとかもできなくはないが）
シェーダアレイ内で一番遅いピクセルに律速されるのでばらつきが大きいデータはパフォーマンスが出ないがいいか？
DirectX のシェーダアセンブラしか知らない俺でよければ手伝えるかもしれないが。

うーん、ちょっとまだ解ってないこと山積みだけど
あるデータないから、特定のデータを探すとかができればいいですよね
たとえば特定の方法で解析すると意味ができるようなものとか

ツリー構造のデータ
線形リストデータ
そんな感じのデータを検索したりすることができないかと考えていろいろ調べてはいますが結果はいまだ０

>>259
strchr ならできるが、フェッチ量を考えるとかなり具合が悪い気がするな。
同様に正規表現検索なんかも、DFA にしたのをシェーダ言語にコンバートできそうな気もするが、汎用 CPU みたいな気合入ったキャッシュ機構がないと具合が悪そう。
ツリーやリストはまだなんとかなりそうかな。

つーか、いろいろ調べてるなら、アセンブラしか使えない俺は用無しか。

アセンブラでもいいんですけど、何せ効率が悪いので
できれば、C++からインラインで留めておきたいと考えてます

GPUとCPUで、得意不得意な処理があると聞きます。
GPUが得意な処理はCPUの何倍も高速に処理できると聞きましたが
具体的にはGPUが得意な処理と言うのはどういったものなのでしょうか？

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

依存性の少ないストリームデータを横に並べてベコベコ叩くような処理が得意です。

ぶはは、馬鹿ばっか（核爆）

自称研究者の単なる情報収集家とかいるしなｗ

日本の大学でgpgpu系の研究室って有りますか

>>266
無い。日本の研究者連中はどいつもこいつも馬鹿。
素直に欧米の大学行け。

別にGPGPUの研究してないから馬鹿ってわけでもないと思うが・・・
むしろ、GPGPUの研究してるようなやつの方が有る意味馬鹿に見える。
もちろんこの場合の馬鹿は、変態的な手段で目的を達する事に喜びを得る馬鹿って意味だけどな。

GPGPUﾊｧﾊｧ…

こと半導体に関しては、大学よりも企業の研究所のほうがレベル上なんじゃないの？

>>270
誤爆？

>>271
誤爆じゃねって
ぶっちゃけどーなの？

>>270
GPGPUは半導体プロセスよりも情報処理の方が分野が近いとおもふ

いいたいことはわかる。
ハードウェアアーキテクチャ屋ね

一時はもてはやされてたが、今どーなんだ？
どんなに素晴らしいアイディアでも普及しなきゃ意味ないからなぁ

誰かGPUをC++から扱う事が出来るクラスライブラリのSh使ったことある？
関連書籍も無いし、途方にくれてる・・・orz

ぐぷぐぷ

>>277
俺もスレタイ見てそう読んだ

>>275
普及ってお前、どのレベルで言ってんの？ HPC が必要な分野なんてそうないだろ。
マジレスついでに言っておくと、ゲームでよく使われてるよ。

http://www.geocities.jp/takashi_drive2005/gpuindex.htm
皆さんの参考になりませんか？俺が書いた訳じゃないけど。

>>280
続きが見たい。

情報処理学会あたりで検索かけると何件かネタが見つかる
ttp://www.bookpark.ne.jp/ipsj/
著者なり研究室なりをたどれば少しは情報が出てくるんじゃなかろうか

あげてみる

GPGPUはれいめい期なの？
参考書籍はないの？

GPUはあと3年もすればコプロセッサという名前になります。

AMDにそんな業界を作り変える力は無いぞｗ

intelとnVidiaはどうするんだろう？

Intelは業界１位のグラフィックスチップメーカー＆CPUメーカー
nVIDIAは業界１位の単体グラフィックスチップメーカー

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


どう考えても、AMDとATiが組んだところでそんな業界の仕組みを変えれるとは思えない。
２位同士が組んでどうやって１位同士が確立しているシステムを潰すってんだ。

最終的にはIntelがそういう流れを決定付ける。

まあな

GPGPUで動画のエンコードとか聞いたけどさ
そういう前後の依存関係が関係する処理ってGPUで出来るの？
一旦、処理した内容をメインメモリに戻して、その結果を元に次の処理って事をしないといけないと思うんだけど・・・。

動画圧縮における「前後フレームとの依存関係」と
アルゴリズムにおける「データの依存関係」は違う。

GPGPU的Hello Worldとして何から手をつければいい？
ちなみに現時点でGPGPUについては概要しか知らないんだが。

ハロワルは視覚的にわかるものが好ましいから
適当なテクスチャデータ→GPU→ピクセルズーム→メインメモリ→BMP出力
こんな感じでどうよ？

>>293
http://www.gpgpu.org/developer/#tutorial
http://www.gpgpu.org/w/index.php/Brook#Installing_Brook

このスレで Hello World の話題が出たことあるんだから、それを踏まえた上での質問をして欲しいものだが。

ATIのGPUがFolding@homeに参戦
http://slashdot.jp/articles/06/08/27/0239247.shtml

こういうのが本命かな

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..

>>297
ぱっと見ではプログラム中の一部の処理をピクセルシェーダに置き換えられるようにしただけに見えるんだが
どうも要領を得ないので読み直すか

ttp://www.shader.jp/xoops/html/modules/wordpress/index.php?p=326

http://www.gpgpu.org/
が見えないんだけど、どうしちゃったんだろ？

http://journal.mycom.co.jp/articles/2006/08/01/siggraph01/004.html

DX10では今までと比べ物にならんほど汎用性が増すみたいだね。

浮動小数点数のバッファに1.0より大きな値を記録する事は出来ないのでしょうか。
試してみたら1.0で飽和されてしまって。

シェーダー言語使ってるかどうかとか、情報少なすぎ。
どっかで8bitとかのフォーマットに変換されてたりするんじゃないか？

>>237を元にしてD3DFMT_R32Fを使いテクスチャを2枚にして
ps_1_1
tex t0
tex t1
add r0, t0, t1
してます。

結果が1.0以下になる演算では小数で解が得られているので
8bitに変換されているというより1.0で飽和しているという印象を受けました。

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枚のテクスチャを加算するピクセルシェーダのコードはこれで間違いないでしょうか。

俺の持っているのは 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 のコードは合ってる。

http://pc.watch.impress.co.jp/docs/2006/1109/kaigai316.htm

>>307
これで、おれのようなへっぽこコード書きでも使えるようになった。

Geforce8800GTXのSLIで1TFlopsが30万円くらいだしすげーよな。
はやく開発環境ほすぃ

ここまでくると、もうGPGPUとは呼べないよね。

今までシェーダーでやってた人が馬鹿みたい
メモリー周りはどうなってるのかな？

そんなことよりもなぁ、演算プロセッサボードで作ってた連中が不憫で不憫でw

あーもう要らないね、GPU内で全部計算できるし、転送しなくてすむし。
グラフィック以外の計算にも使えそうなキガスルがどうだろう。

>>313
フーリエ変換に使えないか、調査予定。巧くすれば、プロセッサボード屋に払う分をこっちの仕事にできそうな希ガス。

GPU内でDSP的でない処理がモリモリできるのであれば、
メインメモリとの転送量も少なくできるかな。
もしそうなら、x16じゃなくてx1レーンに沢山のっけてもいいかも。
できるかどうか知らんけど妄想。

Cで扱えるようになるっていうのは、ハードウェア的な新機能なの？
旧型のGPUも、ドライバーで扱えるようになるのかな？

GPUのアーキテクチャーが大きく変わったことでCでプログラミングできるような
構造となった。だからコンパイラー付き

よって旧型チップじゃ使えないよ。

なるほど・・・、THX
ドライバ側っつーか、ライブラリ側でかなーり頑張れば旧GPUも対応出来そうな感じもするんだけどなぁ。
もちろんパフォーマンス的なものが変わってくるだろうけど。

無理。

これってやっぱ単精度なんだよね？

ちゃんと嫁よ
プロセッサ内蔵してそこが実行してるんだから旧も新もあるか。

>>320
（独自）Cコンパイラ使えます
けどdouble使えません

単精度浮動小数演算器に桁上げ回路？くっつけて
できないのかねぇ？
ソフト的にやったら性能ガタ落ちだろうし。

http://www.4gamer.net/news/history/2006.11/20061113170123detail.html

CUDAの詳細どぞ。

ほんと今までグラフィック屋さんでもないのにCgいじくってひーひー言ってたのがｳﾞｧｶみたい…
まぁ、8800は素直にすげーと思うけど

これもGPGPUですか？
http://www.itmedia.co.jp/news/articles/0611/14/news102.html

ソフトウェアレンダとハードウェアレンダの境目が取っぱらわれるわけでもないのかな?

とりあえずこの傾向が進めば、GPUの扱いは
Cバス用のPC-9801-16に乗ったMC68kみたいになるわけだな。

ソフトレンダはdoubleで計算してるからねぇ。
floatでレイトレったらすごい結果になるしｗ

Mpegのエンコードにおける、動きベクトルの算出に
GPUが使えたらと考えています。
参考になるようなサイト等ありましたら教えてください。

GPGPUなMP3エンコーダー作ってください

http://www.kvraudio.com/forum/viewtopic.php?t=153073
こんなのきたよ
GPGPUでサウンド用DSP的なことをやるみたい。
この場合はDelayだけだけどｗ

オフセットしてaddするだけやん！

CUDAがでてきたから来年にはGPGPUの状況も変わるかもね。

うちの大学で、GPUでレイトレやってる人がいる・・・・

レイトレなんて久しぶりに聞いた単語だ。

>>333
一昨年俺がやったぜ
GeForce6シリーズなら十分
SM2.0だとループができないから
6800GT初売りに予約して買った。
研究費だけどね。

今だと、海外もボコスカ論文出てるから
新規性アピールするのむずいかな。
あ、研究とは言ってないのか

ごめん、GPUじゃなくて、PPUっぽい・・・

GPUPPURか
http://d.hatena.ne.jp/gpuppur/
最近進捗ないけどどうなんだろうね。

ファミコンのPPUを演算に使うのは難しそうだけどな。

ソフト的に倍精度の研究やってる俺がきました
2007年後半にハード的に実装されるみたいですねー

>>337
レイトレーシングでStanford bunnyとかレンダリングできるけど、遅い。

>>339
あの，大変申しにくいのですが
今年のSIGGRAPHのポスターでドンピシャなのが…
Extended-Precision Floating-Point Numbers for GPU Computation
http://cs.allegheny.edu/~thall/

悪気はないんです，担当教官から言われるよりはよっほどマシだと思いますし．
頑張ってください

>>342
俺ｵﾜﾀ＼(＾o＾)／

読んできました。
難しい内容じゃないし誰かがやっててもおかしくないですよね
近々中間発表があるのでそれまでになんとかしないと・・・
情報提供ありがとうございましたm(_ _)m

すみませんお聞きしたいことが
nvidiaのCg言語はATIのチップ上でも動くのでしょうか？

GPUプログラミングをやってみたいと思っているのですが
手持ちがATIしかなくて

>>344
ATIのチップでやったことないけど、できたと思う。
NVIDIA SDKでも落としてサンプルを走らせてみたらいいと思うよ

>>345
ありがとうございます。試してみますー

CUDA使ってる人居ません？
興味があって、GF88GTSのメモリが少ないやつを無理して買ってきたんですけど
コンパイラが手に入らない・・・orz

もしかして、ベータテスターや関係者じゃないと、まだ配ってもらえない？

落としてないから知らないが、CUDA Toolkit Version 0.8に
コンパイラ入ってないの？

＞The Toolkit includes standard FFT and BLAS libraries, a C-compiler for the NVIDIA GPU and a runtime driver.
って書いてあるけど。

GPUで汎用コンピューティングを行うスレ
http://pc10.2ch.net/test/read.cgi/tech/1167989627/16

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

>>347
お、動いたら感想よろしく。

昨日か一昨日くらいにCUDAコンパイラのパブリックベータが始まった。
誰でも落とせるようになったはず

情報THXです！

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

早く64bitバージョンでませんかねぇ・・・。

>>352
英語版のnVIDIAのサイトからGO!
日本語版のサイトのvistaドライバのページは何故かNot Fount
多分最新のドライバ入れれば、有効になると思われ。
Vistaでは試してないけど、XPのx64でCUDA SDKは使えたから・・・(ただしグラボがGF66なのでインストールしただけｗ)

Supports Linux and Windows XP operating systems

とかいてあるからVistaはまだ無理なのかも

NVIDIA CUDA Homepage
http://developer.nvidia.com/object/cuda.html

Vistaまだっぽいな。。

とりあえず動かしてみたいけどG80廉価版待ち

初歩的な質問です。
GPGPUにチャレンジしてみようと思い、BrookGPUを使ってるんですが
ループの並列化がイマイチどのようにすればいいかがわかりません。

例えば、ループの部分で前回回した処理結果に加算を行う処理をする場合
前後関係が出てくるので、GPGPUに適した並列化は出来ないと思うのですが、こういうのは何か解決方法があるのでしょうか？

int i;
float x[1024];
x[0]=1;
for(i=1; i<1024;i++){
x[i]=x[i-1]*i;
}
みたいなやつの事？
そもそも、この手のはGPGPUに向かない。

>>358
依存関係がなくなるように計算式を変更するか、
並列させる方向を変えるような工夫が必要。

でもって、そういう工夫は実はSSEを使ったベクタ化やOpenMPによる並列化にも適しているので、
ますますGPUを使うメリットが活き難くなる罠。

並列計算はいいんだけど
計算の中間結果を保持する為の
テンポラリバッファが大きくなって
すぐ頭打ちになりそうなイメージ

演算精度が悪すぎて使い物にならない印象しかないんだが…。

明日G80にダイブしてみるよ！
飽きたら速攻で売り払わないと

>>362
http://mypage.odn.ne.jp/www/k/8/k8_hammer_trans/files/Hammer-Info.html
もうじき倍精度サポート
現状でも型としてはサポートしてるからコーディングは可能

>>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には向かないってこと？

その処理は、コンパイラが優秀ならばCPUでもGPUでも
まあまあ効率よく実行されそうだが。

>>365
その処理は問題ない。むしろ超得意なくらい。

>>365
それは前後の処理結果は関係ないでしょ。
imgに代入するならともかく、imgと言うデータがあらかじめあるのなら、そのままVRAMに転送すりゃいいわけだし。

>>365 を Cg で書くとどんな感じ？

今はCgよりCUDAの方が。。。
まぁ古いGPU(俺を含めて)の人には仕方ないが。

>>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の内容を開放する関数は無いのかな？

じゃあCUDAで書くとどうなるの？

>>371
手抜きするなーｗ
外側のループもはずせるだろ。

いや、面倒だから俺はやらないけどなｗ
VRAMは自動開放だからな…、俺もよくフリーズさせてしまう。正確にはフリーズじゃなくて単に低速化するだけなんだろうけど
プロセスも殺せなくなるのが嫌だな

Brookでやるからだよ。
頑張って自分でCgとか使ってゴリゴリ動的にメモリを管理するんだ。
って言うか、あれは隠蔽されすぎてて何やってるのかわからんし、パフォーマンスが出るような組み方ができないので
遅すぎる。BrookGPU使ってCPU処理より速い処理ってかけるの？どう頑張ってもReadBackである意味速度差がつけられちゃうよ。

何度見てもスレタイをゲプゲップと読んでしまう

ぐぷぐぷってよんでる

intからfloatへの変換で+/-32768.0の範囲へ正常に変換できる様にGPUで計算したいのですが
CPUだと、
hoge*(1.0 / ( 1L << (8 * sizeof(int) - 16)));
一般的なWintel環境だと、hoge*(1.0 / (32768.0));
だと思うんですが、GPUだとこのままだとint型とfloat型の扱いの違いか、正常に変換出来ません。
GPUでやる場合、どういう風にすればいいのでしょうか？

あ、ｽﾏｿ
単純ミス。。。

GPU側にfloatで値を渡してたから、2重に変換されてた・・・

GPUにint型をfloatで送っちゃった時点で、桁落ち発生するでしょ。

桁落ちするの？

assert((float)0x7FFFFFFF != (float)0x7FFFFFFE);

Brookもint型が扱えればな…。
floatとintだと、個人的にはfloatの方が高度なものだと思うんだけど
なんで、float扱えて、int型が扱えないのかなぁ・・・

>>377
キャストしてGPU側に送って、GPU側で更にint型にキャストじゃ駄目なん？
って、GPGPUの言語名に使ってるかわからんけど、大抵intは無理なんかな

ところで、おまいらAMDのフュージョンは期待してますか？

AMDはコンパイラが期待出来ないから駄目
ここは嫌でもIntelやnVIDIAと共同で第3機関を作り、命令セットの仕様を管理させた方が良い。

じゃなきゃ3D NOWの二の舞さ。
どうせIntelもGPUコアとの統合を考えてるんだろ？
そうなった場合、どうせどこかで命令セットが共通化するんだから(しなかったら終わってる)
最初からそういう機関を作っとけよ。

そうなるよりチップセットにプログラマブル演算機能があった方がいいな。
メインメモリへ近いしCPUである程度処理して
並列化できる処理ではCPUがそのメモリアドレスを投げて
結果をCPUに戻すかGPUなどのバスに転送させる。
定数時間で出来る処理ならメモリ転送の代わりにできる。

チップセットにCPUくっつけたらいいんじゃね？

>>387
すでにAMDのCPUはメモリに直接つながってるからその状態では。

>>385
> じゃなきゃ3D NOWの二の舞さ。

AMD64はよくがんばったと思わないか?

あれは先にIA64が大コケして自爆しただけ。

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

>>389
あれは殆どマイクロソフト主導じゃん
ＭＳの戦うプログラマの人がAMD64自体の開発に関わってたし

後は、あれはあくまでx86命令の拡張で、今までのCPUの延長線上のものだが
今回のフュージョンは、アーキ的には全然比べ物にならないくらいの大改造だから…

CPUコアに統合されれば、GPGPUの最大の問題点であるReadBackの遅さが解決するな。
そもそも、CPUの命令に自然に溶け込む形みたいなので、GPGPUとか意識せずとも、勝手にコンパイラがやってくれそうな気もする。

粒度はどんなのになるんだ？
現行GPUでいうところ quad とか batch とかにあたるもの。

自分でループ展開して並列化して、各GPUをプログラマに管理させたりしてｗ
まぁ、コンパイラが勝手にやってくれるんじゃないかな。
それ以外の場所は、一般的なクラスタリングシステムみたいにやってくれるって事はないと思われ
そういうことは研究されてるけど、まだまだ一般的なコンパイラ1発でやってくれる仕組みは完成しているとは言いがたい。
最適な粒度をコンパイル時に調べてくれるとかやっても、別環境で実行する場合変わるしなぁ。

いや、俺が知りたいのは、それぞれのユニットがプログラムカウンタを持つのか、コプロセッサ命令でシェーダアレイコントローラに命令するのか、ということなんだ。
全部のユニットにプログラムカウンタがあったら、そりゃサブプロセッサが沢山載ったマルチコアでしかないじゃん。
コプロセッサ命令になるにしても、拡張命令で１度に１つのユニットに１命令送るだけじゃ意味ないから、適当なグルーピングが必要だと思うんだけど。
x86ISAの拡張ってんだから、後者ではあるんだろう。
で、その粒度はどんなのになるんだろうな、と。
>395 の話題も面白そうだけど、他のプロセスなりスレッドとのユニットの取り合いとかも考えるとやってらんないね。

偉そうな口調で頓珍漢な事言ってる人は、出て行って欲しい。
んがぁ、無理なんだよね。

ひろぽんは、殺伐とした方が情報の濃度が上がるとか言うけど、
白痴や馬鹿が沢山いるのに、そりゃああり得ない話。
頓珍漢なこと言ってると理解出来るレベルの人にとっては、
その情報って情報価値を持たない情報だったりするし。

日本語でおｋ

ウォッカはストロワヤが一番。やっぱりウォッカはロシアだね。
スレ違いスマソ。
自分の、これはダメかもわからんねは、
バイクで50キロぐらいで2車線目を走っていた。
するといいきなり目の前に1車線目に止まっていた車が右に、
フルブレーキするまもなく追突（前輪あたり）
10m程飛ばされて頭、ほんとにてっぺんからアスファルトに直撃。
その瞬間首が変な方向に、ぐにっとなった時。

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

これはだめかもわからんね・・・

朝鮮語でおｋ

>>397
流れ的に俺のことなんだろうが、フロントエンドにしか興味ないのか？

ネットワークのスレとかにも現れる
「おまえらバカばっかりだな」系の人だろ

もちろん具体的な議論はしません

>>401
何処の人か分からないけど、ごめん。
イント、フロートでごちゃごちゃ言ってた人のこと。

それも多すぎてわからん。

【キーワード抽出】
対象スレ： GPGPU
キーワード： イント


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


抽出レス数：1

イント人もびっくり

GPUってCPUに取り込まれて無くなってたよ。
CPUは、FPUとSPUとGPUで構成されてたよ。

>>396
「何時の時代の人だ（と言ってもたかだか数年前だが・・）」的な
ことを今更「俺が知りたいのは」とか書くから荒れる。勉強しろ。

>>408
url か検索ワードくらい教えてくれ。
英語でなんて表現したらたどり着くのか見当も付かん。

【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ではない。
たしかに正しい。
でもこの視野の狭さがアホな言動につながるのです。
プログラムから見るとどう見える?
概念レベルではどう見える?
そんな視点は一切ない。

GPGPUの研究発表を聞いた
CPUのみに比べて若干早くなっている程度
たぶんプログラミングレベルが低いのもあるんだろう
コストパフォーマンスについて聞いたら
「将来的には」を連発してた
CPUよりコストパフォーマンスの伸びが良い予定らしい

だってさ、1度でもGPGPUでコーディングした人ならわかるでしょ。
GPUを活かせる箇所が少ない事に…。
GPUといえども、1つあたりのストリームプロセッサの能力はCPUに比べて鼻くそだし、ReadBackのコストも馬鹿みたいにかかるんだから
並列化できなけりゃ意味がない・・・。そんな都合の良いループ部分が現状のコードや計算式見てそんなにあるか？

早起きなのか徹夜かどうかはさておき、さっそくどうも。

うちのソースは機械系で有限要素的なので割とあるんだな。
PS2の時に1GFlops程度出たけどP4のSSEにトータルで負けた。
CellとGPGPUは期待してるけど過剰期待は禁物だと思ってる。
いちおうGeForce8800買ってみるよ。
Cellはソフト作る気にもならないのでライブラリ充実待ち。

私のところも並列できる応用は色々ある。
実際、ClearSpeedやXTrillionのようなアクセサレータボードで速度が出ている。
それらに較べれば、コストはGPGPUなら桁違いに掛からないわけで。
#CELLも評価対象になってるけどね。

ムダ毛対策にもGPUによる並列処理が効果的らしい。

>>415
全身大やけどしました

>>412
動画のエンコードだと1つのキーフレームを1つのストリームプロセッサに
担当させることによって、簡単に並列化できる。

標準的なグラボは
VRAM128M
ストリームプロセッサは64基

１コアあたり2Mしか使えん。(それ以前に128M丸々使えるわけが無い)
丸々割り当てるのは辛いんじゃないか？

メモリ容量は768MBを想定してたから確かに128Mの場合は辛いなぁ。
GPU側のメモリを使いきるごとにCPU側のメモリに渡すというやり方で
なんとかなりそうな気はするけど。

完全にCUDA世代のグラボ前提の話になってるな
まだ遠い話だ・・・

ttp://fah-web.stanford.edu/cgi-bin/main.py?qtype=osstats
GPGPU遅いとかいうのはnVIDIAのG7x前提だからだったんだね・・・

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

1台あたりは
PS3 30GFLOPS
GPU 60GFLOPS

そのCellもフルパワー出てるかわからないけどね

>>421
俺、G7xに限らず、G80でも試したが、結果は似たようなもんだったぞ。
ぶっちゃけGPGPUは、もはや言葉だけが先行した流行りモノに過ぎない気が・・・

実際、BrookGPUとか使えばC使える人なら簡単にGPGPU出来るようになったのに
誰も使ってないし、使ってる人は割りと失望してる人が多い・・・

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同様遅いのかな？

上手く全てのコアを綺麗に動かせれば、当然差が出るけど
実際の場面で、汎用処理でそういうことをするのは難しい。

姫野ベンチのようなプログラムだと差が出るだろうけどな

いい加減ナントカシェーダという呼び方はやめなさい

既に定着してしまっているモノを変えたければ、
より多くの人に共感してもらえて説得力のある代替案を出さなきゃ。

David Kirk 「この命名はおかしいと自分も思う。Shader(プロセッサ)はプロセッサと呼ぶべきだと思う」
http://pc.watch.impress.co.jp/docs/2006/1121/kaigai320.htm

nvidiaはストリームプロセッサと呼んでるじゃん

シェーダーって元々影処理専門だったんだっけ？

それはシェイドシェイダーユニットの役割ですね

shade (r)だから影erみたいなもんだろ。

元が3DCG用語だからな
それをgenericな用途に使おうとしてるんだから
呼び方に違和感が出てくるのはしかたあるまい

3DCGの範疇であるvertex shaderの時点でもうおかしいわけなんだが

ピクセル影er
頂点影er
プログラム可能な影er

CG用語のシェーダーっていうのは凄く広い意味を持ってるからややこしい。
基本的に与えられたデータを元にピクセル出力するためのプログラムは全てシェーダー。
頂点処理をするのもそうだし、毛を生やしたりするのもシェーダーと言ったりする。

「シェーダ」は元々はRenderManとかmental rayとかの用語でしょ

vertex shaderはピクセルの出力と全く関係ないような

CUDAを使ってトリップ検索させると速いですか？

そういうのには向いてません。

高速にcryptを実行するってのは前に試したけど
いい感じにかきなおせなかったわ。　

ちなみに、cryptの能天気な話は
ttp://www.gpgpu.org/forums/viewtopic.php?p=4642&sid=fa945081fc53f719b6da6ade288b0ac8
ここみてちょ。
ここに載ってるパワポは見た上で試したが…。

こいつら、分かってて書いてるんだろうけどさ・・・。

>>439
8800GTSで試したんだけど遅くはないけど激速じゃない。(4M程度)
コストパフォーマンスではC2Dよりちょっと分が悪い。
春に廉価版が出揃って、CUDAのバージョンが上がったらモノになるかな?

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

>>440
俺はLUTで試したけど、MP内にてLoadネックで
並列度が頭打ちになってる感じ。>>440が試した結果をもすこし詳しくきぼん

■後藤弘茂のWeekly海外ニュース■
CPUとGPUの大きな違い
●汎用コンピューティングで近づくCPUとGPU
http://pc.watch.impress.co.jp/docs/2007/0326/kaigai346.htm

>>442
C2DでもTrip-Monaで500k程度だから4Mでも十分じゃん

やきとり屋さんだよ

utripperはathlon64 2GHzで動かすよりCeleron 1.3GHzの方が速かったんだけどそんなもん？

アレはキャッシュのレイテンシ依存だし



PS3で10Mうめぇｗｗｗｗとか言ってるの俺だけ？

>>447
Cellで？

RSX使わせてくれないから、まあそうなるかな

>>442
GTSで4Mか。
GTXのSLIだとどれぐらいになるかな…。
また、理論ピークと、トリップ検索の性質を鑑みるに、まだ性能向上の余地はかなりありそう。
今後に期待だ。
まあカネも電力もバカみたいにかかるけど。

[email protected]×2でTripcode Explorer v1.2.3を動かすと10.3Mtrips/sらしいので、
Woodcrestを二機積んだマシンでGTXのSLIを使えばチョー最強？

（・∀・）

>>450
電源が死にそうだね。つーか、熱対策か。

CPUはClovertownの50W版でよくね？

取り敢えず、8800GTXの動く環境はできた。
#CPUは1coreXeonだけど。
さて、来月から実験だ。

ttp://sourceforge.net/project/showfiles.php?group_id=96847
brookgpuの更新が止まってるように見えるんだけど、
とりあえずダウンロードしてみた。
サンプルプログラムどこ？
仕様はわかったんだけど、動作イメージが掴めねえ。

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)

PeakStreamはCTMしようか

>>455
ヒント：brook/prog の下
あとここの解説も分かりやすい。
ttp://www.mi.tj.chiba-u.jp/~hamano/brook/sample/sample.html

つか、外人が思い付きで作ったｷﾓｲ言語使うのはヤメロ。
nVidia様の作られた環境だけを支持したほうがいいぞ

実質BrookGPUは、Cで記述したソースをnVIDIA様が作られたCg言語にコンバートするシステムなわけだが…。

>>459はCUDAのことを言ってるのだろう。
たしかにあれはいいと思うが、世の中全てがnVIDIAチップじゃないのが問題。
家の中でnVIDAだけに絞って開発するならいいが。

>>460
でもFolding@homeでそれ使ったらまともに動かなかったんだろう。
そのマクロ言語が悪いんじゃなくて、ビデオカードが向いてなかったんだろうけど。

>>460
CVSだとCg,HLSLに加えCTMが。

現状だと
・キモイ新言語（CUDA,Brook,CTM?）
・ぶっちゃけ使いやすくないグラフィックス記述（グラフィックスAPI＋シェーダ言語）
しか選択肢が無い件。

汎用性汎用性とか言いながらグラフィックス記述でプログラミングしてるけど、
GPUのアーキテクチャにひっついたキモイ新言語がGPUの性能を一番引き出せるんじゃね？
という不安が拭えない。

CUDAには数値演算ライブラリもついてきたんじゃなかったっけ?
それが使えるもんなら、自分で書いてたらバカ見るなぁ。

つうかCUDAでいいじゃん、あれ将来的に完全に整数演算できるぞ
今はおもちゃ用だから科学計算じゃ糞だけど。ゲームとか軽い計算ならできる。

BrookGPUで満足しているが、
あれを使うと、簡単だけど細かい操作が出来ないから
並列コンピューティングの技術やアルゴリズムが殆ど使えない…。

結果、リードバックの速度とか、GPUのマイナスの部分ばっかりが出てダメダメになるな・・・

>>467
X19XXではうまく動いているみたいだよね＞Folding@home

てか、「ストリームプロセッサ」として売ってるものそのまんまじゃね
AMD Fusionにもあれがほぼそのまま搭載されるとか

>>467
BrookGPUが細かい事出来ないのは同意だけど
元々各シェーダーユニットを管理して並列化を効率化する事は出来ないぞ。
ベクトルプロセッサだから、そういうものだ。

うん、綺麗に管理できると良いんだけどなぁ…。

いやだからCUDA使えってあれなら俺等が求める
世界を追求できる。とりあえず、Geforce8600買ってみろ

上のほうにある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ないんで何ともいえないけど。

R580でやってるfoding程度はG71でも可能だがパフォーマンスが出なかった
G80ではどうなんだろうな

CellでPCの数百倍ってちょっと信じがたいんだけど
レジスタ本数が重要とかってこたないよな？
nVIDIAのシェーダってレジスタ少ないんじゃなかったっけ

>>472
おれもそうだけど、まだG88を買ってるやつがほとんどいないんじゃないかな。
おもちゃとしてはちと高いし、入れるとうるさいだろうし。

>>347がOS 32bitに載せ替えてくれればいいんだけど、それまでは皆次世代廉価版
待ちなんだろう。

>>347
つかおまえ、金はあるが知識無さ過ぎだろ？Linux入れろベンチ取るぐらいの駄コード書くのに
何64bitとOSにこだわり持ってるんだ？お前なら、RE買うのお金がないのですがとか言いそうで恐いけどなw

俺なんかXeon買う金ないからPS3買ったくらいだｗｗ
はやくRSX使いたいｗｗｗ

おれはNXT買う金がなくてRCX買ったよ

>>477
そのRSXって、要はG7XXXだろ。あんまり使い途ないんじゃないかなあ。
X11周りを作り替えるってんならありがたい話だが、あんたそういうのできる人だっけ？

出来ない人。
むしろ描画のHWアクセラレーションが利かないのが痛いの。
欧州ギークならなんとかしてくれる・・・と思いたい

>>480
Linux板で人の話を聞かずに無駄金使ったな。

GPU使えないって言ってもフレームバッファは使えるし
X立ち上げて普通に使う（FireFoxでWebブラウズしたり）分には特に問題ない。
意外と使えるんでびっくり。

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

今使えなくてもアップデートで使えるようになる可能性もあるし。

まともにニコ動が見れないWebブラウズなんかいみねーよ

Flashが見れないのはPPC Linux用Flashプレイヤーが提供されてないからで
PS3のせいじゃないだろ

>>482
わかってないね。
Linux板で言ってたのは、鯖機のつもりで使えば、何の不満もないだろってことだよ。
コンソールはおまけ。おまけがそのうち化けるかもしらんけど。

取り敢えず仕事用にHPの中古EWS調達して8800GTXのボード入れているけど、五月蝿いとは思わないなぁ。

立ち読みしたPS3 Linux雑誌によるとnVIDIAはPS3 Linux用ドライバ作る気零らしい。
署名しかないのか。。。？

GK「トップガンならやれる」

>>486
＞HPの中古EWS
それ、Netburst Xeon機だろ。
足下に2台あるけど、（ヘッポコカードとは言え）ビデオカードの音などまったく気にならない。
でも、「五月蠅くない」ってのとは違うだろう。
こんなの自宅で使いたくない。

>>487
今のところRMSの言の通りだね。
業者の非openなドライバに依存していると、いつかテメエの首が絞まる。

能力の低いopenドライバと能力の高いclosedドライバの
両方があったら俺は後者を使う。
使えなくなったときに移行すれば良いだけだし。

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.

ネタもとの日付が気になるが
Fusionにはたしかに、でかめのキャッシュかレジスタが必要でしょうな。
EDRAMとして使えばXbox360は軽く超えてしまうのか・・・

Fusionの話かと思ったが、Socket FのGPUの話け？

BrookGPUって、実行環境で環境変数設定しないといけないけど
あれって凄く不便なんだよなぁ・・
例えば自分の配布ソフトに組み込みたい時とか・・・

環境ごとにバッチファイルでも作ればよくね？

つかCUDA以外全部失敗とみなしてもいいほど糞だ。
オナニー言語とかマジ作るのやめてほしい見てると
イライラしてぶっ潰したくなってくるよ

Cgがあの有様なのに、今度はCUDAに期待しろとなｗ

8800を汎用計算で速度計測したサイトが見つからないんで、教えてほしい。

8800にあんまり魅力を感じないんだけど研究する価値ある？

>>499
CUDAが動くのが8800しかないから。
今更後戻りはしないだろうから、新世代毎にCUDAが使える
ビデオカードが増えてくるはず。

AMD X19XXはBrockGPUでも使い物になることがわかった(folding)
nVIDIAがどういう状態なのかわからないんで。

CUDA_SDK入れてみたけど、サンプルが動作確認的なのばかりで
パフォーマンスが目に見えるようなのが無くてちょっと寂しい。

ゲーム用途でなんだが
いわゆる、プロシージャル処理を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もトンボのデモでやってるっぽいけど
インパクトは・・

>>502
絵の話はよそでやってくれよ。

とりあえずBrookGPUがなぜユーザーに環境変数を設定させる方式にしてるのかが疑問だ
ライブラリの初期化のときにパラメータを与える方式にしない理由がわからん。

bgInit(BG_OPEGL);
みたいにさぁ

>498
自分でやれば、論文かけちゃうぞ。

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


っていうかCUDAがあるのにBrookGPUを使う意味がわからん。
特定の処理に関しては楽なのか?

CUDAを使うにはGF8シリーズが必要だろ
BrookGPUなら、プログラマブルシェーダーを搭載していれば、主要なGPUで動く

GPGPUの壁の一つにそういった汎用性の問題があるよね。
ATIのいう業界標準のAPIに期待。

ATIの業界標準APIってなんだよｗ
標準にならないと、所詮CUDAと同じ

業界標準で言うと、nVIDIAのCgの方がマシ
あれはシェーダー搭載している主要グラボにほぼ対応している。
純粋なGPGPU用の言語ではないけどな。
んで、Cg用のコードを吐き出すBrookGPUがまだマシだとあきらめて使われてる理由でもある

汎用演算が今後広く普及したとしても、
nVIDIAとATiでなかよく一つの業界標準言語を作るのは無理だろうね。

MS（の強要）頼みかな。

SPEのISAは普及しそうにありませんか？（本音：糞食らえ

Cgは一応MSも噛んでるな
しかもATiでも的でも使える。
CUDAもそんな感じにするんじゃないの？

自作板で見たんだが、こんなもんがあるんだね。誰か使ってる？

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

.NETかよ

Ge86発売日に意味もなく東京に行く出張入れることを成功したぜ。
上司になんでこんな時期に本社へ出張必要なのぉ？って怪しまれたが
気にしない。CUDAするために、２枚購入してくるぜ。

SLI　CUDAできるのかな？

出張期間延長で
通販にしとけばﾖｶﾀｰ
と嘆きつつPC一式調達してホテルでいじる>>514に乾杯!

ttp://www.kohgakusha.co.jp/support/rtmshadr/index.html
ここのソース試した人いる？

ＶＣでまともに動かないんだけど

もうすぐGF8600および8500が出る。
それからが本当にGPGPUが普及するかの正念場だな。
8800はヘビーユーザーだけの代物だったが、8600や8500は十分一般ユーザーの手に入る価格帯だし。
まぁ、その分ベンチは散々だが、所詮ローエンド

まぁ、このスレ何気に4割が俺の書き込みなんだよなぁ・・・。
その状況から言って、やっぱり寂しいものがあるよなぁ。。。

おまいさん>>131か？

毎日スレ更新してるのでバンバン書き込んでください＾−＾

まだ手を出すのは早いからな
デフェクトスタンダートが決まりつつあり
日本語ドキュが整備されつつあるぐらいでも
十分遅くない、経験的に

>>514-515
CUDAのforumに、GPUが非SLIで複数ささってれば全部使うよー、って書いてあった気がするんだけど、ソースを失念。

そんな(消費電力とスペースの)恐ろしいことはできないw

最近のGPUは前世代の2倍のパフォーマンスだけど消費電力も2倍って感じだからなw
ATIの新しいのはビデオカードだけで250Wとか酷すぎる。

8800GTXなんて、+12V電源を30A用意しろと書いてあるよ。
単純計算するとそれだけで360Wだ。
#実際、ボード上に+12V用6pin電源コネクタが二つもある。

CPUのように消費電力が通常の半分で値段が通常の1.5〜2倍の
製品を出してくれれば、一般的な開発者もGPCPUの検討用に買ってみようか、
というやつが増えると思う。
次世代では両者とも検討してほしいところ。

・・・と思ったが、250Wやら300Wやらじゃ、半分でもNetbust「全盛期」かそれ以上だ。
んなもん、ゲームもしないのに買ってもアホらしいな。

計算終わった後に「チーン」って音しそうだな。

おい、CUDA SDK 0.81 あるぞ。

あるぞといわれても

取り敢えず拾った。

>>529
THX!

>>529
ｱﾘｶﾞﾀﾏｷﾝ ( ´∀｀)ﾉ⌒ω)Д`)ﾌﾞﾆｭ

けっこうCUDA使い＝8800使いがいるんだね。
簡単な結果でいいから、報告してくれないかな。

おれCUTA使い

( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )ﾋｿ

>>533
なんか適当なベンチマークないかね。
nVideaのサンプルは動作確認っぽいのばかりで動かしても面白くないのだけれど。
#つーか、私も作らないとなんだけどね(苦笑

SDK 0.8だと、どうしても一塊のデータをわっと処理するバッチ系の
サンプルしかなかったので、俺の場合まだまだ基本性能を評価する段階だった。
NVIDIA FORUMでは、「演算サーバみたいなもの組めねえぞｺﾞﾙｧ」なトピックがHotだった。
>>529は俺なんだが、今別の遊びをやってるのでCUDAしばらく棚上げだ。
他の誰かがほげってくれるのを待つ!

>>533同意
とりあえず>>424の姫野ベンチの結果が知りたいな

Linuxだから無理。
じゃないけどBrook入れてないからめんどい。

実行だけならBrook入れなくても
出来るよ。

>>533
つーか今CUDAって8800以外で使えるの？

ｹﾞﾌｫ廉価版出たけどあまりにも性能差が差別化されまくり。
それでも、エミュよりマシだと思えばいいのか。

8600が出ましたよ。

質問です。
ifやswitchなど条件分岐を一切使わずに汎用プログラミングを行うと言うのがかなり理解出来ないのですが
一般的にGPUでのプログラミングでは、この辺はどのようにしているのでしょうか？

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

>>544
分岐の分だけmain()を作る
今はもうレガシな手法になりつつあるが。
当然個々のフラグメントプログラムは
画一したフローを踏むことになる。

>>545
一瞬びっくり！という感じだけど、やっぱりわからない。
if文は普通にc++で書いて特定の箇所で飛ばすのに比べて、
mainたくさんというのは、どういうメリットがあるの？

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向けプログラミングでも同じ
（最近は分岐予測のほうが賢くなってるから一概にはいえないけど）

>>547
>>545の話はそういう話なのかい？
＞mainじゃなくてもサブルーチンでもいいけど
あんたのコードで//HogeHogeのところで別プロセス呼んでたりしたら、
普通は頭がおかしいコードだと思うよね。

プログラムって基本的にループの塊なんで、

むしろループがプロセスの単位だと思ってくれ

いやさ、おれもコード書きのはしくれなんで、forkくらいは使うけど、
>>545のはGPUを使うときの独自の流儀の話をしてんじゃないの？ってこと。

ちなみにGPUにプロセスの概念はない。GPU上でOSは動かないだろ。

たとえばJPEGの量子化なんかだと、除算値を定数化できれば大幅に高速化できるわけで。
でもコンパイル時には不定なわけで。
でも除算値毎にEXE作ってたらアホらしいから、普通のCPUだと、動的に命令コード生成したり
する。一般人はこんな面倒なことやらないけど、トップガンの常套手段ね。

でもGPUだとそういうことできないから（CPU側でやれば可能かも）
モジュールを複数作ってパラメータにあったのをロードすると。
そんだけの話でしょう。

>>552
いちおう理解できたようだ。感謝。
でも>>547は関係ない話だろう。

スレが伸びてると思ったら糞団子かよ

トップガン(藁

分岐コストが高いなら、両方のルートを計算すればいいだけ。
そういう頭の使い方ができない香具師にはGPUを使いこなすのは難しい。

つまり下手鉄砲も数打ちゃ当たる？

弾の数が勿体ない。
スループット落ちるじゃないか。

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

早い話がIntel版Cellだな

さすが団子ﾁｭｰさん＾＾

ダンゴの一言は重みがあるな

GPUで出来ることの幅が広がるのはうれしいけど
本来のGPU的の使用には向かなくなってるのかな？
例えば、これからコアもっとリッチに、粒度をもっと細かくしていくと
行き着く先はCell+だよね。で現状CellはGPUの代わりは出来ていない。

上の奴は何を言ってるんだ?
もっと勉強してこいと言いたい。

今のGPUがやっているような、パラレリズムの特徴を利用してメモリアクセスの
レイテンシーを隠ぺいできるような仕組みがないと、PUの利用効率が悪くなって
大きなファクターでの性能向上は難しいような気がする。

個人的には David Williams 氏のいうことはあまり信用できないな。

>>556-558
ItaniumやXbox360 GPUのプレディケーションって奴では？
XBOX360なら48 shader
分岐待ちしてるのと、演算にリソース使うの
どっちが良いんだろう？
まぁ、R520系のように分岐ユニット（？）をつければ良いのかな・

G70系のように比較的大きい粒度だと小さいレジスタですんでたのが
R520系では小さい粒度のためG70系に比して大きいレジスタを搭載している。

NVIDIAはどうか知らないがAMDは更に小さくするんじゃないかな？粒度

取り敢えずCUDAのサンプルと同等の処理をgccでコンパイルして較べてみた。
3.4GHzXeonで66ms掛かる処理が8800GTXで0.23ms。
#サンプルはsimpleTexture。
こういうサンプルだと確かに速いね。
#いかん、Xeonの方はsse使ってないやw

で、Xeonでsse使ったら(ベクタ化してないけど)44msにはなった。
でも、200倍近く。これなら取り敢えず、実験でお金が貰えそうだw

>>568
ども。
Xeon Quad DPのコア当たり性能が仮にNetburst Xeon 3.4GHzの倍だとしても、
x 2 x 4 x 2 でもまだ、10倍以上か。

double演算エミュレーションのサンプルみたいのはあるのかな？

コード示さんとわからん。

GPU側はCUDAのサンプル、CPU側はそれを移植したもの。
どうしても見せろってことなら後で載せるよ。
#どうせだからこのPCでもコンパイルしてタイムを計ってみるか。

あー、載せるの忘れてた。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だった。

>>573
おいおい、そのCPU用のコードはいくらなんでも冗談だろ？

>>574
何か問題でも?
getData()はCUDAのサンプルの出力からの類推ででっち上げたから問題があるとしたらその辺かな?
transform()に関してはCUDAのサンプルのロジックそのままだからそれについては何もコメントできないけど。

>>575
CUDAで実行した場合に transformKernel() 内のすべてのロジックを
各画素について糞真面目に計算してるとでも思ってるのか？
そのCPUコードじゃGPUと対等じゃないよ。

普通に考えて、width, height, thetaのみに依存する（入力ストリーム全体に対して不変の）
ロジックは先に計算してGPUの定数レジスタに格納する、くらいの最適化はしてるだろうね。
DirectXのHLSLシェーダをアセンブリにコンパイルしたときのpreshaderみたいに。

>>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とかに依存させたら
各入力に対して毎回三角関数を計算せざるを得なくなるから劇的に遅くなるんじゃないかな

gcc、それくらいの最適化は任せられなかったっけ？
気持ちが悪いから、可読性が落ちないなら、速い方にするけど。

>>573にもう一度回してもらうのが一番手っ取り早いか。

>>579
sinf, cosfは外部のライブラリ関数で、Cコンパイラはその処理内容を知る立場にないから、
for文の中にある関数の呼び出し回数を勝手に減らすような最適化は普通しないと思うよ。
インライン関数だったらそういう最適かも可能だけど。

うい、流れは理解した。
明日にでも試してみる。

>>580
gccはsinf()はインライン展開しないようだね。
このテストじゃないけれど、iccはsincos同時に求める専用関数に置き換えるくらいのことはする。
iccの方は現在手元にないから水曜日になるけどテストしてみま。

>>581
投げてばっかりで悪いけど、よろしく。
8600でも買おうかと思ってたけど、unitが半分のはずが1/4しかないんでちょっと萎えてる状態。

CUDAって、Vistaにまだ対応してないよね？
あと、XPはx64にも対応してないけど、これってネイティブな64bitモードで動かないってだけ？
俺メインマシンがVistaとXP x64とのデュアルブートだから、CUDAの導入に踏み切れない・・・。
対応してるなら、早速グラボ買って来るんだが・・・

積は最近遅くない気もするがね。

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;
　　}
　}
}

ほい、お待たせ。
結論から言うと、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出始めてますねぇ。

>>583
この辺は参考にならない?
http://forums.nvidia.com/index.php?showtopic=28716

>>585
どうもです。10msそこそこってのはCeleron1.2GHzですか？
getData（テクスチャフェッチ）はGPUが非常に得意な部分だからそこでかなり差が付いてるかもね。

Celeron 1.2GHzならメモリが遅過ぎでしょう。
あとCeleronの場合、整数だけで座標を演算した方が速いと思う。
それにしても比較するのは酷な環境。

ところで時間計測はどのように行ってます？

いや、10msはXeon3.4GHz(>568-569参照)。
そう言えば、Celeronの速度は忘れてた。

あとこれCPUにもよるだろうけど、繰り返さなくていいなら

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

の方が速いよな。
本当はループの外で判定出来るからもっと速くなるけど
とりあえずこの程度は予測分岐で賄えるだろうと怠慢。

何言ってるか分りにくいか。
ix %= width
みたいな除算が重たいから取り除くって話ね。

>>591-592
あー、それは敢えてCUDAサンプルの出力を見て合わせた。
最初は条件分岐でやったけど、確か大して時間変わらなかったように記憶している。

>>589
CUDAのサンプルの時間測定をそのまま使ってたんで、今調べたらgettimeofday()だった。

積に比べれば遥かに重いんだけど、流石にXeonでは誤差か。

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

ix %= width;

を

ix &= (width-1);

にして除算が排除出来る。
Celeronではかなり効果あるんじゃないかなあ。

上の方でも条件分岐が必要な処理に関して質問があがってたのですが
イマイチ、ぴんと来ないので質問させてください。

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

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

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

初歩的な質問で申し訳ないのですが、この辺具体的な話がイメージ出来なくて困っています。

つか、ゲッパチ買ってきたんだけどCUDA糞じゃん

普通の文字列処理とかできねーじゃん。汎用GPUプログラミングとかいっておいて
なーんもできねーじゃんゴミだだまされた。明日nvidiaに電凸しよう。

>>595のは、ちょっと例が悪かったです。
ごめんなさい(汗
ただ、他にifを使う部分は、やっぱり数式に直すしかないんですかね？

>>597
悪いってレベルじゃねぇぞｗ

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

>>596
はいはい。
使いこなせないだけですね。
文字列処理って何ですか？
文字列を数値化すれば、形態素解析であろうが、文字列マッチングであろうが
置換であろうが、余裕ですよ。

>kiの値は
>ki=1/√2 (i=0)
>ki=1 (i≠0)
単純になら、ki=1-(1-1/√2)*(i==0)
i==0の時だけループからはずすのも手だし、
テクスチャを係数テーブルにするほうが普通じゃ。

>>597
効率がどうなるかは知らんが、そういう用途ならCUDAの方が楽じゃない?

BrookGPUで各ユニットで共通の変数を利用したい場合ってどうすればいいのでしょうか？

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

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

このようなパターンです。

>>601
まず、後者の場合、reduceを使う

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

前者の場合。
イテレーターを使うんだと思うんだけど、ちょっと俺にもわからん。

って、うわ・・・
後者も間違ってる。。sumの問題じゃなかったのね。
すまん。

その場合普通に
kernel void (out float o<>){
o=o+5;
}
でいいじゃん。

>>601

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

後者は何が言いたいのかわからん。
普通で

お前らCUDAやりなさい。

ところで、CgがあるのにCUDAを出す意義って？
nVIDIAは言語の乱立を自重汁

Cgはシェーダー言語。HLSLのベースになった時点であるいていど成功。
CUDAはプログラミング言語。

>>606
はあプログラミング言語ねえ

>>595
conditional move とか select とか、そういう類の命令を持つ CPU とか GPU があるのね。
だから３項演算子とか>599のようなことで問題なし。
そんなことを気にするよりも、まずは動くものを作ってこことかどっかに投げないと、何が聞きたいのかわからんというか、何を答えても的外れになりそうな気分になって答えられない。

BrookGPUって、intは使えないよね？
データがint型で、ストリームに送る前にキャストしても返ってくる値がおかしいから困る・・・。

こういうのってどうすればいいんだ？

桁落ちが原因だろ。＞値がおかしくなる。
落ちない範囲に収めるor諦める

コーヒーブレイク
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。

電気馬鹿食いDQNカードだぞ？

これから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は、和積演算だけは、同時実行出来るんだっけ？

>>613
それは計算量少なすぎ。
明らか転送のネックの方が大きいだろｗ

>>614
CPUの時も、streamReadとstreamWriteだけやるようにしてみました。
それでもCPU:16秒でした^^;

>>615
それはつまり、GPUの処理時間は2秒ということだね。
……だからなに?

転送時間を差し引いても、演算速度がCPUよりGPUの方が遅いって話だろ

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

BrookGPUはデバッカはついてるのかな？
ブレークポイント設定してステップ実行とか出来るの？

今、主にHLSLで組んでいるんだけど
GPUデバッグがやりずらくて困ってるんけど
同じかな？

>>618
BrookGPUって、単なるコンバータだよ。
結局Cgのデバッグ作業になるが・・・。
Cgは、nVIDIAがそういうツールを提供してる。

>>613

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

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

さっさと、CUDAでも覚えるんだ。

BrookGPUなんて海外じゃもう糞確定してるって見方が大半だよ。GPGPUで
最先端いってるやつらに、BrookGPUwって感じで笑われるしなぁ。

BrookGPUはお遊び言語なのは知ってるけど
じゃあ、何が良い言語なんだ？
CUDA出る前からGPUは騒がれてたんだから、CUDA以前から扱いにくくともCPUよりちゃんと速度が出るのはあるんだろうね？

SHとか使ったが、あれは、ちょっとなぁ・・・

実際に海外の優秀なやつはら暇つぶし程度にしかいまのところやってないよ
速度云々は別にどうでもいいって感じだよ。ただできましたって感じだよね

…おい
誰も何でつっこまんの？
行列演算させずに、１次元計算させてどうするんだ。

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


本当にレベル低いな、おい…

>>624
何マジレスしてるんだよw？

行列に落とし込むくらいだったら、CPUに演算させた方が・・・ｗ

たまに出てくるGPGPUで有効な例とする
for(i=0;i<SIZE_N;i++){
out[i]=in[i]+1;
}
こういう処理を否定してちゃあ、世間のジャーナリストは嘘つきだなｗ

ttp://mumei24.run.buttobi.net/cgi-bin/upload.cgi?mode=dl&file=971

DLパス:gpu

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

誰か助けてください。

>>611
リンク先は流し読みしただけだけど。

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

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

と、思ったことを適当に書いておく。参考にならんな。

GPUはSPMDだろ。
まぁCUDAで言えばWarpはSIMDだが、いずれにしてもGridレベルのSPMD。

627ですが…反応ないですか

>>630
激しくスレ違い。
ここはコンピュータグラフィックス関連のスレじゃないよ。

…スレ違いなんですか
他スレの方が汎用コンピューティングとあったのでこちらで聞いたのですが

GPUスレと勘違いしてないか？
GPGPUスレだぞ。汎用的にGPUを使おうってスレで、本来のグラフィックス処理がらみはスレ違い。

OpenGLスレとかその辺かな。

このスレッドの人ってあかでみっくぽすとの人が多いのかな

中途半端に賢い人が多いんだよ

>>611
ttp://techreport.com/reviews/2007q2/radeon-hd-2900xt/index.x?pg=3
float MAD serial以外は、概ね速い。

最近シェーダを学び始めた者です。

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

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

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

よろしければご教授お願いします。

Cgでint4が出来れば扱えるんじゃない

CUDAは、さっさとXP x64とVistaに対応するべきだ。
俺、この2つのデュアルブートだから、せっかく8シリーズ買ったのに・・・。
これのために買ったのになぁ・・・orz

>>639
ありがとうございます。
試してみます。

ATI RADEON X800 XTで
Ｃｇの中でforやらbreakが使えないみたいなエラーが出たんだけど

これってどこで確かめれるの？

>>640
ゲフォ8800なんて買う変態がXP 32bitにするわけがないからなぁ。







本当に本腰入れたいんならVista&XP×32bit&64bit全部入りだろうけど。
とりあえずコンパイルしてエミュで動かしてみたが速度とかどうってより
operatorやらtemplateやらが通るのに吹いた

>>643
CUDAのこと? あれ、だってコンパイルにはgcc使ってるもの。

あーそりゃそうだな

ねねCUDAで

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

て処理書きたいんだけどどうやって書けばいいか教えてください

無理

なんだとぉ
ふざけるんじゃねーよ教えてくれよマジ切れするぞ
ゆとり世代は沸点低いんだよ忘れたのか？

＞ゆとり世代は沸点低いんだよ忘れたのか？
ちょっと地面に穴掘って埋まってきたら?
圧力掛かると沸点高くなるっしょ。

>>649
なめてんのかコラいいかげんにさっさと教えろよ

マジレスしてやるよ
CUDA SDKにはエミュついてるから、自分で試しヤガれ
コンチクショー

だから無理だって言ってるだろ。
GPUには、条件分岐するキーワードは無い。
予めCで分岐してから、各処理を呼び出すしかない。

じゃあ
abcdefjを128bitのhexとかに予め変換してとか小細工しても

strstr()なんかを作ることは無理なのか？

>>653
もちっと、じぶんのあたまでよくかんがえてからしつもんしよう。
ぺたっ　（もうすこしがんばりましょう）

>>654
わかんねーからきいてるんだろうが
こちとら時間ねーだんよささっと情報晒せ

時間ないなら諦めたら?

>>656
悪かった取り乱してしまった。すまいと反省している。
ね？ね？ヒントでいいかなんか情報くださないな

なかなか釣れませんね

あのー誰か教えてよぉもう2日もがんばってるけど
できないよ

>>659
そもそもなぜGPUでstring処理を行いたいのでしょうか？？

いくらCUDAでGPUを汎用プログラミング用途に使えるようになったと
言っても、やはりGPUが得意とするのは大量の単精度浮動小数点データ
に対する演算だと思うのですが。

余計なお世話だろ

すみませんでした

>>660

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

だれか具体的にいくらって数値出していただけるならうれしいのですが
そんなもん自分でやれっていわれるのはまちがいないのでCUDAで
どうやって作ればいいのかちょっと聞いてみたかったんですよ。
未だにできないでうーむってうなってますよw

>>663
CUDA SDK付属のエミュでまずは作れ。
そしたら実機で回してみせるよ。

>>663
CUDA SDK付属のエミュでまずは作れ。
あうあう？うーんうーん？エミュってどこにあるの
それいってくださいよーもー

まずはダウソしてインスコしてビルド汁
話はそれからだ

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

64bitじゃ無理じゃーん
どうしろっていうんだorz

俺もXP x64とVistaのデュアルブートだから無理だったんだよな・・・prz

>>667
欲張って64bitのマシンを買うからだ

大丈夫、漏れは64bit機で32bitRedHat入れている。
#勿論、CUDAは問題なく動く。

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はお終い。

演算アクセラレータボードを作っている会社も危ない状況ですね。
某社のボードなんか100万とかする挙句に開発環境がそれの倍以上だもんなぁ。

ねぇねぇubuntu x64環境でどうやってCUDAするの？
toolとcudaいれたけどVideoのドライバがインスコできない
なんで？

ERROR: this .run file is intended for the
Linux-x86 platform, but you appear to be
running on Linux-x86_64. Aborting installation.

とか出るのですが原因が判りません。

>>674
日本語の参考書が出るまで、あんたにはCUDAは使えない。
日本語の参考書が出たらまたどうぞ。

>>671
いやさすがに3年後でmGPUにはならないでしょ…

>>674
エラーメッセージにダメな原因がはっきりと書いてあると言うのに、
これでも文章の意味が分かりませんか。はぁーーーーー。

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

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

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

# それができないなら、675氏の言う通りだと思います。

いや、日本語の参考書が出てもダメでしょ。

>>671のサイトのはGRAPEの製作者のところなので
自分たちのシステムの優位性をアピールしたいんだろうが
その人たちですら、性能面でのGPUの優位性はもはやみとめざるを得ないと言う事だろうな。





しかしまぁ、CUDAの実行環境の話もそうだけど
さっさとGPGPUの環境整えてくれ。Vistaやx64非対応ってやる気あんのかと

一般人は、エラーメッセージの内容を信用しないって所があるんじゃね？
多分、そのメッセージが日本語でも同じ。

理由は、Windowsのような、全くもって何の解決にもなってないようなエラーを吐く環境に鳴れたせいかと。
アプリケーションの強制終了の時のエラーダンプを、アプリケーションの作者に送っても殆ど無意味だし。
ブルースクリーンのエラーメッセージをコンピュータのサポートに送っても無意味だからなぁ

おいハードディスク買ってきたから32bitOS入れるから
教えてくれるよね？

環境は今からそろえるつもりとして、はじめるとしたらCUDAとCgどちらがいいですか？

両方やれば?

ねぇねぇねぇ
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なんだけどエミュで動かせるって聞いたけど違うのかな？
カード走って買ってこないとダメ？

GPUチップを認識できてないとそうなった希ガス。
nvcc動かすだけなら大丈夫だと思うけど。

エミュ用のディレクトリのを実行した？

サンプル動いたぉ

gpgpu志向のプログラム作ろうとしてます。
ですがいきなり分からないことが、出てきました。

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

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

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

一体どれなんでしょうか？

あまりGPGPU指向の話じゃないねぇ

ちょいCUDAで質問
とりあえずCUDAの手順として
デバイス初期化
メモリ初期化（host,dev)
計算
終了処理
という感じになっているが、なんでkernelの関数呼び出す時こんな
キモい呼び出しになってるの？すっげーキモくて違和感ありありなんだが

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

こんなアフォな呼び出ししたくねーよw

その呼び出しのどの部分がキモいのか具体的にお願いします。

逆にそれだけで済んでしまうところが肝なんだが。

今エミュだけだからよーわからんのだけど
__device__と__global__って再帰呼び出し禁止だけど

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

ソース上げてくれたらテストするよ。

__device__ hogeから__device__hoge1を呼び出せないのは痛いなぁ。

inline展開できない場合は処理不可能なのかぁうーむ。これにはちと
まいったな

なぁなぁ

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

その辺の情報がいまいちよーわからんのだが

CUDAが未だにVistaやx64に対応できないのは何か理由があんの？
もうかなり経つよね。

GPGPU完全死亡
http://pc.watch.impress.co.jp/docs/2007/0611/kaigai364.htm

>>698
こんなのセルと大してかわらへん
並列度が低すぎる

IA命令セットと互換ってのがみそだろ。
どうせSSEだろうけど。

で、どれだけ広まるのよ？一般に。
GPU以上に広まる可能性はあるのけ？

そもそもGPUじゃないし
ただGPUで出来るGeneral Processingのおいしい部分は全部持ってっちゃうと思う。
x86のコードがそのまま動く意味は大きい。

しかも2009年まで出てこなんじゃ
インテルお得意のキャンセルされるかもしれないしね

てことは、一般には浸透しない可能性の方が大きいな。
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.

CPUコアがいくら増えたところでGPUの性能が落ちる訳じゃないし。

GPGPUよ、短い命であった。

そう、CPUのコアが増えたところで
GPGPUを使えば更に速くなるわけで、どっちか切り捨てるとかそういうものじゃないでしょ。
使えるものは使うと速くなるんだから。この場合は　だけどｗ

例えば今まで
CPU10 + GPU25 = 35
で処理できていたことが
CPU20 + GPU25 = 45
で処理できるならそれはいい。
なんで
CPU20 = 20にGPU切り捨てる必要があるんだ

しかも、CPUよりはGPUの方が安い罠。

30コアのCPUがいきなり一万円台で買えるとは思えないが。
よっぽど一世代前の高級GPUのほうが安く買えるかも。

PCI-Expressに挿せる超高速コプロならなんでも売れると思うけどね。
GPUでも糞INTELの石でもなんでもいいけどね

そうは言ってもClearSpeedはベンチマークスコア上げるのには
有効だが実用面ではちょっと。

あれは期待外れだった。糞高いコンパイラだけで性能出せないんじゃ……ねぇ。

「Larrabeeが登場したら、ハイパフォーマンスコンピューティングのベンチマークを
総なめにする可能性がある」とある業界関係者は期待を語る。

Larrabeeのターゲットアプリケーションは、一目見てわかる通り、GPUがGPGPU
でターゲットにし始めている領域と完全に重なる。つまり、LarrabeeはIntelによる
GPGPUの動きに対する回答だ。IntelとGPUベンダーは、ハイパフォーマンスな
浮動小数点演算性能が必要な並列コンピューティングの領域で、真っ向から
ぶつかることになる。

LarrabeeはSSL対応レイヤ3スイッチのアクセラレータや
重めのアプリケーションサーバにも向いているような気がする。
値段次第だけど。

R600のプログラム形態はSPIのStorm-1に近いかも知れん。

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つある。

GPGPUでGrapeオワタと思たらメニーコアでGPGPUオワタ

GPGPUを使った類似画像検索とか面白そうだが
どこもやってないのかな？

画像のパターン検索？ならやってた人がいたと思う

まぁそういう用途はGPGPUよりもこういうほうが面白そうだけどスレ違いか
ttp://www.k2.t.u-tokyo.ac.jp/vision/M-SIMD_architecture/index-j.html

DirectX10でGPUを汎用整数プロセッサとして使うサンプルある？

今更R600って、…MSX Turbo-R？

あれは、R800だろ。

SEGA の体感ゲームだっけ?

R3000じゃなかったっけ？
ジオメトリエンジンついてるんだよな？

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に振り分けられる。

新しい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

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は?

お、情報THX。
早速見てみなくちゃだわ。

もう完全にCUDAはやる気ないんじゃない？

うちはXP x64とVistaのデュアルブートだから、完全にアウト。

>>731
大丈夫、TesraがあるからCudaは終わらない。

こりゃあrapidmindの勝ちかな

x86_64 でXPとかビスタなんて使ってるやついたのか？

GPGPU用途に限ればLinuxでもいいのか。
CUDAカーネルの5秒制限も払拭されることだし。

残念。Larabeeの一人勝ち。

CUDAの分野とかから考えて、Vistaとx64を避ける意味がわからん。
特にVistaでは、GPUの仮想化をサポートしてるんで、まさにGPGPUの為の実装みたいなもんなのに・・・

Larrabeeは2009-2010登場のでGPU軍勢が散々広まってしまった後だ。
それにGPUは3世代進歩する。
専用ライブラリやランタイムが必要ならISAがx86である意味は薄い。
ましてや32コアを意識してプログラムを組めなんて気の遠くなることは・・・
Larrabeeだけこける。

GPU軍勢の影の総大将がMicrosoftであることは間違いない。

>>737
じゃあDirectX10.1が出る頃には対応するんじゃないか

PeakStreamを忘れないでください…と思ったけど買収されたしナァ

>>738
そんなばかなｗ
GPU軍勢って、nVIDIAだけじゃん。
結局IntelとAMDの天下だよ。

ララビー来るまでにTeslaがどれだけ普及するかだなぁ。
取り敢えずCUDA1.0を788GTSで動かすかな。

歴史的に見て、このプロセッサ(GPU)をCPUが取り込もうとして
失敗する事は殆ど無い。最終的にCPUに取り込まれるのは必然だと思われ。

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

CUDAがx64やVistaに対応しないとか、馬鹿な所で詰まってる場合ではない。
今のメリット(先行)を生かさないと・・・。
本当に何を考えてるんだか・・・。

先生！
強い電波を観測しますた！！

>>743
まー、さっさと対応して欲しいよね。
俺もCPUに取り込まれてx86になったら、人は流れると思う。
特定分野はわからんけど、それならそれでx64に対応しろよ。
何もかもが中途半端

長文いってみようか。

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

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

ってことでIntelとAMDが談合してx86にデータ並列のストリーム処理命令を新たに追加して終わりだな。
LarabeeでもFusionでも使えるとなれば勝ち決定。

と思ったがLarrabeeは全部のコアでフルx86が走るのか。
そうなると>LarabeeでもFusionでも使えるとなれば〜は無いな。

CPU/MCHどっちにくっついていようがオンボードVGAがシェーダー重視で肥大化して
いったら、逆にS3（VIA）その他の弱小グラフィックスが再び脚光を浴びる。

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

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

5年後を予想すると、HPCクラスタ界隈はOpteronやXeonやPowerPCが引き続き使われ、
クライアント環境でのベクトル演算/SIMDはSSEの進化で間に合う。

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チップ上に集積した，いわゆる
クアッド・コアである。

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を超えるロードマップわ現実的す。

変なの沸きすぎ

俺Vista x64で8600GTだけどDirectXしかねーべ？

Larrabeeってどうやって普及させるつもりなんだろうか。

最終的にはCPUと統合らしいから
普通に次世代CPUとしてでしょ。
何となくチップセットに内蔵してきそうな気もする。

っていうか、単体で出さないでしょ？ｗ
科学技術分野に出すかも知れないけど、普及版は統合かと

出るのは pcie gen 2 カードでだよ
価格は10万前後

つかストリームコンピューティングって市場がそもそもないだろ
せいぜい研究機関とか大学で細々と使われるぐらいで
結局ソフトウェアが無ければ普及しない

リアルタイムレイトレがGPUラスタライザを凌駕するとか真顔で言ってる奴がいるけど
ポリゴンとピクセルが1:1に限りなく近付くようになるならまだしも
法線マップとかのイメージスペース技法の発明でそんなことはこの先起こらない

GPUじゃないけど一番敷居が低いのはやっぱりCell?

>>757
思いっきり高い敷居を跨ぐ為に、誰もが俺様ライブラリを作っている状態ですが。

>>756
＞つかストリームコンピューティングって市場がそもそもないだろ

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

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

それ以外にも、レンダリングパスが多くなりすぎるケースや、
ラスタ処理では不可能な処理や、誤魔化していた処理、
そういった高レベルの処理を入れていくと、ラスタライザでは限界がある。
光源が増え、シャドーが幾何級数的に増加したら、従来のラスタライザではどうしようもなくなる。
最終的にはレイトレとラジオシティを組み合わせたものしか生き残れない。

>>759
> 潜在的需要はいくらでもある。

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

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

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

俺はこの先もリアルタイム3DはGPUラスタライザで変態的テクニックを多用していくことに変わりないと考えるね
一次レイと一次シャドーレイだけで息切らしてるようなリアルタイムレイトレは期待できない

>>760

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

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

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

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

つか通常のGPUで盛り上がっているし。
意見は貴重だけどよそでやってくれないかな〜？

レイトレの話はさすがにスレ違いだけど、
「GPUに対する3Dゲームのような決定的な市場」があるのなら是非知りたいね。

言う気無いならがんばるなよ。言わなきゃ論証にならないんだからさ。

>763
誰に言ってるの？

少なくとも漏れの周りでは高速に演算したいと言う要求が色々ある。
「面倒だから1Uサーバ機を100台単位で並べろ」ってのから「4core2CPUは高いからなんとかならんか?」まで千差万別。
前者の場合でも、「1U機にGPU入れればラック筐体単位で節約できる可能性がある」となれば興味を示すだろう。
(他社のアクセラレータボードに較べて)安いことは充分刺激になっているよ。

スーパーコンピュータ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台に拡大した。

>>760
＞ピクセル単位でシャドーレイ飛ばすのとシャドーマップ描画して参照するのとを比べれば

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

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

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

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

そりゃ今はレンダリング速度が遅いだけだ。
1/60秒で描画できるようになったら、逆転する。

シャドーｗｗｗｗｗｗｗｗｗ

そうなんだよね、折角「ラスタスキャンだとデータ量が増える」からとベクタデータになった処理が、
「解像度が上がるとベクタデータは級数的に増える」からと結局ラスタデータになったりしているしね。
尤も、今や8000x8000なんて画像のフィルタリング処理がオンメモリでできるからこそだけれども。

>>767
> シャドーレイなんて飛ばす必要ないぞ。

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

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

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

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

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

ラスタライザが生成するコーヒレントレイの圧倒的な速度と効率性という前提がある以上
繰り返すがRTRTが可能なほど高速なハード上では、ラスタライザはより高速に動作する
インコヒーレントレイをレイトレで処理して他は通常通り高速にラスタライザで処理するなら分かるが
大方の研究者の云う通りレイトレそれ自体がラスタライザを消し去ることはあり得ない

レイトレーシングのスレはここですか？

いちおうGPGPUネタではある。

ヲタゲーCGはもうお腹一杯。
もっと単純に、天文物理の多体問題を解くみたいな
GRAPEや地球シミュレータとの比較で頼む。

Grapeは事実上の敗北宣言が出てたじゃん。
「価格辺り消費電力が大きい」とか微妙な逃げ口上つきで。

>>770
＞誰もラジオシティの話なんてしてねぇぞ

俺はしている。ラジオシティ使わずに、レイトレでソフトなライト処理は不可能だ。

>>770
＞RTRTが可能なほど高速なハード上では、それ以上に高速に動く（＝より高い複雑度のシーンを扱える）

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

ラスタライザ型で表現できる品質レベルで言えば、そりゃRTRTが可能なハードで上で、
それ以上に高速に動くのはあたりまえ。そんなことは小学生でもわかるわ。
人間が考えうる高品質の画像を作っていく上で、無限の計算力があるなら、
ラスタライズ型の処理なんてあり得ない。
所詮、計算力が十分になるまでの、その場しのぎ、誤魔化しの手法にすぎないんだよ。
RTRTが可能になれば、ラスタライザは死滅する。パレットによるタイリング手法が死滅したようにね。

非リアルタイムのアニメ映画でさえもRTはそれほど使われてないんだが・・・

とりあえずレイトレしなくてもいいからオフラインレンダラ並の
アンチエイリアスできるようになってから話しろよ

>>777
その通り
スキャンラインラスタライザは現在でも多数のオフラインCGで使用されている

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

Larrabeeが出たら是非RTRTを実装してもらいたい
もっとも同時期の最新GPU上で動く最新デモの足元にも及ばんだろうが
品質の面でも解像度の面でもな

> 無限の計算力があるなら

この前提も妄想だな

そもそも現在の半導体のドミナントデザインたるCMOSは
20nmプロセス前後で限界を迎えるという事実をお忘れか？

>>780
忘れてないよ。でも、技術の発達により、膨大な計算量が扱える方向に進むのだから、
究極的にはどこを目指すかという点で、無限の計算力があるときどうなるかを考えることは無意味ではない。
３０年後のＣＰＵのスペックはどのレベルか考えてみるのもいい。
１００コア程度なら２０１０年前後で投入してくるだろうし。

>>779
＞品質の面でも解像度の面でもな

鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングするのでも、
ポリゴンラスタライズ型が勝てるとでも思ってるの？
想定している品質や分野を意図的に制限すれば、そんなことはいくらでもいえる。

> 鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングするのでも、
> ポリゴンラスタライズ型が勝てるとでも思ってるの？
> 想定している品質や分野を意図的に制限すれば、そんなことはいくらでもいえる。

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

自己矛盾にすら気付かん馬鹿ですね
相手するだけ時間の無駄か

だいだい反射や屈折等のインコヒーレントレイに関しては>>770で
「インコヒーレントレイをレイトレで処理して他は通常通り高速にラスタライザで処理するなら分かる」と言っているだろう

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

まさかとは思うが、コヒーレントレイに関してもレイトレがラスタライザより
高速に描画できるとでも思っているのか？

>>783
＞「想定している品質や分野を意図的に制限す」ることだわな

だから、それを言っているのだが。
矛盾ではなく、そういう例を出しているのが読めない馬鹿か？それとも意図的に誤読しているのか？
本気で俺が「制限すること」でないと思って書いていると思うなら、お前は読解力がない。

>>785
横レスだけどそんな皮相的な反応されても・・・

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

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

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

Ice Age のスタッフがRTサイコーって言ってたよとか、そういう実分野での応用に
ついて検証するしかないんじゃないかな。

>>786
＞「より制限の緩い、一般的な用途でRTの方が優秀である」という主張を内包している
＞としか思えないわけだけど、

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

現状の計算機環境、要求品質でポリゴンラスタライズ型を否定しているわけではない。
が、そう遠くない将来、ＧＰＵもポリゴンラスタライズも死滅する。コプロがＣＰＵに取り込まれたように。

「膨大な計算量」を何に使うかはデザイナやアーティストが決めるんじゃないかな。

>>787
俺の質問に答えろよ
> まさかとは思うが、コヒーレントレイに関してもレイトレがラスタライザより
> 高速に描画できるとでも思っているのか？

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

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

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

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

重要なのはいかに同時期の市場情勢や需要に適合するかであって
シンプルで正確な技術が必ずしもスタンダードとはならないことは歴史が証明している

>>789
＞> まさかとは思うが、コヒーレントレイに関してもレイトレがラスタライザより
＞> 高速に描画できるとでも思っているのか？

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

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

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

ＲＴＲＴのゲームも出てきていることだし、
ＣＰＵパワーの使い道としても俺はＲＴＲＴの今後の発展に期待する。
どっちが残るかなんて歴史が証明すればいいし、今拘る気はない。
ＧＰＵとラスタライズが死滅する方が新しい発展があって面白そうだから、
俺が勝手に思っているだけでいいよ。

ttp://www.hc.ic.i.u-tokyo.ac.jp/~kaki/SIGGRAPH2002/Panel_RT_vs_RAS.html

GPUとラスタライザが死滅するほうが新しい発展があるって思える根拠に興味が

思ってるだけでいいならだらだらと書き下すなと

GPUの応用研究で食おうと思ってたらLarrabeeが出て人生オワタような必死さですね

別にLarrabeeなり、CPUベースのレイトレなり、新しいものに期待をかけるのはいいと思うが、
なぜ、チャレンジの芽を摘むような批判をぶつけるのだろう。

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

本当に死滅するならそれはそれでいいし、死滅しないとしてもそういう別のベクトルが
頑張るのはいいことだと思うぞ。妄想が原動力ならそれでもいいじゃないか。

＞なぜ、チャレンジの芽を摘むような批判をぶつけるのだろう。

「Intel にとって良いことは、コンピュータ業界にとって良いことだ」から

>>795
2chで吠えてないで結果を出せってことだろ。

LarrabeeもTeslaもPCI-Eカードの時点で終わってる
CPUに統合されない限り可能性はない

今現在結果を出そうとすることすら叶わないLarrabeeへの皮肉ですか

このスレを一通り眺めて思ったこと。
CPUも互換性を考えなければすっげ早くなるのだろうか。

>>800
それなんてCell？

CPUに統合されても可能性はない

誰かが20nmの壁を書いていたけれど、それを忘れてないと書きつつ100コアとか書いちゃうのが信じられない。
そしてまさしくその壁と戦っている人達が、実際にGPGPUにもLarrabeeにも興味を持っているわけなのだが。

>>798
メモリ事情を考えろ
http://pc.watch.impress.co.jp/docs/2007/0131/kaigai332.htm
http://media.arstechnica.com/news.media/larrabee-pci.gif

つか俺的には何FLOPSとかどうでもいいからメモリのレイテンシを改善しろと言いたい。
お前ら何年間横這いなんだよ、と。

>>805
急に言われてもメモリも困る。
ちゃんとプリフェッチされるようなコードを書けば良い。

コードについて以外のことについてぐだぐだ書くのはやめろよ。
板違いだ。

自作板にでもスレッド立ててやれば良いだろ。

>>807
最近多いよな
こういう多分野にまたがって統合的にものが考えられない奴

>>808
どっかのいいかげんなwebサイト仕込みのネタをの適当に口まねするのが
「総合的にものを考える」ことかよｗ　アホくさ。

スレのびすぎ

で、GPGPUで犬を洗えるようになるのか?

>>804
考えた
http://amb.sakura.ne.jp/hanyou/img-box/img20070611224306.jpg

>>803
１００コアの話はインテルのロードマップのことだろ。あっちでは数百コアって書いてあったけど。

>>812
CSIが細くて笑った。

データの入りと出だけだから問題ないの･･･か？

要するにNUMAでしょ
CPU間のCSIはコヒーレントバス的に使って、たまに他のノードのメモリにアクセスする感じでは。

ものすっごい初歩的な質問なのですが

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

の、何か作業をGPUに任せるのって
プログラム側からシェーダに対して
どういうコードを描けばいいのですか？Cgで

>>816
つ[cuda]

CUDA使えるGPUではないので無理です


ナニを読んだりググれば出てきますか？

Cgで普通のグラフィックのプログラム書いた経験はある？

今やろうとしているのが、まさにCgで普通のグラフィックプログラムやろうとしてるのですが
どうもわからなくて

はじめにどこ見ればいいですか？

>>820
まずは鏡を見て「俺はなんて馬鹿なんだろう」と気付くことから始めよう。

そうですね、バカだと思います

もう来ません＞＜

ぼくもやりたーい

　　　　　　　　　　　　　　　　　┌─┐
　　　　　　　　　　　　　　　　　｜も.｜
　　　　　　　　　　　　　　　　　｜う　|
　　　　　　　　　　　　　　　　　│来│
　　　　　　　　　　　　　　　　　│ね│
　　　　　　　　　　　　　　　　　│え .|
　　　　　　　　　　　　　　　　　│よ .|
　　　　　　ﾊﾞｶ　　　　ｺﾞﾙｧ　　│ !!.│
　　　　　　　　　　　　　　　　　└─┤　　　　ﾌﾟﾝﾌﾟﾝ
　　　　ヽ(`Д´)ﾉ　ヽ(`Д´)ﾉ　　(`Д´)ﾉ　　　 （　`Д）
　　　　|￣￣￣|─|￣￣￣|─|￣￣￣|─□（ ヽ┐U
〜 〜　￣◎￣　　.￣◎￣　　￣◎￣　　 ◎−>┘◎

GPGPU.ORG

普通のグラフィックプログラムでループを1000回も回すことがあるのか
ちょっと興味あるな

1000回じゃなくて百万回では？

数百万ループって・・・
どんだけ広い空間を定義する気なんだ・・・

別に広さの問題ではないと思うけど

>>826
単に1024×1024のテクスチャの各ピクセルに対して同じ「何か作業」をしたいだけだろ

そんな低レベルというか基本中の基本のことを他人に聞く
ような神経が考えられない。ゆとりか？

基本中の基本は
どこを調べたら出てくるんですか＞＜

>>832
>825

ジャパニーズで教えてください＞＜

つ[excite翻訳]

英語読めないとかどんな低学歴…

NVIDIA最強
http://pc.watch.impress.co.jp/docs/2007/0702/kaigai369.htm

>837
お前個人は貧弱だけどな

一人一人は小さな火だが

なんでわかった？

なんだよ、お前らみんな英語読んでやってるってのかよ！
このバカバカマンコ！！！！
お前らなんかチンコの皮をチャックに挟んでしんじゃえ！！！

早く、GPUでのプログラミング教えろよ！

英語が嫌ならDirect3Dの日本語ドキュメントとかでHLSLとか勉強して、それをグラフィックス以外の用途に使えばいいやん

ゲフォ8600とか買ってCUDAするのがよろしいかと

8600GTSなら3万弱、8600GTなら1万円台中頃かな。
最早CUDA以外を勧める理由がないよ。

CUDAで使えるjava処理系だせや>えぬびでぃあ

>>844
x64やVistaに対応していないし、しそうにもない現状を考慮してもか？
流石に痛すぎるだろ・・・。

>>846
需要があれば出すでしょ。現状、TeslaはLinuxをメインにしているようだからね。
#Linuxならx64もあるわけで。

>>837
AMD K10最強
http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_13223,00.html?redir=CPBM01

8600GTでCUDAって動くの？

8800からじゃなかった？

>>816
1024*1024のテクスチャをサイズが変わらないように描画しろ。
演算の中身がシェーダ。

GPGPUのHellowWorldってまさにこれだと思うんだけどどうよ。

>>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でもいけるんじゃなかろか。

ちなみに、8600GTSでhttp://pc11.2ch.net/test/read.cgi/tech/1167989627/47とおなじことやってみたら、
概ね1/3〜1/2の速度が出た。メモ取るの忘れちゃっから細かい数字は不明だけど。

>>852
816氏はCUDA使えなくてCgでやりたいって言ってるんだから、
テクスチャの概念を持ち出さないわけにもいかないだろうに。

>>854
あ、確かに。これは失礼。

ビンゴ
http://jndb.pc.mycom.co.jp/articles/2005/09/06/siggraph2/002.html

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

とっても簡単に言えば、0x0000FFへ0x00FF00を足して0x00FFFFにする計算が、
青ピクセルへ緑ピクセルを加算合成してシアンのピクセルにすることで代用できる
って感じ?

なんかすごいのが来た・・・

>>856-857
ﾌﾟｯ

俺Vista x64なんだけどManaged DirectXが一番楽？

// 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;
}

なんかすごいのが来た・・・

>>860-861
ﾌﾟﾌﾟｯ

Vista x64用管まだー？


XP 32bitを後から入れるのもなぁ
＃Vistaのブートセクタ壊れるし。

KNOPPIXでも使ってddしろ

どっちかというとソフト作ってバンPに配布したい。
DirectX10ならVistaに最初から入ってるじゃん

→決定


だんごやさんのソフト（って言ったらまあアレくらいだ）に組み込むと言っておこう

Vista and XP x64ユーザーな俺は無関係。



CUDAやる為に、地雷と言われてたGF8600GTS買ったのになああああ
88買う財力は無かった。

まあでも、いちおうCgやHLSLは使えるみたいだし

俺はG92が出るまでCUDAは他の人間に露払いさせて
バージョンアップを待つね

それはいつになるの

その頃にはG100が発表される…

来年４月
http://pc.watch.impress.co.jp/docs/article/980402/mgag100.htm

おいおい、10年前スレかよw

俺なんてG400持ってるもんね！

laguna3d持ってる俺が通りますよ

俺なんかすでに9801だぜ

何このすれ

CUDAやるのに
マルチスレッドプログラミングの知識は必須ですか?

は？

いや、だってGPUってメニイコアでしょ。
行列計算とかを速くできるようになるんでしょ。
それってマルチスレッドプログラミングともろかぶりじゃないんですか?
CUDAのAPIっーか、ライブラリ関数見た事無いから
想像ですが。

Voodoo2買ってきたお（ ^ω^）

>>879
CUDAのSDKは誰でもダウンロードすることができるので、興味が
あるのであれば、少しは自分で調べてみましょう。
あとはGPGPUに関しては、インプレスの後藤さんの記事もとても
参考になります。

>GPGPUに関しては、インプレスの後藤さんの記事もとても参考になります。

（笑）

>>GPGPUに関しては、インプレスの後藤さんの記事もとても参考になります。
(涙目)

後藤記事は、2chにおいては失笑扱いらしいから気をつけてな。

ふつうに知識あれば彼の記事の読むべきところ流すべきところが
わかって、参考になるんだけどな。

まぁ、GPGPUをいい始めたとき
多くの人は信じてはいなかったわけだが

マルチスレッドプログラミングの知識はあるに越したことはないが、必要とまではいかない。
データバラレルくらいわかればとりあえずは十分でしょう。

【派遣ネガティブ根性チェック】

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

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

×データバラレル
○データパラレル

ちなみにgotoちゃんは
ろくなCS学位も持ってないただのなんちゃって屋さんだよ

記者や評論家が本職で無いのは当然といえば当然

安藤や大原の勝ち

安藤氏って学術関係の検索かけてみるといろいろ引っかかるけど同姓同名？


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

　サブサブテーマ３−�@
氏名 ： 安藤壽茂
所属 ： 国立大学法人九州大学 情報基盤研究開発センター 客員教授
　　　　 富士通株式会社　サーバシステム事業本部　技師長

>>889　　　　　　　　　 当然なんてのは文系のイイワケだよ。
ただ、文章を書けない理系が多いのも事実だから、仕方ない面はある。

>>891
本物のハイエンドプロセッサのアーキテクトなんすけど、知らずに後藤氏なんかと
比較してたすか？
http://mdfs.net/Docs/Comp/CPU/Archit.htm
　　------------------------
　　HaL SPARC64, 1995 - Hisashige Ando (design manager), Winfried Wilcke, and Mike Shebanow
　　------------------------

MYCOMの安藤とか書いてあるページもあるし同姓同名の別人でもいるのかと思っただけ。
とはいえ凡人にはあそこまで技術論は語れないわな。
氏の連載はそこらの院生が使ってるアカい薄い高い本よりよっぽど分かりやすい。

>>888
なにが間違ってるのかわからなかったけど、やっとわかった。
パラレルね。携帯だから視認性が劣悪で、濁点と半濁点の区別がつかないんだよね。
しかもT9変換使っているからご変換されてるとほんとわからない。

マルチスレッドの知識というより、並列プログラミングとか並列アーキテクチャの知識かなぁ。

CUDAはthreadとかwarpとかblockとかgridとかmultiprocessorとか
普段並列プログラミングで使っていない（違う意味で使っている）怪しい単語が並んでてうまく頭の中で整理できない私。
死んだほうがいいな。

>>896
つ抗うつ剤

Cgのサンプルで
パーティクル以降のOpenGLBasicのプロジェクトファイルが無いのって
仕様ですか？

パーティクルのところを見たいのに…メインのソースが無いとわかんねぇ

ぁげ

ageるなsageろ

GPGPUって、ある文字列をソートするとか言う用途に使えそうなんですが
行列を使った効果的なソートのサンプルとかありませんか？

あと、BrookGPUに手を出そうと思ってるのですが、どこ探してもベンチマーク結果のようなものが見当たりませんが
どこかに無いでしょうか？

なんで文字列のソートなんかに使えると思ったのか。
一番向いてない分野だと思うが。

そうでもないよ。
GPGPUを使ったBWTは、割と発表されてる。

CPUだと、quickだが、GPUだとバケットソートを再帰的にやるのが賢いだろうな。

>>903
割と向いた処理ってのは同意だが
GPUで再帰は無理

有るよ。
並列ソートって研究分野で、教科書も出てる。

GPUじゃないけど、SIMD並列スパコンを使って
並列ソートで速度を競う、ってのが去年くらい
に東工大のプログラミングコンテストの課題
だった。

>>905
教科書ともし公開されてたらプログラミングコンテストのソースがあるところを教えてほしい。

NVIDIAならCUDAのサンプルにbitonicソートのサンプルがついてるね。

"文字列"のソートにGPGPUが向いているの？

文字列だって、結局数字に落とせるでしょ。
しかも、文字の配列として扱えるので、行列処理に強いGPUには格好の演算対象
もう少し動向を勉強してきなさい。

せっかくの浮動小数点演算パワーを整数配列のソートという
しょうもない用途に浪費させることのナンセンスさを言っているんだろうｗ

GPGPUの現状の利点って、専攻したメニィコアによる並列処理でしょ。
もはや、浮動小数点演算能力は、GPUの専売特許ではなくなってる事に気づくべき。
グラフィック処理用プロセッサだからって、騙されちゃいけないよ。

少なくともピクセルシェーダーが扱うbitonicソートは、整数演算だな。
あれもGPUに特化した処理だし。何をいまさら・・・

>>911
後藤の受け売り乙ｗ
2chだからアレだけどリアルではそういう事言わないほうがいいぞ

まぁとりあえずGPU+CUDAとCPUで整数配列ソートのベンチマークでも
取ってみることをオススメするよ

普通に、どっかの論文でCPU(Pen4 2.8G)に対してGPU(Geforce6600)で48倍のソート結果出てたでしょ。
ついでに、バイオインフォマティクスのDNAマッチング(要するに文字列マッチング)では68倍
十分CPUに対してのアドバンテージだし、利用がナンセンスとかあふぉだろ。

実際俺がBrookGPUで作ったBWTのソートでも、CPUに対してちゃんとアドバンテージあったよ。
俺じゃなくても、ググったらいくらでも結果出てくるだろ。

ftp://ftp.research.microsoft.com/pub/tr/TR-2005-183.pdf

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

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

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

結論言うと、別に浮動小数点じゃなくても、GPUのメリットはある。
CPUに負ける例があるなら、むしろ示せ。

先日、CUDAに移植した(ってのも変な言い方だけど)プログラムは、
CPU版より速くするのに結構手間が掛かったよ。
メモリアクセスがgdgdなロジックだと、意外にCUDAは苦手なようだ。

そうそう、CPU版で使ってた三角関数のテーブル参照は、CUDAでは自前で演算した方が速かった。
超越関数ニモニックを持たないどこぞのDQNCPUのサブプロセッサよりも、その点ではずっと重宝だよ。
まぁ、どう足掻いてもLocalなメモリが250KBしかないから最初に書いたような
問題が発生しないと言う点ではそのDQNCPUのほうがマシと言えなくもないけどw

おいおいギガバイト級データのソートの話なんて明らかにしてないだろ
20-100GBの文字列とかどんだけ〜ｗｗｗ

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

俺はちょっと馬鹿らしくてやってられないなぁ
だから言うようにGPU+CUDAとCPUでベンチしてみて欲しいんだよねｗ

>>917
おちつけ
話が支離滅裂

特に
>おいおいギガバイト級データのソートの話なんて明らかにしてないだろ
>20-100GBの文字列とかどんだけ〜ｗｗｗ
ここ何が言いたいかわからん。

GPGPUでの文字列ソートの時点で、多分やりたい分野はわかっちゃったけど・・・
(最近あちこちで論文出てるアレだよね？バイオインフォマティクスとか名前が出てきた時点で・・・ｗ)
確かに、上手くやれば良いんだけど、多分ここの人たちの考えてる文字列ソートって、せいぜい数M単位だと思うよ。
グラフィック肌の人が多いここで聞いても無駄
普通に論文読みなよ。

>>918
まぁなんだ、論文嫁

グラフ見るだけでもいいけど

ところで、ちょっと前のビデオカードで試したときは、入力データを
そのまま出力するだけで、内部精度の影響か最下位ビットが微妙に
変化してしまうことがあったけど、8800あたりだと問題ないの？

>>921
キャストが原因じゃねぇの？
16bitの入れ物に32bitのデータを入れて、演算して
再び32bitのデータに戻したら、最下位ビットが変化する。


>>609
この辺りか

>>921
floatは精度が24bitしかない。それはどんなGPUでも一緒。
CUDAなら整数型もあるから、8800に限らず8600,8500でも大丈夫だけどね。

不定領域が出来るって話だよね？
予め、受け皿をゼロで埋めておけば良いんじゃね？

あれ？NVIDIAは16bitと32bitじゃなかったっけ？
ATIは9800あたりは24bitだったけど、X10000から32bitじゃないの？

そもそも仮数精度のこと言ってるのか浮動小数フォーマット全体での精度のこと言ってるのか。
仮数精度24ビットと32ビットは同じ。

どっちにしろ「どんなGPUでも同じ」ではないと思うけどね。
最低保証は9bitだったっけ？

>>923

ちなみにIEEEならmantissa 23 bits、exponent 8bits、sign 1 bit

たしかに仮数部23bitだけど、内部表現上の最上位は暗黙に1として省いてるだけだから、
実際にはエクセル64の24ビットに精度が劣るということはない。

おれのようなヘッポココード書きには論文はちと荷が重いよ。

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

並列ソートを理解するには、どの本がわかりやすいの？

ダンゴさんがピシっと〆めてくれたな。

さすが団子さん！かっくいい！！ー

この前知り合いからGPGPUって名前を聞いて
今作ってるプログラムの高速化に使えないかと考えたんだが、
GPGPUは

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

って処理に使えそう？
使えそうなら今から勉強してくるぜ！

>>935
並列演算できる部分があれば充分使える。
CUDAなら実装も簡単。

>>935
ﾄﾝｸｽ

　　┌───────────────────────────────┐
　　│935 名前：デフォルトの名無しさん[sage] 投稿日：2007/08/14(火) .23:32:20 │
　　│>>935　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
　　│並列演算できる部分があれば充分使える。 　　　　　　　　　　　　　　　　　　 │
　　│CUDAなら実装も簡単。 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
　　└───────────────────────────────┘
　│>>935　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
　│並列演算できる部分があれば充分使える。 　　　　　　　　　　　　　　　　　　 │
　│CUDAなら実装も簡単。 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
　└───────────────────────────────┘
│>>935　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
│並列演算できる部分があれば充分使える。 　　　　　　　　　　　　　　　　　　 │
│CUDAなら実装も簡単。 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 │
└───────────────────────────────┘

荒らしうぜぇ

CUDAなら実装も簡単とは言うがな、兄者

資料がなさ過ぎるんだよ、兄者

とはいえ、BrookGPUのような既存のGPGPU専用言語では、
速度が出ないし、速度が出る実装も出来ないからなぁ。


この前BrookGPUで、CPUより40パーセントも遅い処理書いちゃって憤慨した。
鼻から色々出た。

>>939
NVIDIAのドキュメントでは不足かい?
まぁ、書いてみろ｡いいもんだ。
#つーか、fftwやblas使いなら苦にもならんだろ｡

>>748
> S3（VIA）その他の弱小グラフィックスが再び脚光を浴びる。

いよいよSiS/Mirageの出番がやってまいりますた！
http://arena.nikkeibp.co.jp/winpc/col/02/web_road_intel.pdf

P4M900でChrome9がAGP接続な事に本気でビックリした

CUDAって再帰出来ないの?
moe(){←GPU側の処理
}
hoge(){←CPU側の処理
foo();
bar();
moe();
for(;;)
hoge();
}
みたいな事って無理なの?

CPU側はできるでしょ。ドキュメントを読めば、デバイス側はできないと書いてあったと思うけど。

そうそう、>944のようなコードだと、moeの呼び出し部分を並列化することになると思う。
つまり宣言は
__global__ void moe(...);
であり、呼び出し部は
moe<<<blocks, threads>>>(...);
になるんじゃないかな。
再帰段数にも拠るけど、巧く考慮しておかないとパフォーマンスは出にくいと思われ。

ttp://www.gpgpu.org/s2007/
SIGGRAPH 2007 GPGPU COURSE

GPGPUってどういう処理に向いているの?
一つの処理をforkしてさばく場合?
それともやたら早く数値演算が出来るの?

やたらとは速くないな。少なくともWoodcrestには負けると思う。
強いのは並列処理。例えば行列演算とか画像処理にはかなりの威力を発揮する。
意外なところでは、超越関数だけで言えばXeonを遥かに凌ぐ速度も出る。

簡単に言えば、CPUより出来の悪いプロセッサが、大量にくっついてるから
数で勝負できる。ってだけ。

並列化出来なければ、何のメリットも無い罠

文字列操作は出来ないんですか?
#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';
}
良く分からないですけれど、こんな感じで。

>>951
・GPU側関数はGPU側メモリしか扱えない。
・並列化しなければパフォーマンスは出ない。

結論:単なる文字列のコピーには使えない。但し、文字列操作ができないと言うことではない。

ちきしょーCUDA使いたかったのでXP 32bit追加

Linuxは64bit出てるけどWinはないんだっけ?

やっぱCUDA使う研究者とかはLinux使う人が多いのかな。
VMが進化してきたのでいいけど。

nvcc(CUDAのコンパイラ)とgcc(iccでも可)があれば開発できるからねぇ。
Windows版はVS2005との連携になるからちと面倒。
# 尤も、どうせコマンドライン版を使うんだけど。

>>952
ありがとうです。
GPU側からは、CPU側のメモリは弄くれないと。
つまり、参照渡しが使えない訳か。
GPU側の演算結果を得るためには、
cudaMemcpyという専用の関数を使わないと
駄目な訳ですね。
自分はMacしかもってないんですけれど、
実験でLinuxマシンかおうかなぁ。
CUDAには夢を感じるので。

・∀・）っ-○◎●

G80 じゃなくて CUDA に夢？
Larrabee とかにも自然に使えるとかそういう願望？

なぜダンゴがこのスレにいるんだ？

最初から居る

G80じゃなくてCUDAに自分は夢を感じますねぇ。
自分GPUの仕組みについては全くさっぱりなので。
ところでGPUをグリッド?単位で扱うみたいな事が書いてあるんだけれど、
っーことはGPUをいくつかに切り分けて、
fork-execしたプロセスに別々に渡したりできるのかしら?

>>962
その仕組みがCUDAでいう並列化の肝だ。
例えばこんなループを
for (int i = 0; i < N; ++i) {
func(array, i);
}
こんな風に書くわけだ。
func<<<1, N>>>(array);

いや呼ぶ側が別プロセスで使えるか，って話だろ

あー、そういう話か。
別プロセスから単純に使おうとしたら待たされたっぽいけど
分割数を制御すれば共存できるかな?
確かに巧く使えば便利そうだ。ちょっと調べてみよう。

>>963,964,965
すいません。
そういう話です。
GPUを論理分割?して別々の処理をしているプロセスに割り当てられたら
夢が広がるかなぁと思って。

TILE64ってどうよ？
PCIeカードが出るみたいだけどx4レーンに刺すタイプみたいな。

わざわざマザー買い換えたくないし、さてどうしたものか。

しかも2スロット占有型でしょ。
コンパイラがどんなもんかも判らんし。

マザー側のx1レーンを削（ｒｙ

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

嫌だこの構成・・・

これって
大量のスレッドをぶん回す用途には使えないの?

そもそもスレッドってなに？みたいな。
GPUって基本的にピクセル数分並列化できるから、複数タスクを平行に動かすような用途には進化しなかった。

SIMDだからなぁ。MIなプログラム/アルゴリズム
には向かないと桃割れ。
ちと三宮へゲフォなグラボ見に逝って来る。