[表示 : 全て 最新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/


47 名前:デフォルトの名無しさん mailto:sage [2005/11/13(日) 20:15:55 ]
PhysXもそろそろ出るね
CPU以外のパワーを利用するのって
一時的かと思ってたけど時代の潮流かな

48 名前:デフォルトの名無しさん mailto:sage [2005/11/22(火) 18:01:21 ]
staraxis.kazelog.jp/okiraku/2005/11/atiavivo_49a9.html
ATIのAVIVOエンコード機能は凄い!!

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

49 名前:デフォルトの名無しさん mailto:sage [2005/11/22(火) 22:17:01 ]
いや、Theaterっていう専用チップが乗ってるよ
www.4gamer.net/news.php?url=/news/history/2005.09/20050920190000detail.html

50 名前:デフォルトの名無しさん mailto:sage [2005/11/25(金) 12:27:04 ]
FAQ - GPGPU.org Wiki
www.gpgpu.org/wiki/FAQ


51 名前:デフォルトの名無しさん mailto:sage [2005/11/29(火) 00:05:32 ]
GPU GEMS2の日本語版が出たようだ

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

52 名前:デフォルトの名無しさん [2005/11/29(火) 00:06:17 ]
sageたままだった・・・orz

53 名前:デフォルトの名無しさん mailto:sage [2005/11/29(火) 00:09:53 ]
AGPメモリにフレームバッファ確保できなかったっけ?

54 名前:デフォルトの名無しさん mailto:sage [2005/11/29(火) 01:22:55 ]
>>10
Javaチップ、Javaアクセラレータ
なんてものがあるしな。
考えられなくもないな

55 名前:デフォルトの名無しさん mailto:sage [2005/11/29(火) 01:24:29 ]
>>19
むしろVMと速度だな。
C言語の中の人は
オブジェクト指向を使うと速度が遅くなる
から使わない方がいいとか未だにいっているからね。




56 名前:デフォルトの名無しさん mailto:sage [2005/11/29(火) 01:25:23 ]
>>28
JavaのGUI, Swing APIやJava3D APIの3Dレンダリングの
部分だけGPUに任せられたらいいねえ。

57 名前:デフォルトの名無しさん mailto:sage [2005/11/29(火) 01:29:20 ]
>>31
それも微妙なところではあるが。
Java SE 5 Tigerからかなりの高速化が実現されているし
Java SE 6 Mustangからはさらに高速化する。
Javaアプリ初回起動だけVM上で動いて
2回目以降からはネイティブで動くってことがあるわけで。
Javaアプリを起動するたびにVMをいくつも起動するという
問題も解消されるし。

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


58 名前:デフォルトの名無しさん [2005/11/29(火) 11:54:36 ]
>>56
Java3DはOpenGLかDirect Xがバックエンドになっているんだが。

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


59 名前:デフォルトの名無しさん [2005/11/29(火) 16:23:09 ]
これってグラボ変えたら動かなくなるんでしょ?
グラボなんてドンドン新しいのが出るんだからそんなの使えネェじゃん。

60 名前:デフォルトの名無しさん [2005/11/29(火) 16:42:24 ]
それを避けるための高級言語じゃないの?

61 名前:デフォルトの名無しさん mailto:sage [2005/11/29(火) 17:11:03 ]
自作板の雑談と何も変わらんな

62 名前:デフォルトの名無しさん mailto:sage [2005/11/29(火) 17:42:26 ]
大抵はグラボを変えても動きます
特に新しいものに変える場合は可能性は高いです
例えるなら>>59は「MMXってCPU変えたら動かないよね?」みたいな質問です

63 名前:デフォルトの名無しさん mailto:sage [2005/11/30(水) 00:55:00 ]
>大抵はグラボを変えても動きます
大抵って?

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

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

64 名前:デフォルトの名無しさん mailto:sage [2005/11/30(水) 01:01:32 ]
>>63
既にShaderはほぼ標準装備ですが何か?

65 名前:デフォルトの名無しさん [2005/11/30(水) 01:12:41 ]
>>63
並列アルゴリズムの実装のために少しでも安くて速い計算リソースを使おうという研究なんで、
互換性を気にして「10年後に動かなかったらどうするんだよ」という向きには用は無い。



66 名前:デフォルトの名無しさん mailto:sage [2005/11/30(水) 01:25:58 ]
そもそもGLSLはOpenGLドライバ側でコンパイルされてGPUのコードに変換されるものだから
原則的にはGPUが変わっても動くと考えても問題ない。
(バグや仕様で動かない可能性は100%否定できないが)

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

67 名前:デフォルトの名無しさん mailto:sage [2005/12/01(木) 19:23:35 ]
今までのGPUは後方互換をほぼ意識しないで拡張してきたからこれだけの性能が出たのだと思う。
今後もちゃんと動くかはかなり疑問に感じる。(GPGPUが一過性のような気がする。

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

68 名前:デフォルトの名無しさん [2005/12/01(木) 20:10:14 ]
まぁ一過性というのはそのとおりでGPUは通過点でしかないだろうね。
今はいろいろ試して、問題点を出したり適応範囲を模索したりしてる段階。
それを元にハードウェアも含めてだんだん方向性が決まってくるわけで。

69 名前:デフォルトの名無しさん mailto:sage [2005/12/01(木) 21:17:17 ]
GPUに本当に有用なアーキテクチャがあるならコプロと同じ運命をたどるでしょ。
リレースイッチをブザー代わりに使うような技術に発展性があるわけがない。


70 名前:デフォルトの名無しさん [2005/12/11(日) 06:22:53 ]
age

71 名前:デフォルトの名無しさん mailto:sage [2005/12/13(火) 05:47:10 ]
>>69
浮動小数点演算はコプロというか専用エンジンが無いとどうしようも無いぞ。
それはCELLとかも同じ。

72 名前:デフォルトの名無しさん mailto:sage [2005/12/13(火) 19:53:50 ]
整数演算もできるようになるのはいつ?

73 名前:デフォルトの名無しさん mailto:sage [2005/12/13(火) 21:27:15 ]
>>71
意味わからん。話が噛み合ってないな。

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

74 名前:デフォルトの名無しさん [2005/12/14(水) 16:26:15 ]
マシンに本物のFPU積んだ時には、嬉しくって毎日レイトレしてたな。

75 名前:デフォルトの名無しさん mailto:sage [2005/12/14(水) 16:41:40 ]
コプロ積んでもBASICが全く速くならなかった時には、orzだったな。



76 名前:デフォルトの名無しさん mailto:sage [2005/12/15(木) 20:19:33 ]
>>69
しかしブザーが出回るまでの間は有用だし生き延びるだろうさ。

77 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 09:48:59 ]
コプロ無しの少数演算って遅すぎだろ

78 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 09:56:39 ]
それよりGPGPUの話をしよう

