GPGPU - 暇つぶし2ch

GPGPU ..

526:デフォルトの名無しさん
07/04/09 15:46:29
8800GTXなんて、+12V電源を30A用意しろと書いてあるよ。
単純計算するとそれだけで360Wだ。
#実際、ボード上に+12V用6pin電源コネクタが二つもある。

527:デフォルトの名無しさん
07/04/13 03:40:49
CPUのように消費電力が通常の半分で値段が通常の1.5～2倍の
製品を出してくれれば、一般的な開発者もGPCPUの検討用に買ってみようか、
というやつが増えると思う。
次世代では両者とも検討してほしいところ。

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

528:デフォルトの名無しさん
07/04/13 11:08:03
計算終わった後に「チーン」って音しそうだな。

529:デフォルトの名無しさん
07/04/13 13:24:32
おい、CUDA SDK 0.81 あるぞ。

530:デフォルトの名無しさん
07/04/13 14:16:29
あるぞといわれても

531:時々書いてるこのスレの住人
07/04/13 14:32:29
取り敢えず拾った。

>>529
THX!

532:デフォルトの名無しさん
07/04/13 18:29:20
>>529
ｱﾘｶﾞﾀﾏｷﾝ ( ´∀｀)ﾉ⌒ω)Д`)ﾌﾞﾆｭ

533:デフォルトの名無しさん
07/04/15 13:13:41
けっこうCUDA使い＝8800使いがいるんだね。
簡単な結果でいいから、報告してくれないかな。

534:・∀・）っ-○◎●
07/04/15 13:21:27
おれCUTA使い

535:デフォルトの名無しさん
07/04/15 15:41:46
( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )ﾋｿ

536:デフォルトの名無しさん
07/04/15 16:37:35
>>533
なんか適当なベンチマークないかね。
nVideaのサンプルは動作確認っぽいのばかりで動かしても面白くないのだけれど。
#つーか、私も作らないとなんだけどね(苦笑

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

538:デフォルトの名無しさん
07/04/15 23:54:14
>>533同意
とりあえず>>424の姫野ベンチの結果が知りたいな

539:536
07/04/16 11:31:05
Linuxだから無理。
じゃないけどBrook入れてないからめんどい。

540:デフォルトの名無しさん
07/04/16 12:17:16
実行だけならBrook入れなくても
出来るよ。

541:デフォルトの名無しさん
07/04/16 23:48:51
>>533
つーか今CUDAって8800以外で使えるの？

542:デフォルトの名無しさん
07/04/18 18:04:18
ｹﾞﾌｫ廉価版出たけどあまりにも性能差が差別化されまくり。
それでも、エミュよりマシだと思えばいいのか。

543:デフォルトの名無しさん
07/04/18 20:24:05
8600が出ましたよ。

544:デフォルトの名無しさん
07/04/18 21:09:01
質問です。
ifやswitchなど条件分岐を一切使わずに汎用プログラミングを行うと言うのがかなり理解出来ないのですが
一般的にGPUでのプログラミングでは、この辺はどのようにしているのでしょうか？

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

545:デフォルトの名無しさん
07/04/18 22:05:46
>>544
分岐の分だけmain()を作る
今はもうレガシな手法になりつつあるが。
当然個々のフラグメントプログラムは
画一したフローを踏むことになる。

546:デフォルトの名無しさん
07/04/18 22:16:00
>>545
一瞬びっくり！という感じだけど、やっぱりわからない。
if文は普通にc++で書いて特定の箇所で飛ばすのに比べて、
mainたくさんというのは、どういうメリットがあるの？

547:・∀・）っ-○◎●
07/04/18 22:43:44
mainじゃなくてもサブルーチンでもいいけど、分岐の頻度を最小限に減らさないといけない
パイプラインが長いと、分岐の度に大きなペナルティ食らうわけよ

んで

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

よりも

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

のほうが速いよね。
パフォーマンス重視なら、分岐を繰り返し処理の外に追い出せる場合は
なるべくそうしたほうがいい。たとえ冗長になってもね。
普通のCPU向けプログラミングでも同じ
（最近は分岐予測のほうが賢くなってるから一概にはいえないけど）

548:デフォルトの名無しさん
07/04/18 23:12:58
>>547
>>545の話はそういう話なのかい？
＞mainじゃなくてもサブルーチンでもいいけど
あんたのコードで//HogeHogeのところで別プロセス呼んでたりしたら、
普通は頭がおかしいコードだと思うよね。

549:・∀・）っ-○◎●
07/04/18 23:19:36
プログラムって基本的にループの塊なんで、

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

550:デフォルトの名無しさん
07/04/18 23:24:46
いやさ、おれもコード書きのはしくれなんで、forkくらいは使うけど、
>>545のはGPUを使うときの独自の流儀の話をしてんじゃないの？ってこと。

551:・∀・）っ-○◎●
07/04/18 23:24:58
ちなみにGPUにプロセスの概念はない。GPU上でOSは動かないだろ。

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

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

553:デフォルトの名無しさん
07/04/18 23:59:05
>>552
いちおう理解できたようだ。感謝。
でも>>547は関係ない話だろう。

554:デフォルトの名無しさん
07/04/19 00:13:38
スレが伸びてると思ったら糞団子かよ

555:デフォルトの名無しさん
07/04/19 00:46:37
トップガン(藁

556:デフォルトの名無しさん
07/04/19 00:50:39
分岐コストが高いなら、両方のルートを計算すればいいだけ。
そういう頭の使い方ができない香具師にはGPUを使いこなすのは難しい。

557:デフォルトの名無しさん
07/04/19 01:04:55
つまり下手鉄砲も数打ちゃ当たる？

558:・∀・）っ-○◎●
07/04/19 01:07:57
弾の数が勿体ない。
スループット落ちるじゃないか。

559:デフォルトの名無しさん
07/04/19 01:09:19
252 ：Socket774 [sage] ：2007/04/19(木) 00:15:30 ID:0/nRKtHL
Larrabeeはかなり本気で開発している模様

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

そしてGPGPU終了のお知らせ

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

URLﾘﾝｸ(journal.mycom.co.jp)

560:・∀・）っ-○◎●
07/04/19 01:12:33
早い話がIntel版Cellだな

561:デフォルトの名無しさん
07/04/19 01:19:22
さすが団子ﾁｭｰさん＾＾

562:デフォルトの名無しさん
07/04/19 10:22:20
ダンゴの一言は重みがあるな

563:デフォルトの名無しさん
07/04/19 20:33:33
GPUで出来ることの幅が広がるのはうれしいけど
本来のGPU的の使用には向かなくなってるのかな？
例えば、これからコアもっとリッチに、粒度をもっと細かくしていくと
行き着く先はCell+だよね。で現状CellはGPUの代わりは出来ていない。

564:デフォルトの名無しさん
07/04/19 20:42:46
上の奴は何を言ってるんだ?
もっと勉強してこいと言いたい。

565:デフォルトの名無しさん
07/04/19 20:51:19
今のGPUがやっているような、パラレリズムの特徴を利用してメモリアクセスの
レイテンシーを隠ぺいできるような仕組みがないと、PUの利用効率が悪くなって
大きなファクターでの性能向上は難しいような気がする。

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

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

567:デフォルトの名無しさん
07/04/19 21:42:32
G70系のように比較的大きい粒度だと小さいレジスタですんでたのが
R520系では小さい粒度のためG70系に比して大きいレジスタを搭載している。

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

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

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

570:デフォルトの名無しさん
07/04/21 05:44:09
>>568
ども。
Xeon Quad DPのコア当たり性能が仮にNetburst Xeon 3.4GHzの倍だとしても、
x 2 x 4 x 2 でもまだ、10倍以上か。

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

571:デフォルトの名無しさん
07/04/21 06:18:08
コード示さんとわからん。

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

573:536
07/04/23 18:28:24
あー、載せるの忘れてた。CPU版のソースはこんな感じ。これをGPUのサンプルのtransform()と入れ替えて辻褄合わせた。
#でも、CUDAではgetData()相当で単純に整数化しないでニアレストネイバーか何かでサンプリングしているのでその分更に差が開く……

static float getData(float * data, float x, float y, int width, int height)
{
int ix = static_cast<int>((x + 1) * width + 0.5f);
int iy = static_cast<int>((y + 1) * height + 0.5f);
ix %= width;
iy %= height;
return data[iy * width + ix];
}
void transform(float * rdata, float* g_odata, int width, int height, float theta)
{
for (int y = 0; y < height; ++y) {
for (int x = 0; x < width; ++x) {
float u = x / (float) width;
float v = y / (float) height;
u -= 0.5f;
v -= 0.5f;
float tu = u*cosf(theta) - v*sinf(theta) + 0.5f;
float tv = v*cosf(theta) + u*sinf(theta) + 0.5f;
rdata[y*width + x] = getData(g_odata, tu, tv, width, height);
}
}
}
このコード、Celeron1.2GHzでは109msだった。

574:デフォルトの名無しさん
07/04/23 19:42:27
>>573
おいおい、そのCPU用のコードはいくらなんでも冗談だろ？

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

576:デフォルトの名無しさん
07/04/23 20:21:04
>>575
CUDAで実行した場合に transformKernel() 内のすべてのロジックを
各画素について糞真面目に計算してるとでも思ってるのか？
そのCPUコードじゃGPUと対等じゃないよ。

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

578:デフォルトの名無しさん
07/04/23 21:22:20
>>573
CPU側をこんな感じにすればGPUの計算量に近くなるかな

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

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

逆にCUDAのほうでsin, cosの中身をthetaだけじゃなくビルトイン変数blockIdxとかに依存させたら
各入力に対して毎回三角関数を計算せざるを得なくなるから劇的に遅くなるんじゃないかな

579:デフォルトの名無しさん
07/04/23 21:58:44
gcc、それくらいの最適化は任せられなかったっけ？
気持ちが悪いから、可読性が落ちないなら、速い方にするけど。

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

580:デフォルトの名無しさん
07/04/23 22:24:02
>>579
sinf, cosfは外部のライブラリ関数で、Cコンパイラはその処理内容を知る立場にないから、
for文の中にある関数の呼び出し回数を勝手に減らすような最適化は普通しないと思うよ。
インライン関数だったらそういう最適かも可能だけど。

581:536
07/04/23 23:00:41
うい、流れは理解した。
明日にでも試してみる。

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

582:デフォルトの名無しさん
07/04/23 23:33:10
>>581
投げてばっかりで悪いけど、よろしく。
8600でも買おうかと思ってたけど、unitが半分のはずが1/4しかないんでちょっと萎えてる状態。

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

584:デフォルトの名無しさん
07/04/24 06:58:26
積は最近遅くない気もするがね。

void transform(float * rdata, float* g_odata, int width, int height, float theta)
{
　float inv_width = 1.0f / width;
　float inv_height = 1.0f / height;
　float sin_theta = sinf(theta);
　float cos_theta = cosf(theta);
float v = -0.5f;
　for (int y = 0; y < height; ++y, v += inv_height) {
float u = -0.5f;
　　for (int x = 0; x < width; ++x, u += inv_width) {
　　　float tu = u*cos_theta - v*sin_theta + 0.5f;
　　　float tv = v*cos_theta + u*sin_theta + 0.5f;
　　　*rdata = getData(g_odata, tu, tv, width, height);
++rdata;
　　}
　}
}

585:536
07/04/24 17:56:14
ほい、お待たせ。
結論から言うと、10msそこそこまで速くなった。
#コンパイルオプションつけ捲くりw(-O3 -funroll-loops -msse2 -mfpmath=sse)

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

ってことで、レスくれている人達THX。こちらもどうせいろいろ資料作らなければならないんで、ネタ提供してもらって助かってます。
#そう言えば、DOSPARA辺りで8800積んだBTOのPC出始めてますねぇ。

586:536
07/04/24 18:31:54
>>583
この辺は参考にならない?
URLﾘﾝｸ(forums.nvidia.com)

587:デフォルトの名無しさん
07/04/24 20:27:32
>>585
どうもです。10msそこそこってのはCeleron1.2GHzですか？
getData（テクスチャフェッチ）はGPUが非常に得意な部分だからそこでかなり差が付いてるかもね。

588:デフォルトの名無しさん
07/04/24 23:38:13
Celeron 1.2GHzならメモリが遅過ぎでしょう。
あとCeleronの場合、整数だけで座標を演算した方が速いと思う。
それにしても比較するのは酷な環境。

589:デフォルトの名無しさん
07/04/24 23:45:07
ところで時間計測はどのように行ってます？

590:536
07/04/24 23:49:26
いや、10msはXeon3.4GHz(>568-569参照)。
そう言えば、Celeronの速度は忘れてた。

591:588
07/04/24 23:55:05
あとこれCPUにもよるだろうけど、繰り返さなくていいなら

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

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

592:デフォルトの名無しさん
07/04/24 23:56:58
何言ってるか分りにくいか。
ix %= width
みたいな除算が重たいから取り除くって話ね。

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

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

594:588
07/04/25 03:13:43
積に比べれば遥かに重いんだけど、流石にXeonでは誤差か。

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

ix %= width;

を

ix &= (width-1);

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

595:デフォルトの名無しさん
07/04/27 00:55:48
上の方でも条件分岐が必要な処理に関して質問があがってたのですが
イマイチ、ぴんと来ないので質問させてください。

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

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

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

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

596:デフォルトの名無しさん
07/04/27 01:01:48
つか、ゲッパチ買ってきたんだけどCUDA糞じゃん

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

597:デフォルトの名無しさん
07/04/27 01:26:43
>>595のは、ちょっと例が悪かったです。
ごめんなさい(汗
ただ、他にifを使う部分は、やっぱり数式に直すしかないんですかね？

598:デフォルトの名無しさん
07/04/27 01:42:26
>>597
悪いってレベルじゃねぇぞｗ

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

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

599:デフォルトの名無しさん
07/04/27 06:51:15
>kiの値は
>ki=1/√2 (i=0)
>ki=1 (i≠0)
単純になら、ki=1-(1-1/√2)*(i==0)
i==0の時だけループからはずすのも手だし、
テクスチャを係数テーブルにするほうが普通じゃ。

600:デフォルトの名無しさん
07/04/27 07:50:49
>>597
効率がどうなるかは知らんが、そういう用途ならCUDAの方が楽じゃない?

601:デフォルトの名無しさん
07/04/27 09:50:02
BrookGPUで各ユニットで共通の変数を利用したい場合ってどうすればいいのでしょうか？

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

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

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

602:デフォルトの名無しさん
07/04/27 09:55:56
>>601
まず、後者の場合、reduceを使う

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

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

603:602
07/04/27 09:57:59
って、うわ・・・
後者も間違ってる。。sumの問題じゃなかったのね。
すまん。

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

604:デフォルトの名無しさん
07/04/27 10:35:23
>>601

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

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

605:デフォルトの名無しさん
07/04/29 00:19:43
お前らCUDAやりなさい。

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

606:デフォルトの名無しさん
07/04/29 00:46:51
Cgはシェーダー言語。HLSLのベースになった時点であるいていど成功。
CUDAはプログラミング言語。

607:デフォルトの名無しさん
07/04/29 00:49:41
>>606
はあプログラミング言語ねえ

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

609:デフォルトの名無しさん
07/05/02 13:22:28
BrookGPUって、intは使えないよね？
データがint型で、ストリームに送る前にキャストしても返ってくる値がおかしいから困る・・・。

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

610:デフォルトの名無しさん
07/05/03 08:20:49
桁落ちが原因だろ。＞値がおかしくなる。
落ちない範囲に収めるor諦める

611:デフォルトの名無しさん
07/05/03 18:01:20
コーヒーブレイク
URLﾘﾝｸ(www.forum-3dcenter.org)
URLﾘﾝｸ(www.forum-3dcenter.org)
R600のリークスライドなんですが、SuperScalar,SIMD,VLIW等
並列実行のキーワードが並んでます。
詳しい人、どうなんでしょうこのGPU。

612:デフォルトの名無しさん
07/05/04 00:36:29
電気馬鹿食いDQNカードだぞ？

613:デフォルトの名無しさん
07/05/04 13:22:12
これからGPGPUに入門しようと思って、手始めに3Kのテキストデータの文字列に+1するだけの単純コードで実験してみた。
BrookGPUが簡単だったので、こいつを使った。

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

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

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

…全然だめじゃん。GPGPUって
環境は、Athlon64 X2 4200+,GF8600GTS
これより式を複雑にしたら、もっとスーパースカラーなCPUがより有利になるでしょ。
GPUは、和積演算だけは、同時実行出来るんだっけ？

614:デフォルトの名無しさん
07/05/04 13:36:48
>>613
それは計算量少なすぎ。
明らか転送のネックの方が大きいだろｗ

615:613
07/05/04 13:40:38
>>614
CPUの時も、streamReadとstreamWriteだけやるようにしてみました。
それでもCPU:16秒でした^^;

616:デフォルトの名無しさん
07/05/04 14:10:15
>>615
それはつまり、GPUの処理時間は2秒ということだね。
……だからなに?

617:デフォルトの名無しさん
07/05/04 14:20:32
転送時間を差し引いても、演算速度がCPUよりGPUの方が遅いって話だろ

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

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

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

619:デフォルトの名無しさん
07/05/04 15:11:56
>>618
BrookGPUって、単なるコンバータだよ。
結局Cgのデバッグ作業になるが・・・。
Cgは、nVIDIAがそういうツールを提供してる。

620:デフォルトの名無しさん
07/05/04 15:39:12
>>613

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

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

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

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

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

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

623:デフォルトの名無しさん
07/05/04 15:58:54
実際に海外の優秀なやつはら暇つぶし程度にしかいまのところやってないよ
速度云々は別にどうでもいいって感じだよ。ただできましたって感じだよね

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

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

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

625:デフォルトの名無しさん
07/05/04 16:03:56
>>624
何マジレスしてるんだよw？

626:デフォルトの名無しさん
07/05/04 16:17:52
行列に落とし込むくらいだったら、CPUに演算させた方が・・・ｗ

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

627:デフォルトの名無しさん
07/05/04 18:55:00
URLﾘﾝｸ(mumei24.run.buttobi.net)

DLパス:gpu

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

誰か助けてください。

628:デフォルトの名無しさん
07/05/06 00:11:23
>>611
リンク先は流し読みしただけだけど。

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

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

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

629:デフォルトの名無しさん
07/05/07 01:27:32
GPUはSPMDだろ。
まぁCUDAで言えばWarpはSIMDだが、いずれにしてもGridレベルのSPMD。

630:デフォルトの名無しさん
07/05/09 18:24:24
627ですが…反応ないですか

631:デフォルトの名無しさん
07/05/09 22:08:54
>>630
激しくスレ違い。
ここはコンピュータグラフィックス関連のスレじゃないよ。

632:デフォルトの名無しさん
07/05/10 19:04:59
…スレ違いなんですか
他スレの方が汎用コンピューティングとあったのでこちらで聞いたのですが

633:デフォルトの名無しさん
07/05/10 22:31:23
GPUスレと勘違いしてないか？
GPGPUスレだぞ。汎用的にGPUを使おうってスレで、本来のグラフィックス処理がらみはスレ違い。

634:デフォルトの名無しさん
07/05/11 00:05:44
OpenGLスレとかその辺かな。

635:デフォルトの名無しさん
07/05/13 22:58:51
このスレッドの人ってあかでみっくぽすとの人が多いのかな

636:デフォルトの名無しさん
07/05/14 01:27:35
中途半端に賢い人が多いんだよ

637:デフォルトの名無しさん
07/05/15 07:05:44
>>611
URLﾘﾝｸ(techreport.com)
float MAD serial以外は、概ね速い。

638:デフォルトの名無しさん
07/05/17 02:43:02
最近シェーダを学び始めた者です。

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

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

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

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

639:デフォルトの名無しさん
07/05/18 11:28:03
Cgでint4が出来れば扱えるんじゃない

640:デフォルトの名無しさん
07/05/18 22:35:37
CUDAは、さっさとXP x64とVistaに対応するべきだ。
俺、この2つのデュアルブートだから、せっかく8シリーズ買ったのに・・・。
これのために買ったのになぁ・・・orz

641:デフォルトの名無しさん
07/05/19 00:02:18
>>639
ありがとうございます。
試してみます。

642:デフォルトの名無しさん
07/05/19 21:48:38
ATI RADEON X800 XTで
Ｃｇの中でforやらbreakが使えないみたいなエラーが出たんだけど

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

643:デフォルトの名無しさん
07/05/19 23:25:09
>>640
ゲフォ8800なんて買う変態がXP 32bitにするわけがないからなぁ。

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

644:デフォルトの名無しさん
07/05/20 01:18:59
>>643
CUDAのこと? あれ、だってコンパイルにはgcc使ってるもの。

645:デフォルトの名無しさん
07/05/20 14:17:03
あーそりゃそうだな

646:デフォルトの名無しさん
07/05/26 21:56:13
ねねCUDAで

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

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

647:デフォルトの名無しさん
07/05/26 21:58:16
無理

648:デフォルトの名無しさん
07/05/26 22:57:06
なんだとぉ
ふざけるんじゃねーよ教えてくれよマジ切れするぞ
ゆとり世代は沸点低いんだよ忘れたのか？

649:デフォルトの名無しさん
07/05/26 23:35:02
＞ゆとり世代は沸点低いんだよ忘れたのか？
ちょっと地面に穴掘って埋まってきたら?
圧力掛かると沸点高くなるっしょ。

650:デフォルトの名無しさん
07/05/26 23:56:46
>>649
なめてんのかコラいいかげんにさっさと教えろよ

651:デフォルトの名無しさん
07/05/27 00:00:20
マジレスしてやるよ
CUDA SDKにはエミュついてるから、自分で試しヤガれ
コンチクショー

652:デフォルトの名無しさん
07/05/27 00:23:39
だから無理だって言ってるだろ。
GPUには、条件分岐するキーワードは無い。
予めCで分岐してから、各処理を呼び出すしかない。

653:デフォルトの名無しさん
07/05/27 00:38:12
じゃあ
abcdefjを128bitのhexとかに予め変換してとか小細工しても

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

654:デフォルトの名無しさん
07/05/27 11:33:06
>>653
もちっと、じぶんのあたまでよくかんがえてからしつもんしよう。
ぺたっ　（もうすこしがんばりましょう）

655:デフォルトの名無しさん
07/05/27 11:34:31
>>654
わかんねーからきいてるんだろうが
こちとら時間ねーだんよささっと情報晒せ

656:デフォルトの名無しさん
07/05/27 12:11:24
時間ないなら諦めたら?

657:デフォルトの名無しさん
07/05/27 12:12:27
>>656
悪かった取り乱してしまった。すまいと反省している。
ね？ね？ヒントでいいかなんか情報くださないな

658:デフォルトの名無しさん
07/05/27 12:56:58
なかなか釣れませんね

659:デフォルトの名無しさん
07/05/29 01:34:39
あのー誰か教えてよぉもう2日もがんばってるけど
できないよ

660:デフォルトの名無しさん
07/05/30 08:32:29
>>659
そもそもなぜGPUでstring処理を行いたいのでしょうか？？

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

661:デフォルトの名無しさん
07/05/30 13:59:24
余計なお世話だろ

662:デフォルトの名無しさん
07/05/30 14:36:51
すみませんでした

663:デフォルトの名無しさん
07/05/31 00:38:24
>>660

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

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

664:デフォルトの名無しさん
07/05/31 01:00:22
>>663
CUDA SDK付属のエミュでまずは作れ。
そしたら実機で回してみせるよ。

665:デフォルトの名無しさん
07/05/31 01:02:10
>>663
CUDA SDK付属のエミュでまずは作れ。
あうあう？うーんうーん？エミュってどこにあるの
それいってくださいよーもー

666:デフォルトの名無しさん
07/05/31 01:08:06
まずはダウソしてインスコしてビルド汁
話はそれからだ

URLﾘﾝｸ(developer.nvidia.com)

667:デフォルトの名無しさん
07/05/31 01:22:09
64bitじゃ無理じゃーん
どうしろっていうんだorz

668:デフォルトの名無しさん
07/05/31 02:35:44
俺もXP x64とVistaのデュアルブートだから無理だったんだよな・・・prz

669:デフォルトの名無しさん
07/05/31 07:54:50
>>667
欲張って64bitのマシンを買うからだ

670:デフォルトの名無しさん
07/05/31 09:40:38
大丈夫、漏れは64bit機で32bitRedHat入れている。
#勿論、CUDAは問題なく動く。

671:デフォルトの名無しさん
07/05/31 23:27:42
URLﾘﾝｸ(grape.astron.s.u-tokyo.ac.jp)
URLﾘﾝｸ(jp.arxiv.org)

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

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

残念ながらGrapeはお終い。

672:デフォルトの名無しさん
07/05/31 23:32:08
演算アクセラレータボードを作っている会社も危ない状況ですね。
某社のボードなんか100万とかする挙句に開発環境がそれの倍以上だもんなぁ。

673:デフォルトの名無しさん
07/05/31 23:52:47
ねぇねぇubuntu x64環境でどうやってCUDAするの？
toolとcudaいれたけどVideoのドライバがインスコできない
なんで？

674:デフォルトの名無しさん
07/05/31 23:54:34
ERROR: this .run file is intended for the
Linux-x86 platform, but you appear to be
running on Linux-x86_64. Aborting installation.

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

675:デフォルトの名無しさん
07/05/31 23:59:43
>>674
日本語の参考書が出るまで、あんたにはCUDAは使えない。
日本語の参考書が出たらまたどうぞ。

676:デフォルトの名無しさん
07/06/01 00:26:47
>>671
いやさすがに3年後でmGPUにはならないでしょ…

677:デフォルトの名無しさん
07/06/01 01:30:32
>>674
エラーメッセージにダメな原因がはっきりと書いてあると言うのに、
これでも文章の意味が分かりませんか。はぁーーーーー。

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

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

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

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

678:デフォルトの名無しさん
07/06/01 01:34:26
いや、日本語の参考書が出てもダメでしょ。

679:デフォルトの名無しさん
07/06/01 03:14:22
>>671のサイトのはGRAPEの製作者のところなので
自分たちのシステムの優位性をアピールしたいんだろうが
その人たちですら、性能面でのGPUの優位性はもはやみとめざるを得ないと言う事だろうな。

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

680:デフォルトの名無しさん
07/06/01 03:16:42
一般人は、エラーメッセージの内容を信用しないって所があるんじゃね？
多分、そのメッセージが日本語でも同じ。

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

681:デフォルトの名無しさん
07/06/01 23:10:00
おいハードディスク買ってきたから32bitOS入れるから
教えてくれるよね？

682:デフォルトの名無しさん
07/06/02 14:26:11
環境は今からそろえるつもりとして、はじめるとしたらCUDAとCgどちらがいいですか？

683:デフォルトの名無しさん
07/06/02 14:33:49
両方やれば?

684:デフォルトの名無しさん
07/06/02 15:37:28
ねぇねぇねぇ
CUDAで
NVIDIA: could not open the device file /dev/nvidiactl (No such device or address).
とかでるんだけどさ、なんで？
NVIDIA-Linux-x86-1.0-9751-pkg1.tar.gzこれいれたんだけどさ。
いまカードはGeforce7950GTXなんだけどエミュで動かせるって聞いたけど違うのかな？
カード走って買ってこないとダメ？

685:デフォルトの名無しさん
07/06/02 16:17:50
GPUチップを認識できてないとそうなった希ガス。
nvcc動かすだけなら大丈夫だと思うけど。

686:デフォルトの名無しさん
07/06/03 02:02:23
エミュ用のディレクトリのを実行した？

687:デフォルトの名無しさん
07/06/03 12:43:44
サンプル動いたぉ

688:おしえてちゃん
07/06/03 14:27:02
gpgpu志向のプログラム作ろうとしてます。
ですがいきなり分からないことが、出てきました。

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

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

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

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

689:デフォルトの名無しさん
07/06/03 18:14:52
あまりGPGPU指向の話じゃないねぇ

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

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

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

691:デフォルトの名無しさん
07/06/03 19:55:22
その呼び出しのどの部分がキモいのか具体的にお願いします。

692:デフォルトの名無しさん
07/06/03 20:43:48
逆にそれだけで済んでしまうところが肝なんだが。

693:デフォルトの名無しさん
07/06/03 21:10:34
今エミュだけだからよーわからんのだけど
__device__と__global__って再帰呼び出し禁止だけど

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

694:デフォルトの名無しさん
07/06/03 22:12:09
ソース上げてくれたらテストするよ。

695:デフォルトの名無しさん
07/06/03 23:13:18
__device__ hogeから__device__hoge1を呼び出せないのは痛いなぁ。

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

696:デフォルトの名無しさん
07/06/07 23:58:14
なぁなぁ

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

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

697:デフォルトの名無しさん
07/06/08 07:41:27
CUDAが未だにVistaやx64に対応できないのは何か理由があんの？
もうかなり経つよね。

698:デフォルトの名無しさん
07/06/11 00:43:57
GPGPU完全死亡
URLﾘﾝｸ(pc.watch.impress.co.jp)

699:デフォルトの名無しさん
07/06/11 02:23:44
>>698
こんなのセルと大してかわらへん
並列度が低すぎる

700:・∀・）っ-○◎●
07/06/11 03:08:05
IA命令セットと互換ってのがみそだろ。
どうせSSEだろうけど。

701:デフォルトの名無しさん
07/06/11 07:00:21
で、どれだけ広まるのよ？一般に。
GPU以上に広まる可能性はあるのけ？

702:・∀・）っ-○◎●
07/06/11 07:04:13
そもそもGPUじゃないし
ただGPUで出来るGeneral Processingのおいしい部分は全部持ってっちゃうと思う。
x86のコードがそのまま動く意味は大きい。

703:デフォルトの名無しさん
07/06/11 07:04:20
しかも2009年まで出てこなんじゃ
インテルお得意のキャンセルされるかもしれないしね

704:デフォルトの名無しさん
07/06/11 07:22:53
てことは、一般には浸透しない可能性の方が大きいな。
Intelの資料にはLarrabeeだけで4CPU(?)構成の絵があったりするから
OSもそのまま走るのかも？

Tera Tera Teraには下記の記述がある。
LARRABEE ??TERATERA--SCALE SOLUTIONSOLUTION
Discrete high end GPU on general purpose platform
TeraFlopsof fully programmable performance
GPU ->16 cores @ ~2.0GHz, >150W
JPEG textures, physics acceleration, anti-aliasing, enhanced AI, Ray Tracing etc.

705:デフォルトの名無しさん
07/06/11 18:39:47
CPUコアがいくら増えたところでGPUの性能が落ちる訳じゃないし。

706:デフォルトの名無しさん
07/06/11 19:57:52
GPGPUよ、短い命であった。

707:デフォルトの名無しさん
07/06/11 22:43:50
そう、CPUのコアが増えたところで
GPGPUを使えば更に速くなるわけで、どっちか切り捨てるとかそういうものじゃないでしょ。
使えるものは使うと速くなるんだから。この場合は　だけどｗ

708:デフォルトの名無しさん
07/06/11 23:07:43
例えば今まで
CPU10 + GPU25 = 35
で処理できていたことが
CPU20 + GPU25 = 45
で処理できるならそれはいい。
なんで
CPU20 = 20にGPU切り捨てる必要があるんだ

709:デフォルトの名無しさん
07/06/11 23:15:13
しかも、CPUよりはGPUの方が安い罠。

710:デフォルトの名無しさん
07/06/11 23:18:20
30コアのCPUがいきなり一万円台で買えるとは思えないが。
よっぽど一世代前の高級GPUのほうが安く買えるかも。

711:デフォルトの名無しさん
07/06/11 23:41:11
PCI-Expressに挿せる超高速コプロならなんでも売れると思うけどね。
GPUでも糞INTELの石でもなんでもいいけどね

712:デフォルトの名無しさん
07/06/11 23:46:48
そうは言ってもClearSpeedはベンチマークスコア上げるのには
有効だが実用面ではちょっと。

713:デフォルトの名無しさん
07/06/11 23:51:48
あれは期待外れだった。糞高いコンパイラだけで性能出せないんじゃ……ねぇ。

714:デフォルトの名無しさん
07/06/12 07:29:59
「Larrabeeが登場したら、ハイパフォーマンスコンピューティングのベンチマークを
総なめにする可能性がある」とある業界関係者は期待を語る。

Larrabeeのターゲットアプリケーションは、一目見てわかる通り、GPUがGPGPU
でターゲットにし始めている領域と完全に重なる。つまり、LarrabeeはIntelによる
GPGPUの動きに対する回答だ。IntelとGPUベンダーは、ハイパフォーマンスな
浮動小数点演算性能が必要な並列コンピューティングの領域で、真っ向から
ぶつかることになる。

715:デフォルトの名無しさん
07/06/12 14:02:27
LarrabeeはSSL対応レイヤ3スイッチのアクセラレータや
重めのアプリケーションサーバにも向いているような気がする。
値段次第だけど。

716:デフォルトの名無しさん
07/06/15 05:53:00
R600のプログラム形態はSPIのStorm-1に近いかも知れん。

717:デフォルトの名無しさん
07/06/15 06:11:31
URLﾘﾝｸ(journal.mycom.co.jp)
>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つある。

718:デフォルトの名無しさん
07/06/15 19:06:16
GPGPUでGrapeオワタと思たらメニーコアでGPGPUオワタ

719:デフォルトの名無しさん
07/06/19 20:26:20
GPGPUを使った類似画像検索とか面白そうだが
どこもやってないのかな？

720:デフォルトの名無しさん
07/06/19 21:52:03
画像のパターン検索？ならやってた人がいたと思う

721:デフォルトの名無しさん
07/06/19 23:10:03
まぁそういう用途はGPGPUよりもこういうほうが面白そうだけどスレ違いか
URLﾘﾝｸ(www.k2.t.u-tokyo.ac.jp)

722:・∀・）っ-○◎●
07/06/20 00:57:06
DirectX10でGPUを汎用整数プロセッサとして使うサンプルある？

次ページ