[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 2chのread.cgiへ]
Update time : 07/04 21:41 / Filesize : 200 KB / Number-of Response : 849
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

GPGPU



1 名前:デフォルトの名無しさん mailto:sage [2005/10/08(土) 23:15:20 ]
いつの間にやらCPUを超える演算性能を持ってしまったGPUに計算させてみるという
GPGPUについて語りましょう

参考リンク

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


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

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

686 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 02:02:23 ]
エミュ用のディレクトリのを実行した?

687 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 12:43:44 ]
サンプル動いたぉ

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

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

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

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

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

689 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 18:14:52 ]
あまりGPGPU指向の話じゃないねぇ

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

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

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

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

692 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 20:43:48 ]
逆にそれだけで済んでしまうところが肝なんだが。



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

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



694 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 22:12:09 ]
ソース上げてくれたらテストするよ。

695 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 23:13:18 ]
__device__ hogeから__device__hoge1を呼び出せないのは痛いなぁ。

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


696 名前:デフォルトの名無しさん mailto:sage [2007/06/07(木) 23:58:14 ]
なぁなぁ

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

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

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

698 名前:デフォルトの名無しさん mailto:sage [2007/06/11(月) 00:43:57 ]
GPGPU完全死亡
pc.watch.impress.co.jp/docs/2007/0611/kaigai364.htm

699 名前:デフォルトの名無しさん mailto:sage [2007/06/11(月) 02:23:44 ]
>>698
こんなのセルと大してかわらへん
並列度が低すぎる


700 名前:・∀・)っ-○◎● mailto:sage [2007/06/11(月) 03:08:05 ]
IA命令セットと互換ってのがみそだろ。
どうせSSEだろうけど。

701 名前:デフォルトの名無しさん mailto:sage [2007/06/11(月) 07:00:21 ]
で、どれだけ広まるのよ?一般に。
GPU以上に広まる可能性はあるのけ?

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



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

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

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

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

706 名前:デフォルトの名無しさん mailto:sage [2007/06/11(月) 19:57:52 ]
GPGPUよ、短い命であった。

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

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

709 名前:デフォルトの名無しさん mailto:sage [2007/06/11(月) 23:15:13 ]
しかも、CPUよりはGPUの方が安い罠。

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

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

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



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

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

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

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

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

717 名前:デフォルトの名無しさん mailto:sage [2007/06/15(金) 06:11:31 ]
ttp://journal.mycom.co.jp/articles/2007/02/15/isscc1/
>Stream ProcessorはDPUの他、2つのマイコン(MIPS 4000Ec)を搭載している。
>一つはSystem MIPSと呼んでおり、管理用OSが動作している。
>もう一つはDSP MIPSと呼んでおり、ここでメインアプリケーションが動作し、DPUをマネージメントする。

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

R600の場合command processorとUltra-Threaded Dispatch Processorを二つのMIPS
レーンをShaderと置き換えれば似てるかも知れんね。
ただしR600の場合そのレーンのブロックが4つある。

718 名前:デフォルトの名無しさん mailto:sage [2007/06/15(金) 19:06:16 ]
GPGPUでGrapeオワタと思たらメニーコアでGPGPUオワタ

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


720 名前:デフォルトの名無しさん mailto:sage [2007/06/19(火) 21:52:03 ]
画像のパターン検索?ならやってた人がいたと思う

721 名前:デフォルトの名無しさん mailto:sage [2007/06/19(火) 23:10:03 ]
まぁそういう用途はGPGPUよりもこういうほうが面白そうだけどスレ違いか
ttp://www.k2.t.u-tokyo.ac.jp/vision/M-SIMD_architecture/index-j.html

722 名前:・∀・)っ-○◎● mailto:sage [2007/06/20(水) 00:57:06 ]
DirectX10でGPUを汎用整数プロセッサとして使うサンプルある?



723 名前:デフォルトの名無しさん [2007/06/20(水) 01:19:03 ]
今更R600って、…MSX Turbo-R?