79 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 14:40:11 ]
先生!誰もわかってないので話すことがありません!

80 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 18:07:10 ]
GPGPUは手段であって、目的じゃないからな。
なにか高速に計算したいものがあって、その手段としてGPGPUが良ければ使う。
目的がないのにGPGPUやろうぜとか言われても盛り上がらん。
手段のために目的を探すのはアホだしな。

81 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 18:47:17 ]
目的がないから手段も学ぶ必要ないもんな・・・・
日本発のGPGPUを使ったDivXエンコーダーとか作れれば盛り上がるのだろうが。

82 名前:デフォルトの名無しさん mailto:sage [2005/12/17(土) 20:29:41 ]
GPGPU = Game Programming Gems(プ

83 名前:デフォルトの名無しさん mailto:sage [2005/12/18(日) 03:24:22 ]
>>47
GRAPEは専用プロセッサのままなので他では使われないね。
コプロにしたほうが広がりやすい気がするけど帯域が問題なのかな。
www.itmedia.co.jp/news/articles/0405/28/news048.html

そして東工大のOpteronグリッドにはClearSpeedのSIMDアクセラレータが乗る
www.itmedia.co.jp/news/articles/0410/07/news039.html
japan.cnet.com/news/ent/story/0,2000047623,20075021,00.htm

84 名前:デフォルトの名無しさん mailto:sage [2005/12/19(月) 15:18:34 ]
Scoutって一番興味あるんですが、まだ公開はされていないんですか?

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

85 名前:デフォルトの名無しさん [2005/12/21(水) 01:05:14 ]
>>84
Brook for GPU じゃだめなの?




86 名前:デフォルトの名無しさん mailto:sage [2005/12/21(水) 13:29:13 ]
Vista時代で、常に3D使うようになったらGPGPUも終わりな気がするのは
俺だけかな。

87 名前:デフォルトの名無しさん mailto:sage [2005/12/22(木) 17:50:35 ]
AeroGlassをEnableにすれば大丈夫じゃない?

88 名前:86 mailto:sage [2005/12/22(木) 18:09:05 ]
AeroGlassをEnableにすると、常にシェーダーが使われているわけだから
GPGPUには使えないのではないかと思ったんだけど。

89 名前:デフォルトの名無しさん mailto:sage [2005/12/22(木) 20:22:33 ]
>>86
GPGPUって科学技術計算等の激しく重い演算用だろ?
普通のアプリ走らせてる横でやる必要もないと思うが。

90 名前:デフォルトの名無しさん mailto:sage [2005/12/22(木) 20:29:13 ]
聞きたいのは二つのシェーダー使うアプリを同時に使用できるかと言うこと。
できるのならWindowsがGPU使っていてもGPGPUできるだろう。
もしできないのであったら、GPGPUするときはAeroGlassをオフにしなければならない。
>>89が言うことももっともだが、いちいちそんなことが必要になるなら価値は少し下がる。

91 名前:デフォルトの名無しさん mailto:sage [2005/12/23(金) 00:15:44 ]
GPUにもコンテキストスイッチは存在するんじゃね?

92 名前:87 mailto:sage [2005/12/23(金) 00:16:23 ]
ごめん、英語間違ってますた…disableだ…_| ̄|○

93 名前:デフォルトの名無しさん mailto:sage [2005/12/23(金) 00:34:05 ]
VistaではGPUが仮想化されて、DirectXのデバイスロストが無くなる。
GPGPUとAeroGlassの併用も可能と思われ。

94 名前:デフォルトの名無しさん mailto:sage [2005/12/25(日) 18:37:14 ]
>>90
GUIは(ゲームなどの描画と違って)四六時中描画してるわけではない。

95 名前:デフォルトの名無しさん mailto:sage [2005/12/26(月) 05:54:47 ]
>>90
多分できるだろうけど、切り替えが発生したら猛烈に遅くなる予感。
GPGPUの唯一の価値=速度だから、あんまりそういう用途には向いてないような・・・



96 名前:デフォルトの名無しさん [2005/12/26(月) 19:08:48 ]
計算用に、もう一枚刺す。

97 名前:84 mailto:sage [2005/12/26(月) 19:49:18 ]
>>85

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

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


98 名前:デフォルトの名無しさん mailto:sage [2005/12/26(月) 21:46:14 ]
>多分できるだろうけど、切り替えが発生したら猛烈に遅くなる予感。
CPUはそれなりに現実的にマルチタスクできてるんだから
GPUだけできない理由は何もないような。
ドライバがそこらへんに対応してれば。

99 名前:デフォルトの名無しさん mailto:sage [2005/12/27(火) 16:55:05 ]
>>98

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


100 名前:デフォルトの名無しさん mailto:sage [2005/12/27(火) 17:07:20 ]
並列動作可能なら、CPU側のタスクに合わせてタスクスイッチする必要はないんじゃない?
OS分の描画やりながら、遊んでるユニットでGPGPUの計算するとかできんの?

101 名前:デフォルトの名無しさん mailto:sage [2005/12/27(火) 19:25:35 ]
VistaになってもUIは2kスタイルに設定するから問題ない。

102 名前:デフォルトの名無しさん mailto:sage [2005/12/27(火) 22:44:45 ]
>>100

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

103 名前:デフォルトの名無しさん mailto:sage [2005/12/27(火) 22:56:31 ]
結果はどの道メインメモリに書き戻すんだからそれほど大きなワークは必要なさそうな気もするが。
scatter&gatherつってもその範囲は高が知れてるし。
まあ用途次第だけど。

104 名前:デフォルトの名無しさん mailto:sage [2005/12/28(水) 21:03:56 ]
GPGPUを使ったプログラムを誰かうpしてくれよ

105 名前:デフォルトの名無しさん mailto:sage [2006/01/08(日) 11:27:22 ]
だれかエンコーダー作ってよ。
sf.net探したけど見つからないし。



106 名前:デフォルトの名無しさん [2006/01/21(土) 15:20:00 ]
保守。

107 名前:デフォルトの名無しさん mailto:sage [2006/01/21(土) 16:23:17 ]
>>89
MFLOPS単位で処理能力公表してるし、浮動小数計算するのがメインっぽいね。
代表的なのとしては、動画再生支援くらい?
画像音楽動画エンコくらいしかおもいつかね。
他に浮動少数が活躍する場面ってなにがあるかな?

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

108 名前:デフォルトの名無しさん [2006/01/22(日) 11:00:38 ]
今こそGPGPUを活用するときではなかろうか。
pc.watch.impress.co.jp/docs/2006/0120/mobile321.htm

109 名前:デフォルトの名無しさん mailto:sage [2006/01/22(日) 13:01:49 ]
H.264はAMDがYAMATOでデモってたけど、
やっぱ70Mbpsまでいくとコマ落ちするんだろうか。

110 名前:デフォルトの名無しさん mailto:sage [2006/01/22(日) 22:42:33 ]
PureVideoとか待ってられないから、オープンソースで
シェーダ実装のH.264デコーダーとかでないかな。

111 名前:デフォルトの名無しさん [2006/01/22(日) 22:46:15 ]
つかここム板なんだからGPGPUでhello, worldくらいやれ

112 名前:・∀・)っ-○●◎- ◆Pu/ODYSSEY mailto:sage [2006/01/22(日) 23:00:21 ]
だめだろ文字列を描画する以上の複雑な計算が無い
描画を豪華にしたいなら普通にシェーダ普通に使えって話

