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を汎用整数プロセッサとして使うサンプルある？
723:デフォルトの名無しさん
07/06/20 01:19:03
今更R600って、…MSX Turbo-R？
724:部外者('A`)NEET ◆xayimgmixk
07/06/20 11:57:32
あれは、R800だろ。
725:デフォルトの名無しさん
07/06/20 16:44:13
SEGA の体感ゲームだっけ?
726:デフォルトの名無しさん
07/06/21 01:21:12
R3000じゃなかったっけ？
ジオメトリエンジンついてるんだよな？
727:デフォルトの名無しさん
07/06/21 05:39:54
URLﾘﾝｸ(www.dailytech.com)
NVIDIA Announces Tesla General Purpose Processor Platform
URLﾘﾝｸ(pc.watch.impress.co.jp)
NVIDIA、G80ベースのHPC向けGPU「Tesla」
～PCI Expressカードタイプから1Uラックまで
>Teslaのソフトウェアプラットフォームは同社の汎用プログラミングモデル
>「CUDA (Compute Unified Device Architecture)」を利用。
>CUDAにはGPU用のCコンパイラが含まれており、
>Cプログラムに若干の修正を加えるだけで、
>CUDAコンパイラが処理をCPUとGPUに振り分けられる。
728:デフォルトの名無しさん
07/06/21 06:05:30
新しいGPGPU
URLﾘﾝｸ(www.gpucomputing.eu)
URLﾘﾝｸ(www.gpucomputing.eu)
729:ktkr!
07/06/26 11:26:50
ktkr!
Linux
[Download x86, x86-64] CUDA Tookit version 1.0
Windows
[Download] CUDA Tookit version 1.0 for Windows XP (32-bit)
[Download] CUDA SDK version 1.0 for Windows XP (32-bit)
[Download] Windows Display Driver version 162.01 for CUDA Toolkit version 1.0
URLﾘﾝｸ(developer.nvidia.com)
....ちょ、x64とかVistaは?
730:デフォルトの名無しさん
07/06/26 11:50:15
お、情報THX。
早速見てみなくちゃだわ。
731:デフォルトの名無しさん
07/06/26 12:15:19
もう完全にCUDAはやる気ないんじゃない？
うちはXP x64とVistaのデュアルブートだから、完全にアウト。
732:デフォルトの名無しさん
07/06/26 12:17:27
>>731
大丈夫、TesraがあるからCudaは終わらない。
733:デフォルトの名無しさん
07/06/26 14:56:23
こりゃあrapidmindの勝ちかな
734:デフォルトの名無しさん
07/06/26 15:51:35
x86_64 でXPとかビスタなんて使ってるやついたのか？
735:デフォルトの名無しさん
07/06/26 15:54:31
GPGPU用途に限ればLinuxでもいいのか。
CUDAカーネルの5秒制限も払拭されることだし。
736:デフォルトの名無しさん
07/06/26 18:51:32
残念。Larabeeの一人勝ち。
737:デフォルトの名無しさん
07/06/26 19:15:32
CUDAの分野とかから考えて、Vistaとx64を避ける意味がわからん。
特にVistaでは、GPUの仮想化をサポートしてるんで、まさにGPGPUの為の実装みたいなもんなのに・・・
738:デフォルトの名無しさん
07/06/26 20:32:02
Larrabeeは2009-2010登場のでGPU軍勢が散々広まってしまった後だ。
それにGPUは3世代進歩する。
専用ライブラリやランタイムが必要ならISAがx86である意味は薄い。
ましてや32コアを意識してプログラムを組めなんて気の遠くなることは・・・
Larrabeeだけこける。
GPU軍勢の影の総大将がMicrosoftであることは間違いない。
739:デフォルトの名無しさん
07/06/26 20:52:27
>>737
じゃあDirectX10.1が出る頃には対応するんじゃないか
740:デフォルトの名無しさん
07/06/26 21:11:16
PeakStreamを忘れないでください…と思ったけど買収されたしナァ
741:デフォルトの名無しさん
07/06/26 22:39:50
>>738
そんなばかなｗ
GPU軍勢って、nVIDIAだけじゃん。
結局IntelとAMDの天下だよ。
742:デフォルトの名無しさん
07/06/26 22:46:43
ララビー来るまでにTeslaがどれだけ普及するかだなぁ。
取り敢えずCUDA1.0を788GTSで動かすかな。
743:デフォルトの名無しさん
07/06/26 22:58:45
歴史的に見て、このプロセッサ(GPU)をCPUが取り込もうとして
失敗する事は殆ど無い。最終的にCPUに取り込まれるのは必然だと思われ。
性能云々の問題ではすまない。それで住むならMIPSは勝利していたはず。
キーとなるとは、いかにGPUを汎用的に使えるようにするか だ。
GPUのメリットはぶっちゃけてしまえばコア数の差だ。これがもっと汎用的な事が可能なCPUもコアが増えるとなれば大変だ。
向き不向きで確かにGPUの並列化のほうが得策かもしれないが、その差が微々たる物であった時、はじめは部分的に使われても、最終的には全てを飲み込まれてしまう。
CUDAがx64やVistaに対応しないとか、馬鹿な所で詰まってる場合ではない。
今のメリット(先行)を生かさないと・・・。
本当に何を考えてるんだか・・・。
744:デフォルトの名無しさん
07/06/27 01:05:29
先生！
強い電波を観測しますた！！
745:デフォルトの名無しさん
07/06/27 01:39:32
>>743
まー、さっさと対応して欲しいよね。
俺もCPUに取り込まれてx86になったら、人は流れると思う。
特定分野はわからんけど、それならそれでx64に対応しろよ。
何もかもが中途半端
746:デフォルトの名無しさん
07/06/27 01:45:07
長文いってみようか。
性能ではなく普及台数の勝ち負け（プラットフォーム足り得るか）で言えばTeslaは間違いなく「負け」だな。
研究者は独りでｵﾅﾆｰしてﾊｧﾊｧできるだろうが、需要となるキラーアプリが無い限り一般消費者が飛びつくわけがない。
どっかのアホがPPUでレイトレとか風呂敷広げてたが、PPUと同じように普及せず終わる。
（つかそもそもTeslaは一般向けじゃねぇし）
GPUはGPUたる所以のラスタライザ周りのハードワイヤード機能が足枷となって
電力消費の観点からも性能は伸び悩むだろうが、Vistaや3Dゲームで元々GPUは需要があるだけに可能性はある。
ただ現状ではVistaは全く普及していないし、CUDA・CTMとベンダ毎に仕様が異なるから
2010年にLarabeeが登場する頃までは標準化も達成されずグダグダが続くだろう。
ってことでIntelとAMDが談合してx86にデータ並列のストリーム処理命令を新たに追加して終わりだな。
LarabeeでもFusionでも使えるとなれば勝ち決定。
747:デフォルトの名無しさん
07/06/27 02:10:44
と思ったがLarrabeeは全部のコアでフルx86が走るのか。
そうなると>LarabeeでもFusionでも使えるとなれば～は無いな。
748:デフォルトの名無しさん
07/06/27 02:28:25
CPU/MCHどっちにくっついていようがオンボードVGAがシェーダー重視で肥大化して
いったら、逆にS3（VIA）その他の弱小グラフィックスが再び脚光を浴びる。
（PCIeカードの）GPGPUは大学の研究室/個人レベルで使われるだろうが、それで終わる。
チップ自体の価格は大量生産を背景に競争力を持てるが、プログラミングコスト、電力
コストを考えると中～大規模案件では採用されない。
Larrabeeは詳細不明、リリース次期から逆算すると現時点でテープアウトしてなさそう。
後藤記事によると「“練習版”、本格的な製品とは言えない」(業界関係者)。とのことで、
実用化への道は長い。
5年後を予想すると、HPCクラスタ界隈はOpteronやXeonやPowerPCが引き続き使われ、
クライアント環境でのベクトル演算/SIMDはSSEの進化で間に合う。
749:デフォルトの名無しさん
07/06/27 02:38:09
639 ：Socket774 [sage] ：2007/06/18(月) 23:35:29 ID:j/fCz3TG
URLﾘﾝｸ(it.nikkei.co.jp)
システム価格の安いｘ８６サーバーのクラスターシステムへの需要シフトが
継続するとＩＤＣではみています。
２００６年におけるｘ８６サーバーは前年比４０．６％増で、４年連続で前年比プラス
成長となりました。国内ＨＰＣ市場におけるｘ８６サーバーの出荷金額構成比は、
過去最高の３６．６％に達しました。
ＲＩＳＣサーバーからｘ８６サーバーに民間企業のＨＰＣ需要がシフトしたとみられ、
民間企業向けの大規模クラスターシステムが好調でした。
678 ：Socket774 [sage] ：2007/06/27(水) 01:35:36 ID:Kgk8gcuA
Sun，ペタフロップスを実現可能なSolaris機を披露へ
URLﾘﾝｸ(techon.nikkeibp.co.jp)
Rangerには米AMD社のクアッド・コアを6576個以上搭載する。
当初のピーク性能は105TFLOPSだが，2007年中にピーク性能を
421TFLOPSに引き上げる計画である。
IBM社の次世代BlueGene，米Argonne研が導入へ
URLﾘﾝｸ(techon.nikkeibp.co.jp)
今回のBlue Gene/Pの演算性能は114TFLOPS。
2007年秋には3万2768個のプロセサから成るシステムになる。
各プロセサは，4個のCPUコアを1チップ上に集積した，いわゆる
クアッド・コアである。
750:デフォルトの名無しさん
07/06/27 02:39:19
670 ：MACオタ [sage] ：2007/06/26(火) 22:25:47 ID:E+b+TZBO
Blue Gene/Pのプレスリリースす。
URLﾘﾝｸ(www-03.ibm.com)
---------------------
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を超えるロードマップわ現実的す。
751:デフォルトの名無しさん
07/06/27 02:41:21
変なの沸きすぎ
752:・∀・）っ-○◎●
07/06/27 04:23:26
俺Vista x64で8600GTだけどDirectXしかねーべ？
753:デフォルトの名無しさん
07/06/27 05:29:45
Larrabeeってどうやって普及させるつもりなんだろうか。
754:デフォルトの名無しさん
07/06/27 11:13:19
最終的にはCPUと統合らしいから
普通に次世代CPUとしてでしょ。
何となくチップセットに内蔵してきそうな気もする。
っていうか、単体で出さないでしょ？ｗ
科学技術分野に出すかも知れないけど、普及版は統合かと
755:デフォルトの名無しさん
07/06/27 12:35:48
出るのは pcie gen 2 カードでだよ
価格は10万前後
756:デフォルトの名無しさん
07/06/27 15:31:56
つかストリームコンピューティングって市場がそもそもないだろ
せいぜい研究機関とか大学で細々と使われるぐらいで
結局ソフトウェアが無ければ普及しない
リアルタイムレイトレがGPUラスタライザを凌駕するとか真顔で言ってる奴がいるけど
ポリゴンとピクセルが1:1に限りなく近付くようになるならまだしも
法線マップとかのイメージスペース技法の発明でそんなことはこの先起こらない
757:デフォルトの名無しさん
07/06/27 16:43:33
GPUじゃないけど一番敷居が低いのはやっぱりCell?
758:536
07/06/27 16:56:17
>>757
思いっきり高い敷居を跨ぐ為に、誰もが俺様ライブラリを作っている状態ですが。
759:デフォルトの名無しさん
07/06/27 17:06:03
>>756
＞つかストリームコンピューティングって市場がそもそもないだろ
あるけど言わない。飯の種だから。
潜在的需要はいくらでもある。
＞リアルタイムレイトレがGPUラスタライザを凌駕するとか真顔で言ってる奴がいるけど
＞ポリゴンとピクセルが1:1に限りなく近付くようになるならまだしも
それ以外にも、レンダリングパスが多くなりすぎるケースや、
ラスタ処理では不可能な処理や、誤魔化していた処理、
そういった高レベルの処理を入れていくと、ラスタライザでは限界がある。
光源が増え、シャドーが幾何級数的に増加したら、従来のラスタライザではどうしようもなくなる。
最終的にはレイトレとラジオシティを組み合わせたものしか生き残れない。
760:デフォルトの名無しさん
07/06/27 18:14:04
>>759
> 潜在的需要はいくらでもある。
そりゃ潜在需要がなけりゃ誰も新規にストリームプロセッサに投資なんてしない
俺が言いたいのはGPUに対する3Dゲームのような決定的な市場があるのかってこと
詐欺まがいのソフト作って無知相手に売ってもせいぜい売り上げは数百～数千万円程度だろ
> 光源が増え、シャドーが幾何級数的に増加したら、
> 従来のラスタライザではどうしようもなくなる。
またまたご冗談を
勘違いしやすいがシャドーマップってのもコヒーレントレイだからな
ピクセル単位でシャドーレイ飛ばすのとシャドーマップ描画して参照するのとを比べれば
圧倒的に後者の方が効率的だし、そもそも光源数とシャドーの増加量に比例して
負荷も比例するのはレイトレも同じ
おまけにレイトレは動的シーンに致命的に弱い
俺はこの先もリアルタイム3DはGPUラスタライザで変態的テクニックを多用していくことに変わりないと考えるね
一次レイと一次シャドーレイだけで息切らしてるようなリアルタイムレイトレは期待できない
761:デフォルトの名無しさん
07/06/27 19:06:27
>>760
>そりゃ潜在需要がなけりゃ誰も新規にストリームプロセッサに投資なんてしない
>俺が言いたいのはGPUに対する3Dゲームのような決定的な市場があるのかってこと
それを教えてほしけりゃ自分で探しな～
>詐欺まがいのソフト作って無知相手に売ってもせいぜい売り上げは数百～数千万円程度だろ
確かに数億～数百億のプロジェクトを仕切っているあなたにはたいした額ではないですね～
でも会社としてはそういう態度で仕事に望まれると困るんですが・・・
つか通常のGPUで盛り上がっているし。
意見は貴重だけどよそでやってくれないかな～？
762:デフォルトの名無しさん
07/06/27 19:12:23
レイトレの話はさすがにスレ違いだけど、
「GPUに対する3Dゲームのような決定的な市場」があるのなら是非知りたいね。
763:デフォルトの名無しさん
07/06/27 19:36:03
言う気無いならがんばるなよ。言わなきゃ論証にならないんだからさ。
764:デフォルトの名無しさん
07/06/27 19:41:30
>763
誰に言ってるの？
765:536
07/06/27 20:15:23
少なくとも漏れの周りでは高速に演算したいと言う要求が色々ある。
「面倒だから1Uサーバ機を100台単位で並べろ」ってのから「4core2CPUは高いからなんとかならんか?」まで千差万別。
前者の場合でも、「1U機にGPU入れればラック筐体単位で節約できる可能性がある」となれば興味を示すだろう。
(他社のアクセラレータボードに較べて)安いことは充分刺激になっているよ。
766:デフォルトの名無しさん
07/06/27 21:57:15
スーパーコンピュータTop500、IBMが依然トップ。日本勢はトップ10圏外に
URLﾘﾝｸ(www.itmedia.co.jp)
プロセッサ別で見ると、Intelプロセッサ搭載システムが57.8％を占めた。
前回の52.5％よりもわずかに増えている。次に多かったのはAMDで21％、
前回の22.6％からは減少した。IBMのPowerプロセッサは17％だった。
また、デュアルコアプロセッサ搭載システムが増えており、
IntelのWoodcrest搭載システムは前回の31台から205台に、
デュアルコアOpteron搭載システムは75台から90台に拡大した。
767:デフォルトの名無しさん
07/06/27 23:16:43
>>760
＞ピクセル単位でシャドーレイ飛ばすのとシャドーマップ描画して参照するのとを比べれば
馬鹿じゃねーのか？シャドーレイなんて飛ばす必要ないぞ。
＞負荷も比例するのはレイトレも同じ
大雑把に、レイトレの負荷はピクセル数に比例する。
光源数やシャドーの数には影響されない。
＞おまけにレイトレは動的シーンに致命的に弱い
そりゃ今はレンダリング速度が遅いだけだ。
1/60秒で描画できるようになったら、逆転する。
768:デフォルトの名無しさん
07/06/27 23:29:10
シャドーｗｗｗｗｗｗｗｗｗ
769:デフォルトの名無しさん
07/06/27 23:34:49
そうなんだよね、折角「ラスタスキャンだとデータ量が増える」からとベクタデータになった処理が、
「解像度が上がるとベクタデータは級数的に増える」からと結局ラスタデータになったりしているしね。
尤も、今や8000x8000なんて画像のフィルタリング処理がオンメモリでできるからこそだけれども。
770:デフォルトの名無しさん
07/06/28 00:11:21
>>767
> シャドーレイなんて飛ばす必要ないぞ。
素人か？1次レイ飛ばすだけでは影は出来ないってのも分からんのか？
誰もラジオシティの話なんてしてねぇぞ
> 大雑把に、レイトレの負荷はピクセル数に比例する。
> 光源数やシャドーの数には影響されない。
レイトレの負荷が解像度に比例するのは当たり前
光源数が増加してもレイトレは計算量が変わらないとでも思っているのか？
確かにラスタライザはレイトレと比較すれば光源1個あたりのコストが高いが
現状最速のコヒーレントレイ技法であるDeferred Shadingを使えば
RTRTが可能なほど高速なハード上では、それ以上に高速に動く（＝より高い複雑度のシーンを扱える）
> 1/60秒で描画できるようになったら、逆転する。
ラスタライザが生成するコーヒレントレイの圧倒的な速度と効率性という前提がある以上
繰り返すがRTRTが可能なほど高速なハード上では、ラスタライザはより高速に動作する
インコヒーレントレイをレイトレで処理して他は通常通り高速にラスタライザで処理するなら分かるが
大方の研究者の云う通りレイトレそれ自体がラスタライザを消し去ることはあり得ない
771:デフォルトの名無しさん
07/06/28 00:13:13
レイトレーシングのスレはここですか？
772:デフォルトの名無しさん
07/06/28 00:41:58
いちおうGPGPUネタではある。
773:デフォルトの名無しさん
07/06/28 05:06:41
ヲタゲーCGはもうお腹一杯。
もっと単純に、天文物理の多体問題を解くみたいな
GRAPEや地球シミュレータとの比較で頼む。
774:デフォルトの名無しさん
07/06/28 07:00:51
Grapeは事実上の敗北宣言が出てたじゃん。
「価格辺り消費電力が大きい」とか微妙な逃げ口上つきで。
775:デフォルトの名無しさん
07/06/28 12:27:32
>>770
＞誰もラジオシティの話なんてしてねぇぞ
俺はしている。ラジオシティ使わずに、レイトレでソフトなライト処理は不可能だ。
776:デフォルトの名無しさん
07/06/28 12:46:31
>>770
＞RTRTが可能なほど高速なハード上では、それ以上に高速に動く（＝より高い複雑度のシーンを扱える）
とは限らない。
例えば、ラスタライザ型では膨大な量の半透明の処理を「完全」に正しく処理するのは非常に困難。
PowerVRのような方法を使えば完全にできるのだが、タイル(チャンク)を細かくしたらレイトレ型と同じだ。
第一、一次レイに限定していないし、それ以上で作られる品質をラスタライザ型で作るのは不可能。
ラスタライザ型で表現できる品質レベルで言えば、そりゃRTRTが可能なハードで上で、
それ以上に高速に動くのはあたりまえ。そんなことは小学生でもわかるわ。
人間が考えうる高品質の画像を作っていく上で、無限の計算力があるなら、
ラスタライズ型の処理なんてあり得ない。
所詮、計算力が十分になるまでの、その場しのぎ、誤魔化しの手法にすぎないんだよ。
RTRTが可能になれば、ラスタライザは死滅する。パレットによるタイリング手法が死滅したようにね。
777:デフォルトの名無しさん
07/06/28 13:48:46
非リアルタイムのアニメ映画でさえもRTはそれほど使われてないんだが・・・
778:デフォルトの名無しさん
07/06/28 14:45:23
とりあえずレイトレしなくてもいいからオフラインレンダラ並の
アンチエイリアスできるようになってから話しろよ
779:デフォルトの名無しさん
07/06/28 15:23:10
>>777
その通り
スキャンラインラスタライザは現在でも多数のオフラインCGで使用されている
まぁ>>776みたいな信者はオノレの信じたいことだけを信じる現実の見えない典型的な馬鹿だから
せいぜい海外の論文でも崇拝しながらRTRTをこのまま妄信し続けてもらいたいね
Larrabeeが出たら是非RTRTを実装してもらいたい
もっとも同時期の最新GPU上で動く最新デモの足元にも及ばんだろうが
品質の面でも解像度の面でもな
780:デフォルトの名無しさん
07/06/28 15:28:11
> 無限の計算力があるなら
この前提も妄想だな
そもそも現在の半導体のドミナントデザインたるCMOSは
20nmプロセス前後で限界を迎えるという事実をお忘れか？
781:デフォルトの名無しさん
07/06/28 16:02:26
>>780
忘れてないよ。でも、技術の発達により、膨大な計算量が扱える方向に進むのだから、
究極的にはどこを目指すかという点で、無限の計算力があるときどうなるかを考えることは無意味ではない。
３０年後のＣＰＵのスペックはどのレベルか考えてみるのもいい。
１００コア程度なら２０１０年前後で投入してくるだろうし。
782:デフォルトの名無しさん
07/06/28 16:07:50
>>779
＞品質の面でも解像度の面でもな
鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングするのでも、
ポリゴンラスタライズ型が勝てるとでも思ってるの？
想定している品質や分野を意図的に制限すれば、そんなことはいくらでもいえる。
783:デフォルトの名無しさん
07/06/28 16:13:04
> 鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングするのでも、
> ポリゴンラスタライズ型が勝てるとでも思ってるの？
> 想定している品質や分野を意図的に制限すれば、そんなことはいくらでもいえる。
「鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングする」ことなんてのはまさに
「想定している品質や分野を意図的に制限す」ることだわな
自己矛盾にすら気付かん馬鹿ですね
相手するだけ時間の無駄か
784:デフォルトの名無しさん
07/06/28 16:24:45
だいだい反射や屈折等のインコヒーレントレイに関しては>>770で
「インコヒーレントレイをレイトレで処理して他は通常通り高速にラスタライザで処理するなら分かる」と言っているだろう
レイトレとラスタライザが「完全に」同調してレンダリングできる時点で
コヒーレントレイをレイトレで処理するなんてのは馬鹿馬鹿しいにも程がある
まさかとは思うが、コヒーレントレイに関してもレイトレがラスタライザより
高速に描画できるとでも思っているのか？
785:デフォルトの名無しさん
07/06/28 16:34:55
>>783
＞「想定している品質や分野を意図的に制限す」ることだわな
だから、それを言っているのだが。
矛盾ではなく、そういう例を出しているのが読めない馬鹿か？それとも意図的に誤読しているのか？
本気で俺が「制限すること」でないと思って書いていると思うなら、お前は読解力がない。
786:デフォルトの名無しさん
07/06/28 16:56:42
>>785
横レスだけどそんな皮相的な反応されても・・・
「意図的に制限すれば何とでもいえる」を批判の言葉として用いているということは、
「より制限の緩い、一般的な用途でRTの方が優秀である」という主張を内包している
としか思えないわけだけど、
「鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングする」という、
これまた意図的に制限された状況を持ち出しているのが矛盾だということ。
という流れなんじゃない？
Ice Age のスタッフがRTサイコーって言ってたよとか、そういう実分野での応用に
ついて検証するしかないんじゃないかな。
787:デフォルトの名無しさん
07/06/28 17:20:19
>>786
＞「より制限の緩い、一般的な用途でRTの方が優秀である」という主張を内包している
＞としか思えないわけだけど、
そうではなく、膨大な計算量が使える環境で、
どのシーンにも使える究極の品質を目指すならＲＴ以外は論外って事。
ポリゴンラスタライズ型は、計算量が乏しい環境で、
上手く誤魔化す程度の品質においてアドバンテージがあるだけだ。
現状の計算機環境、要求品質でポリゴンラスタライズ型を否定しているわけではない。
が、そう遠くない将来、ＧＰＵもポリゴンラスタライズも死滅する。コプロがＣＰＵに取り込まれたように。
788:デフォルトの名無しさん
07/06/28 17:55:12
「膨大な計算量」を何に使うかはデザイナやアーティストが決めるんじゃないかな。
789:デフォルトの名無しさん
07/06/28 18:08:20
>>787
俺の質問に答えろよ
> まさかとは思うが、コヒーレントレイに関してもレイトレがラスタライザより
> 高速に描画できるとでも思っているのか？
一連のお前の発言からすると、コヒーレントレイはレイトレで描画してもラスタライザで描画しても
『数学的に完全に等価である』という大前提をお前は知らない/理解していないようだな
純粋に両者のアルゴリズムの本質(nature)により、コヒーレントレイの描画で
レイトレがラスタライザを速度で上回ることなど
（お前がいくら期待しようが）あり得はしないんだよ
あるとすれば、それは非本質的な部分がボトルネックになっているに過ぎない
ゆえにコヒーレントレイの描画でレイトレがラスタライザを駆逐することなど起こりはしない
お前の「そう遠くない将来、ＧＰＵもポリゴンラスタライズも死滅する」という主張は
全くもって希望的観測に基づいたドグマだ
重要なのはいかに同時期の市場情勢や需要に適合するかであって
シンプルで正確な技術が必ずしもスタンダードとはならないことは歴史が証明している
790:デフォルトの名無しさん
07/06/28 18:40:09
>>789
＞> まさかとは思うが、コヒーレントレイに関してもレイトレがラスタライザより
＞> 高速に描画できるとでも思っているのか？
だから、俺はそんなことは言ってないだろ。
コヒーレントレイに限るなら、想定している品質や分野を意図的に制限しているといっているだけだ。
＞シンプルで正確な技術が必ずしもスタンダードとはならないことは歴史が証明している
シンプルで正確な技術がどっちのことを言っているのか知らんが、
将来のポリゴンラスタライズについても同様のことが言えるな。
ＲＴＲＴのゲームも出てきていることだし、
ＣＰＵパワーの使い道としても俺はＲＴＲＴの今後の発展に期待する。
どっちが残るかなんて歴史が証明すればいいし、今拘る気はない。
ＧＰＵとラスタライズが死滅する方が新しい発展があって面白そうだから、
俺が勝手に思っているだけでいいよ。
791:デフォルトの名無しさん
07/06/28 18:45:20
URLﾘﾝｸ(www.hc.ic.i.u-tokyo.ac.jp)
792:デフォルトの名無しさん
07/06/28 19:52:56
GPUとラスタライザが死滅するほうが新しい発展があるって思える根拠に興味が
793:デフォルトの名無しさん
07/06/28 19:56:39
思ってるだけでいいならだらだらと書き下すなと
794:デフォルトの名無しさん
07/06/28 20:22:54
GPUの応用研究で食おうと思ってたらLarrabeeが出て人生オワタような必死さですね
795:デフォルトの名無しさん
07/06/28 20:29:52
別にLarrabeeなり、CPUベースのレイトレなり、新しいものに期待をかけるのはいいと思うが、
なぜ、チャレンジの芽を摘むような批判をぶつけるのだろう。
GPUがなくなるとかラスタライズが死滅するとかは妄想に過ぎんかもしれんが、
そこに新しい技術の種があるかもしれないのに。
本当に死滅するならそれはそれでいいし、死滅しないとしてもそういう別のベクトルが
頑張るのはいいことだと思うぞ。妄想が原動力ならそれでもいいじゃないか。
796:デフォルトの名無しさん
07/06/28 20:31:27
＞なぜ、チャレンジの芽を摘むような批判をぶつけるのだろう。
「Intel にとって良いことは、コンピュータ業界にとって良いことだ」から
797:デフォルトの名無しさん
07/06/28 20:34:42
>>795
2chで吠えてないで結果を出せってことだろ。
798:デフォルトの名無しさん
07/06/28 20:42:01
LarrabeeもTeslaもPCI-Eカードの時点で終わってる
CPUに統合されない限り可能性はない
799:デフォルトの名無しさん
07/06/28 20:56:15
今現在結果を出そうとすることすら叶わないLarrabeeへの皮肉ですか
800:デフォルトの名無しさん
07/06/28 21:10:20
このスレを一通り眺めて思ったこと。
CPUも互換性を考えなければすっげ早くなるのだろうか。
801:デフォルトの名無しさん
07/06/28 21:17:40
>>800
それなんてCell？
802:デフォルトの名無しさん
07/06/28 21:21:15
CPUに統合されても可能性はない
803:デフォルトの名無しさん
07/06/28 21:22:24
誰かが20nmの壁を書いていたけれど、それを忘れてないと書きつつ100コアとか書いちゃうのが信じられない。
そしてまさしくその壁と戦っている人達が、実際にGPGPUにもLarrabeeにも興味を持っているわけなのだが。
804:デフォルトの名無しさん
07/06/28 21:33:56
>>798
メモリ事情を考えろ
URLﾘﾝｸ(pc.watch.impress.co.jp)
URLﾘﾝｸ(media.arstechnica.com)
805:デフォルトの名無しさん
07/06/28 21:38:58
つか俺的には何FLOPSとかどうでもいいからメモリのレイテンシを改善しろと言いたい。
お前ら何年間横這いなんだよ、と。
806:デフォルトの名無しさん
07/06/28 21:58:53
>>805
急に言われてもメモリも困る。
ちゃんとプリフェッチされるようなコードを書けば良い。
807:デフォルトの名無しさん
07/06/28 22:07:50
コードについて以外のことについてぐだぐだ書くのはやめろよ。
板違いだ。
自作板にでもスレッド立ててやれば良いだろ。
808:デフォルトの名無しさん
07/06/28 22:14:10
>>807
最近多いよな
こういう多分野にまたがって統合的にものが考えられない奴
809:デフォルトの名無しさん
07/06/28 22:25:33
>>808
どっかのいいかげんなwebサイト仕込みのネタをの適当に口まねするのが
「総合的にものを考える」ことかよｗ アホくさ。
810:デフォルトの名無しさん
07/06/28 23:49:45
スレのびすぎ
811:デフォルトの名無しさん
07/06/29 00:43:52
で、GPGPUで犬を洗えるようになるのか?
812:デフォルトの名無しさん
07/06/29 00:48:03
>>804
考えた
URLﾘﾝｸ(amb.sakura.ne.jp)
813:デフォルトの名無しさん
07/06/29 01:41:37
>>803
１００コアの話はインテルのロードマップのことだろ。あっちでは数百コアって書いてあったけど。
814:デフォルトの名無しさん
07/06/29 12:21:39
>>812
CSIが細くて笑った。
データの入りと出だけだから問題ないの･･･か？
815:・∀・）っ-○◎●
07/06/30 00:37:10
要するにNUMAでしょ
CPU間のCSIはコヒーレントバス的に使って、たまに他のノードのメモリにアクセスする感じでは。
816:デフォルトの名無しさん
07/06/30 12:03:02
ものすっごい初歩的な質問なのですが
for(int i=0;i<1024*1024;i++){
何か作業
}
の、何か作業をGPUに任せるのって
プログラム側からシェーダに対して
どういうコードを描けばいいのですか？Cgで
817:デフォルトの名無しさん
07/06/30 14:40:47
>>816
つ[cuda]
818:デフォルトの名無しさん
07/06/30 15:05:34
CUDA使えるGPUではないので無理です
ナニを読んだりググれば出てきますか？
819:デフォルトの名無しさん
07/06/30 15:58:30
Cgで普通のグラフィックのプログラム書いた経験はある？
820:デフォルトの名無しさん
07/06/30 16:19:54
今やろうとしているのが、まさにCgで普通のグラフィックプログラムやろうとしてるのですが
どうもわからなくて
はじめにどこ見ればいいですか？
821:デフォルトの名無しさん
07/06/30 16:33:15
>>820
まずは鏡を見て「俺はなんて馬鹿なんだろう」と気付くことから始めよう。
822:デフォルトの名無しさん
07/06/30 16:33:58
そうですね、バカだと思います
823:デフォルトの名無しさん
07/06/30 16:52:22
もう来ません＞＜
824:デフォルトの名無しさん
07/06/30 17:03:34
ぼくもやりたーい
┌─┐
｜も.｜
｜う |
│来│
│ね│
│え .|
│よ .|
ﾊﾞｶ ｺﾞﾙｧ │ !!.│
└─┤ ﾌﾟﾝﾌﾟﾝ
ヽ(`Д´)ﾉ ヽ(`Д´)ﾉ (`Д´)ﾉ （ `Д）
|￣￣￣|─|￣￣￣|─|￣￣￣|─□（ ヽ┐U
～ ～ ￣◎￣ .￣◎￣ ￣◎￣ ◎－>┘◎
825:デフォルトの名無しさん
07/06/30 21:31:04
GPGPU.ORG
826:デフォルトの名無しさん
07/06/30 23:58:24
普通のグラフィックプログラムでループを1000回も回すことがあるのか
ちょっと興味あるな
827:デフォルトの名無しさん
07/07/01 01:37:45
1000回じゃなくて百万回では？
828:デフォルトの名無しさん
07/07/01 04:45:32
数百万ループって・・・
どんだけ広い空間を定義する気なんだ・・・
829:デフォルトの名無しさん
07/07/01 04:52:17
別に広さの問題ではないと思うけど
830:デフォルトの名無しさん
07/07/01 05:32:31
>>826
単に1024×1024のテクスチャの各ピクセルに対して同じ「何か作業」をしたいだけだろ
831:デフォルトの名無しさん
07/07/01 17:03:08
そんな低レベルというか基本中の基本のことを他人に聞く
ような神経が考えられない。ゆとりか？
832:デフォルトの名無しさん
07/07/01 21:10:16
基本中の基本は
どこを調べたら出てくるんですか＞＜
833:デフォルトの名無しさん
07/07/02 11:02:30
>>832
>825
834:デフォルトの名無しさん
07/07/02 16:33:11
ジャパニーズで教えてください＞＜
835:デフォルトの名無しさん
07/07/02 16:40:38
つ[excite翻訳]
836:デフォルトの名無しさん
07/07/02 17:10:10
英語読めないとかどんな低学歴…
837:デフォルトの名無しさん
07/07/02 19:29:34
NVIDIA最強
URLﾘﾝｸ(pc.watch.impress.co.jp)
838:デフォルトの名無しさん
07/07/02 19:35:27
>837
お前個人は貧弱だけどな
839:デフォルトの名無しさん
07/07/02 19:44:34
一人一人は小さな火だが
840:デフォルトの名無しさん
07/07/02 19:44:39
なんでわかった？
841:デフォルトの名無しさん
07/07/02 20:31:55
なんだよ、お前らみんな英語読んでやってるってのかよ！
このバカバカマンコ！！！！
お前らなんかチンコの皮をチャックに挟んでしんじゃえ！！！
早く、GPUでのプログラミング教えろよ！
842:デフォルトの名無しさん
07/07/02 21:44:38
英語が嫌ならDirect3Dの日本語ドキュメントとかでHLSLとか勉強して、それをグラフィックス以外の用途に使えばいいやん
843:デフォルトの名無しさん
07/07/02 23:32:53
ゲフォ8600とか買ってCUDAするのがよろしいかと
844:デフォルトの名無しさん
07/07/03 10:33:42
8600GTSなら3万弱、8600GTなら1万円台中頃かな。
最早CUDA以外を勧める理由がないよ。
845:デフォルトの名無しさん
07/07/03 12:59:22
CUDAで使えるjava処理系だせや>えぬびでぃあ
846:デフォルトの名無しさん
07/07/03 14:19:49
>>844
x64やVistaに対応していないし、しそうにもない現状を考慮してもか？
流石に痛すぎるだろ・・・。
847:デフォルトの名無しさん
07/07/03 14:35:40
>>846
需要があれば出すでしょ。現状、TeslaはLinuxをメインにしているようだからね。
#Linuxならx64もあるわけで。
848:デフォルトの名無しさん
07/07/03 21:52:20
>>837
AMD K10最強
URLﾘﾝｸ(www.amd.com)