724 名前:部外者('A`)NEET ◆xayimgmixk mailto:sage [2007/06/20(水) 11:57:32 ]
あれは、R800だろ。

725 名前:デフォルトの名無しさん mailto:sage [2007/06/20(水) 16:44:13 ]
SEGA の体感ゲームだっけ?


726 名前:デフォルトの名無しさん mailto:sage [2007/06/21(木) 01:21:12 ]
R3000じゃなかったっけ?
ジオメトリエンジンついてるんだよな?

727 名前:デフォルトの名無しさん mailto:sage [2007/06/21(木) 05:39:54 ]
ttp://www.dailytech.com/article.aspx?newsid=7772
NVIDIA Announces Tesla General Purpose Processor Platform

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

>Teslaのソフトウェアプラットフォームは同社の汎用プログラミングモデル
>「CUDA (Compute Unified Device Architecture)」を利用。
>CUDAにはGPU用のCコンパイラが含まれており、
>Cプログラムに若干の修正を加えるだけで、
>CUDAコンパイラが処理をCPUとGPUに振り分けられる。

728 名前:デフォルトの名無しさん mailto:sage [2007/06/21(木) 06:05:30 ]
新しいGPGPU
ttp://www.gpucomputing.eu/index3.php?lang=en&page=_library1.php&id=3
ttp://www.gpucomputing.eu/index3.php?lang=en&page=_demo4.php&id=3

729 名前:ktkr! mailto:age!age! [2007/06/26(火) 11:26:50 ]
ktkr!

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

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

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




....ちょ、x64とかVistaは?

730 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 11:50:15 ]
お、情報THX。
早速見てみなくちゃだわ。

731 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 12:15:19 ]
もう完全にCUDAはやる気ないんじゃない?

うちはXP x64とVistaのデュアルブートだから、完全にアウト。


732 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 12:17:27 ]
>>731
大丈夫、TesraがあるからCudaは終わらない。



733 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 14:56:23 ]
こりゃあrapidmindの勝ちかな

734 名前:デフォルトの名無しさん [2007/06/26(火) 15:51:35 ]
x86_64 でXPとかビスタなんて使ってるやついたのか?

735 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 15:54:31 ]
GPGPU用途に限ればLinuxでもいいのか。
CUDAカーネルの5秒制限も払拭されることだし。

736 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 18:51:32 ]
残念。Larabeeの一人勝ち。

737 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 19:15:32 ]
CUDAの分野とかから考えて、Vistaとx64を避ける意味がわからん。
特にVistaでは、GPUの仮想化をサポートしてるんで、まさにGPGPUの為の実装みたいなもんなのに・・・


738 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 20:32:02 ]
Larrabeeは2009-2010登場のでGPU軍勢が散々広まってしまった後だ。
それにGPUは3世代進歩する。
専用ライブラリやランタイムが必要ならISAがx86である意味は薄い。
ましてや32コアを意識してプログラムを組めなんて気の遠くなることは・・・
Larrabeeだけこける。

GPU軍勢の影の総大将がMicrosoftであることは間違いない。

739 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 20:52:27 ]
>>737
じゃあDirectX10.1が出る頃には対応するんじゃないか

740 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 21:11:16 ]
PeakStreamを忘れないでください…と思ったけど買収されたしナァ

741 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 22:39:50 ]
>>738
そんなばかなw
GPU軍勢って、nVIDIAだけじゃん。
結局IntelとAMDの天下だよ。

742 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 22:46:43 ]
ララビー来るまでにTeslaがどれだけ普及するかだなぁ。
取り敢えずCUDA1.0を788GTSで動かすかな。



743 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 22:58:45 ]
歴史的に見て、このプロセッサ(GPU)をCPUが取り込もうとして
失敗する事は殆ど無い。最終的にCPUに取り込まれるのは必然だと思われ。

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

CUDAがx64やVistaに対応しないとか、馬鹿な所で詰まってる場合ではない。
今のメリット(先行)を生かさないと・・・。
本当に何を考えてるんだか・・・。


744 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 01:05:29 ]
先生!
強い電波を観測しますた!!

745 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 01:39:32 ]
>>743
まー、さっさと対応して欲しいよね。
俺もCPUに取り込まれてx86になったら、人は流れると思う。
特定分野はわからんけど、それならそれでx64に対応しろよ。
何もかもが中途半端

746 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 01:45:07 ]
長文いってみようか。

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

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

ってことでIntelとAMDが談合してx86にデータ並列のストリーム処理命令を新たに追加して終わりだな。
LarabeeでもFusionでも使えるとなれば勝ち決定。

747 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 02:10:44 ]
と思ったがLarrabeeは全部のコアでフルx86が走るのか。
そうなると>LarabeeでもFusionでも使えるとなれば〜は無いな。

748 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 02:28:25 ]
CPU/MCHどっちにくっついていようがオンボードVGAがシェーダー重視で肥大化して
いったら、逆にS3(VIA)その他の弱小グラフィックスが再び脚光を浴びる。

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

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

5年後を予想すると、HPCクラスタ界隈はOpteronやXeonやPowerPCが引き続き使われ、
クライアント環境でのベクトル演算/SIMDはSSEの進化で間に合う。

749 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 02:38:09 ]
639 :Socket774 [sage] :2007/06/18(月) 23:35:29 ID:j/fCz3TG
it.nikkei.co.jp/business/news/release.aspx?i=162405
システム価格の安いx86サーバーのクラスターシステムへの需要シフトが
継続するとIDCではみています。
2006年におけるx86サーバーは前年比40.6%増で、4年連続で前年比プラス
成長となりました。国内HPC市場におけるx86サーバーの出荷金額構成比は、
過去最高の36.6%に達しました。
RISCサーバーからx86サーバーに民間企業のHPC需要がシフトしたとみられ、
民間企業向けの大規模クラスターシステムが好調でした。

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