113 名前:デフォルトの名無しさん [2006/01/25(水) 09:18:55 ]
ATI X1900スゲー化け物だね。

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


114 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 22:46:15 ]
純粋にグラフィック扱うならHDRでもAA効くATiの方がいいと自分は思ってるけど
VTFとか見てるとほかにも問題ありそうで怖い。

115 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 22:47:57 ]
まだまだ実用的ではないな



116 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 23:16:11 ]
X1800の時の爆熱問題を解決しないまま、
さらに熱い物を出してくるのは凄い。

117 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 23:30:00 ]
実際X1900なんてメディアのベンチ掲載用にとりあえず作ったやつでしょ。
数出さなければ、いくらでもできるよ。
普通のCPUだとただコア増やすだけじゃ意味無いけどGPUなんて増やせば増やすだけいいしね
まぁ一つが小さくて単純だからできるんだろうけど。

118 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 02:34:56 ]
3DMarkだけスコアが高いなんてさすがATIだな

119 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 03:55:46 ]
それでも48基って一度触ってみたいハァハァ

120 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 12:43:18 ]
>>119
お熱いのがお好き?

121 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 19:11:38 ]
Intelが45nm製造に成功って書いてあったけど、
実用化されれば90nmの製品がまったく同じものだと1/4の面積になるの?

122 名前:・∀・)っ-○●◎- ◆Pu/ODYSSEY mailto:sage [2006/01/26(木) 19:53:37 ]
原子・分子のサイズの限界もあるからまったく同じにはならない筈だよ。リーク電流対策とか必要だし。

123 名前:デフォルトの名無しさん [2006/01/27(金) 10:13:52 ]
>>10
速度が重要で、かつこれからやる処理の中でGPUだと著しく速い命令で解決できる処理を内包する時だろ?

124 名前:デフォルトの名無しさん mailto:sage [2006/01/27(金) 18:20:22 ]
GPGPUをやってみうと思い、試行錯誤しているのですが、
floatの配列を画像に変換してテクスチャとして貼り付け
オフスクリーンに出力された画像をfloatの配列に戻すまでは出来たのですが
シェーダー上ではテクスチャや出力する色情報がvec4やfloat4となっていて、
そのままfloatとして扱うことができません。どうすればいいのでしょうか?

125 名前:デフォルトの名無しさん mailto:sage [2006/01/27(金) 18:31:18 ]
>>124
つ スウィズル演算子

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



126 名前:デフォルトの名無しさん mailto:sage [2006/01/27(金) 18:39:12 ]

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

127 名前:デフォルトの名無しさん mailto:sage [2006/01/27(金) 18:50:10 ]
>>125-126
即レスありがとうございます。
これを参考にいろいろ調べてみます。

128 名前:デフォルトの名無しさん mailto:sage [2006/01/28(土) 02:14:37 ]
スレ立て以来初めてム板らしいやりとりが成立したなw

129 名前:デフォルトの名無しさん mailto:sage [2006/01/28(土) 16:48:11 ]
次はCPCPUの時代

130 名前:デフォルトの名無しさん mailto:sage [2006/01/28(土) 17:03:46 ]
みんなこれ読んだか?
ttp://grape.astron.s.u-tokyo.ac.jp/~makino/articles/future_sc/note011.html

131 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 02:08:39 ]
>>130
説明は面倒くさいが、その記事には同意しかねる。
GPGPU が万能じゃないなんて当たり前な話で、使いどころが分かってない奴は使わなければいいだけの話だ。
俺はゲーム屋だから、やらせることはいくらかある。だからやらせる。

132 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 13:28:06 ]
なあ最近ひらめいたアイデアなんだけど聞いてくれる?
普通テクスチャをシェーダにバインドするときの最大でも16ぐらいまででしょ?
でもテクスチャの代わりにキューブテクスチャを使えばx6枚使えることにならん?
例えばR32Fのシャドウマップを普通にバインドすると16だけど
RGBA32Fのキューブマップとしてバインドすれば16x6x4=384になる。ナイスーアイデーアじゃね?

133 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 13:46:53 ]
>>132
キューブの境界に連続性が無いデータだと、ちと不安だな。
あと、rgba にするのは、チャンネル間移動が無いことが前提だな。
いざというときには使える tips かもね。

134 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 13:05:44 ]
>>121
原子分子のサイズが主要な問題ではないんだけどな。
半導体製品の製造工程は理解できている?
#つーか、原子分子のサイズだけを問題にできるような製造技術があったら一財産築けるぞ。

135 名前:デフォルトの名無しさん mailto:sage [2006/01/31(火) 23:43:28 ]
v-infinity.seesaa.net/article/11073754.html
GPGPUを使っていると思われるエンコードソフト

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



136 名前:デフォルトの名無しさん mailto:sage [2006/01/31(火) 23:58:44 ]
>>135
>>48

137 名前:デフォルトの名無しさん mailto:sage [2006/02/01(水) 15:17:52 ]
記事先では、GPUではなく、CPU処理って書いてるけど
ぶっちゃけ、単なるシェーダーで処理してるだけなら、現行のGF/ATiのGPUでGPU処理できると思うんだが・・・。


138 名前:デフォルトの名無しさん mailto:sage [2006/02/01(水) 18:18:42 ]
GPUはUIの表示以外に使ってない。将来的には使う予定だろうけど。
じゃあ最初にCPU用コード書く必要ないじゃんね。もしかしてOSSのぱくり?

139 名前:亀レスだが mailto:sage [2006/02/13(月) 02:25:14 ]
>>31
> 大量のデータをひたすら単純処理する仕事はJavaの苦手とするとことだと思うのですが

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

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


140 名前:デフォルトの名無しさん mailto:sage [2006/02/13(月) 09:54:38 ]
>>139
おまえはJavaでソフトウェアレンダーでも書いてろ。

141 名前:デフォルトの名無しさん mailto:sage [2006/02/13(月) 10:54:25 ]
確かに多少ゆがんでるようだが>>31よりは事実に近いな

142 名前:デフォルトの名無しさん mailto:sage [2006/02/13(月) 14:35:11 ]
Java厨は消えろ。どうせシェーダなんて叩けないだろ。

143 名前:デフォルトの名無しさん mailto:sage [2006/02/14(火) 22:43:23 ]
Java氏ねPCの動作を重くする害虫ソフトめ!

144 名前:デフォルトの名無しさん mailto:sage [2006/02/14(火) 23:49:16 ]
重くなるのか?

145 名前:デフォルトの名無しさん mailto:sage [2006/02/15(水) 13:05:37 ]
>>139
単語に反応するだけじゃなくて、議論の流れを読めよ。



146 名前:すだこ [2006/02/27(月) 03:45:54 ]
実際問題として例えば

  LAPCKが動いた

とか

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

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



147 名前:デフォルトの名無しさん [2006/02/27(月) 12:07:53 ]
JavaのJITがGPGPUを使用するコードを吐くと嬉しい。
これが出来たら、ネイティブコード系の言語がいらなくなるかも。
性能面で。






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

前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