IBM社の次世代BlueGene,米Argonne研が導入へ
techon.nikkeibp.co.jp/article/NEWS/20070626/134832/
今回のBlue Gene/Pの演算性能は114TFLOPS。
2007年秋には3万2768個のプロセサから成るシステムになる。
各プロセサは,4個のCPUコアを1チップ上に集積した,いわゆる
クアッド・コアである。

750 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 02:39:19 ]
670 :MACオタ [sage] :2007/06/26(火) 22:25:47 ID:E+b+TZBO
Blue Gene/Pのプレスリリースす。
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を超えるロードマップわ現実的す。

751 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 02:41:21 ]
変なの沸きすぎ

752 名前:・∀・)っ-○◎● mailto:sage [2007/06/27(水) 04:23:26 ]
俺Vista x64で8600GTだけどDirectXしかねーべ?




753 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 05:29:45 ]
Larrabeeってどうやって普及させるつもりなんだろうか。

754 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 11:13:19 ]
最終的にはCPUと統合らしいから
普通に次世代CPUとしてでしょ。
何となくチップセットに内蔵してきそうな気もする。

っていうか、単体で出さないでしょ?w
科学技術分野に出すかも知れないけど、普及版は統合かと

755 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 12:35:48 ]
出るのは pcie gen 2 カードでだよ
価格は10万前後

756 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 15:31:56 ]
つかストリームコンピューティングって市場がそもそもないだろ
せいぜい研究機関とか大学で細々と使われるぐらいで
結局ソフトウェアが無ければ普及しない

リアルタイムレイトレがGPUラスタライザを凌駕するとか真顔で言ってる奴がいるけど
ポリゴンとピクセルが1:1に限りなく近付くようになるならまだしも
法線マップとかのイメージスペース技法の発明でそんなことはこの先起こらない

757 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 16:43:33 ]
GPUじゃないけど一番敷居が低いのはやっぱりCell?

758 名前:536 mailto:sage [2007/06/27(水) 16:56:17 ]
>>757
思いっきり高い敷居を跨ぐ為に、誰もが俺様ライブラリを作っている状態ですが。

759 名前:デフォルトの名無しさん [2007/06/27(水) 17:06:03 ]
>>756
>つかストリームコンピューティングって市場がそもそもないだろ

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

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

それ以外にも、レンダリングパスが多くなりすぎるケースや、
ラスタ処理では不可能な処理や、誤魔化していた処理、
そういった高レベルの処理を入れていくと、ラスタライザでは限界がある。
光源が増え、シャドーが幾何級数的に増加したら、従来のラスタライザではどうしようもなくなる。
最終的にはレイトレとラジオシティを組み合わせたものしか生き残れない。

760 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 18:14:04 ]
>>759
> 潜在的需要はいくらでもある。

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

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

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

俺はこの先もリアルタイム3DはGPUラスタライザで変態的テクニックを多用していくことに変わりないと考えるね
一次レイと一次シャドーレイだけで息切らしてるようなリアルタイムレイトレは期待できない

761 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 19:06:27 ]
>>760

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

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

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

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

つか通常のGPUで盛り上がっているし。
意見は貴重だけどよそでやってくれないかな〜?

762 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 19:12:23 ]
レイトレの話はさすがにスレ違いだけど、
「GPUに対する3Dゲームのような決定的な市場」があるのなら是非知りたいね。



763 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 19:36:03 ]
言う気無いならがんばるなよ。言わなきゃ論証にならないんだからさ。

764 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 19:41:30 ]
>763
誰に言ってるの?

765 名前:536 mailto:sage [2007/06/27(水) 20:15:23 ]
少なくとも漏れの周りでは高速に演算したいと言う要求が色々ある。
「面倒だから1Uサーバ機を100台単位で並べろ」ってのから「4core2CPUは高いからなんとかならんか?」まで千差万別。
前者の場合でも、「1U機にGPU入れればラック筐体単位で節約できる可能性がある」となれば興味を示すだろう。
(他社のアクセラレータボードに較べて)安いことは充分刺激になっているよ。

766 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 21:57:15 ]
スーパーコンピュータTop500、IBMが依然トップ。日本勢はトップ10圏外に
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台に拡大した。

767 名前:デフォルトの名無しさん [2007/06/27(水) 23:16:43 ]
>>760
>ピクセル単位でシャドーレイ飛ばすのとシャドーマップ描画して参照するのとを比べれば

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

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

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

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

そりゃ今はレンダリング速度が遅いだけだ。
1/60秒で描画できるようになったら、逆転する。

768 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 23:29:10 ]
シャドーwwwwwwwww

769 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 23:34:49 ]
そうなんだよね、折角「ラスタスキャンだとデータ量が増える」からとベクタデータになった処理が、
「解像度が上がるとベクタデータは級数的に増える」からと結局ラスタデータになったりしているしね。
尤も、今や8000x8000なんて画像のフィルタリング処理がオンメモリでできるからこそだけれども。

770 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 00:11:21 ]
>>767
> シャドーレイなんて飛ばす必要ないぞ。

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

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

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

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

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

ラスタライザが生成するコーヒレントレイの圧倒的な速度と効率性という前提がある以上
繰り返すがRTRTが可能なほど高速なハード上では、ラスタライザはより高速に動作する
インコヒーレントレイをレイトレで処理して他は通常通り高速にラスタライザで処理するなら分かるが
大方の研究者の云う通りレイトレそれ自体がラスタライザを消し去ることはあり得ない

771 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 00:13:13 ]
レイトレーシングのスレはここですか?

772 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 00:41:58 ]
いちおうGPGPUネタではある。



773 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 05:06:41 ]
ヲタゲーCGはもうお腹一杯。
もっと単純に、天文物理の多体問題を解くみたいな
GRAPEや地球シミュレータとの比較で頼む。


774 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 07:00:51 ]
Grapeは事実上の敗北宣言が出てたじゃん。
「価格辺り消費電力が大きい」とか微妙な逃げ口上つきで。

775 名前:デフォルトの名無しさん [2007/06/28(木) 12:27:32 ]
>>770
>誰もラジオシティの話なんてしてねぇぞ

俺はしている。ラジオシティ使わずに、レイトレでソフトなライト処理は不可能だ。

776 名前:デフォルトの名無しさん [2007/06/28(木) 12:46:31 ]
>>770
>RTRTが可能なほど高速なハード上では、それ以上に高速に動く(=より高い複雑度のシーンを扱える)

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

ラスタライザ型で表現できる品質レベルで言えば、そりゃRTRTが可能なハードで上で、
それ以上に高速に動くのはあたりまえ。そんなことは小学生でもわかるわ。
人間が考えうる高品質の画像を作っていく上で、無限の計算力があるなら、
ラスタライズ型の処理なんてあり得ない。
所詮、計算力が十分になるまでの、その場しのぎ、誤魔化しの手法にすぎないんだよ。
RTRTが可能になれば、ラスタライザは死滅する。パレットによるタイリング手法が死滅したようにね。

777 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 13:48:46 ]
非リアルタイムのアニメ映画でさえもRTはそれほど使われてないんだが・・・

778 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 14:45:23 ]
とりあえずレイトレしなくてもいいからオフラインレンダラ並の
アンチエイリアスできるようになってから話しろよ


779 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 15:23:10 ]
>>777
その通り
スキャンラインラスタライザは現在でも多数のオフラインCGで使用されている

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

Larrabeeが出たら是非RTRTを実装してもらいたい
もっとも同時期の最新GPU上で動く最新デモの足元にも及ばんだろうが
品質の面でも解像度の面でもな

780 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 15:28:11 ]
> 無限の計算力があるなら

この前提も妄想だな

そもそも現在の半導体のドミナントデザインたるCMOSは
20nmプロセス前後で限界を迎えるという事実をお忘れか?

781 名前:デフォルトの名無しさん [2007/06/28(木) 16:02:26 ]
>>780
忘れてないよ。でも、技術の発達により、膨大な計算量が扱える方向に進むのだから、
究極的にはどこを目指すかという点で、無限の計算力があるときどうなるかを考えることは無意味ではない。
30年後のCPUのスペックはどのレベルか考えてみるのもいい。
100コア程度なら2010年前後で投入してくるだろうし。

782 名前:デフォルトの名無しさん [2007/06/28(木) 16:07:50 ]
>>779
>品質の面でも解像度の面でもな

鏡面をもつ膨大な量の玉の映り込みを正確にレンダリングするのでも、
ポリゴンラスタライズ型が勝てるとでも思ってるの?
想定している品質や分野を意図的に制限すれば、そんなことはいくらでもいえる。



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

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

自己矛盾にすら気付かん馬鹿ですね
相手するだけ時間の無駄か

784 名前:デフォルトの名無しさん mailto:sage [2007/06/28(木) 16:24:45 ]
だいだい反射や屈折等のインコヒーレントレイに関しては>>770
「インコヒーレントレイをレイトレで処理して他は通常通り高速にラスタライザで処理するなら分かる」と言っているだろう

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

まさかとは思うが、コヒーレントレイに関してもレイトレがラスタライザより
高速に描画できるとでも思っているのか?






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<200KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef