- 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/
- 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を使ったプログラムを誰かうｐしてくれよ
- 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 ]
- スレ立て以来初めてム板らしいやりとりが成立したなｗ
- 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を使用するコードを吐くと嬉しい。
これが出来たら、ネイティブコード系の言語がいらなくなるかも。
性能面で。
- 148 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 15:22:15 ]
- >>147
JavaからGPU使えばいいだけでは？
- 149 名前：デフォルトの名無しさん [2006/02/27(月) 16:15:47 ]
- 実行環境が対応することで
開発した当初は存在してないGPUも
活用できるようになるだろ。
WORAの思想もそのまま生かされる。
- 150 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 16:19:09 ]
- そのためのCgでは？
- 151 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 18:39:33 ]
- Cgは演算結果をメインメモリに書き出せない。
だから、基本的にはグラフィック処理にしか使えない
- 152 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 20:05:18 ]
- メインメモリに書き出すのはシェーダではなくAPIの役目では？
- 153 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 20:44:31 ]
- そういう仕組ができれば自然とCgやHLSLもサポートするだろう。
問題はいつサポートされるのかということと、まともなスピードで
出せるかということだ。
- 154 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 20:49:46 ]
- Direct3D10のOutputStreamみたいな話？
- 155 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 22:02:15 ]
- >>148
透過的にして欲しいということだろ？
現状VMもSSE2とか自動判別してつかうようになったり
ハードウェアアクセラレーションもDirectXやらOpenGLやら使えてる
WinだとNT4対応のためにDirectDrawがデフォだが描画時テクスチャの
コピーをメモリからVRAMに自動的に作って高速にブリット、
オフスクリーンイメージが失われたらメインメモリから復旧とか全自動だ
もちろん、VRAMにおいておく優先順位が設定できて自動的にVRAMから
おいだされたりとかわりとすばらしい
- 156 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 23:24:09 ]
- Java3Dでシェーダ使えるんじゃないの？
- 157 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 23:34:47 ]
- なぜゆえこのスレでJavaにこだわるんだ
- 158 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 23:36:08 ]
- 極度に抽象化されているがゆえに知らないうちに使われている
という状況が一番あるからでは？
- 159 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 23:51:55 ]
- JITにGPGPU使わせるよりも、
シェーダをJavaで記述する方向で開発した方がいいだろう。
- 160 名前：デフォルトの名無しさん mailto:sage [2006/02/28(火) 00:07:10 ]
- 5.0で追加されたatomicAPIとかみたあとではもう何が来ても驚かん。
- 161 名前：デフォルトの名無しさん [2006/02/28(火) 12:52:32 ]
- CoreImageもGPGPU？
- 162 名前：デフォルトの名無しさん [2006/03/03(金) 18:51:04 ]
- わけねーだろ
- 163 名前：デフォルトの名無しさん [2006/03/03(金) 22:20:09 ]
- GPGPU = 食べるための研究ネタ + 趣味
- 164 名前：デフォルトの名無しさん [2006/03/04(土) 11:40:46 ]
- でも、かつての「コプロセッサ」みたく、
ベクトル演算用のプロセッサを
メインプロセッサの他に持つのって
たぶん正解の一つだよな。
バスがハイパートランスポートだと最高かな。
- 165 名前：デフォルトの名無しさん mailto:sage [2006/03/04(土) 12:08:02 ]
- >>164
その考え方だといつかはCPUに取り込むのが普通
という結論になっちまうぞ
感覚的には非対称型マルチプロセッサのほうが近いのでは
- 166 名前：デフォルトの名無しさん mailto:sage [2006/03/04(土) 13:44:50 ]
- >>164
＞ベクトル演算用のプロセッサを
＞メインプロセッサの他に持つのって
その目的は何だ？
- 167 名前：・∀・）っ-○●◎- ◆Pu/ODYSSEY mailto:sage [2006/03/04(土) 15:31:49 ]
- 暗号とかゲーム用物理演算のアクセラレーション
- 168 名前：デフォルトの名無しさん mailto:sage [2006/03/04(土) 22:13:25 ]
- それって、CELLじゃん。
- 169 名前：デフォルトの名無しさん mailto:sage [2006/03/04(土) 22:14:53 ]
- >>168
orz
車輪の再発明スレに行ってくるか....
- 170 名前：・∀・）っ-○●◎- ◆Pu/ODYSSEY mailto:sage [2006/03/04(土) 22:26:06 ]
- でもIntelのMany Core構想ってCellにも通じるものがあるよ。
汎用プロセッサだから当分はメインコアのリッチ化は進行するだろうけど。
- 171 名前：デフォルトの名無しさん mailto:sage [2006/03/05(日) 02:02:27 ]
- つーか、ＤＳＰ搭載やらｘｘコントローラ搭載なんてＣＰＵはありふれてるし、それらと今のＧＰＵはちょっと違うだろ。
依存性の無い並列処理がたまたま最近（ちょっと昔？）の頂点処理や画素処理にあるわけだ。
Cell なんかは、あまりＧＰＧＰＵっぽくはない。ＤＳＰを７つとか８つ積んでるようなもんだ。
ゲーム屋には面白いけど、ＧＰＧＰＵらしい並列演算を念頭に置くなら、ヘテロなんてどうでもいい。ＧＰＧＰＵのパワーの源は、同じコンテキストの演算を別パラメータで同時に実行するトコにあるわけだから。
- 172 名前：デフォルトの名無しさん mailto:sage [2006/03/05(日) 12:12:59 ]
- 昔パソコンのCPUが貧弱な時代にはプロセッサボードというのがわりとありまして
拡張スロットにCPUより性能のよい石とメモリがのっておりました。
歴史は繰り返してるだけ
- 173 名前：デフォルトの名無しさん mailto:sage [2006/03/05(日) 13:10:09 ]
- それいうならコプロw
つーかガイシュツ杉
- 174 名前：デフォルトの名無しさん mailto:sage [2006/03/05(日) 13:20:07 ]
- このスレでGPGPU以前にシェーダプログラミングやったことある奴って
２・３人しかいなさそうだな
- 175 名前：デフォルトの名無しさん mailto:sage [2006/03/05(日) 14:42:12 ]
- >>173
コプロだとコプロインターフェース経由でのアクセスという意味だから
外部にあるプロセッサとは別物だろう
そしてGPUはそっちの方式
- 176 名前：デフォルトの名無しさん mailto:sage [2006/03/05(日) 17:50:21 ]
- O・D・P！O・D・P！
- 177 名前：デフォルトの名無しさん mailto:sage [2006/03/05(日) 22:25:24 ]
- 組み替え可能ハードウェアはどうよ
FPGAで組むと、クロックは半分くらいになるらしいけど、
特定用途なら１サイクル当たり倍以上の性能だせるっしょ
- 178 名前：デフォルトの名無しさん mailto:sage [2006/03/05(日) 23:05:11 ]
- 数百MHz〜数GHzクラスのクロックで動かせる一般向けFPGAってあるのか？
- 179 名前：デフォルトの名無しさん mailto:sage [2006/03/05(日) 23:47:43 ]
- 通常300MHzくらいまでだな
ただし、腕による
- 180 名前：デフォルトの名無しさん [2006/03/06(月) 00:54:43 ]
- www.xilinx.co.jp/products/silicon_solutions/fpgas/virtex/virtex4/index.htm
これは５００MHzってなってるね
フリーの高速実装とか出回ればよさげ。
- 181 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 01:18:40 ]
- ハードウェア加速という訳がきらい
- 182 名前：デフォルトの名無しさん mailto:sage [2006/03/12(日) 10:18:08 ]
- ハードウエアブーストってのはどうだ？
- 183 名前：・∀・）っ-○●◎- ◆Pu/ODYSSEY mailto:sage [2006/03/12(日) 19:51:14 ]
- ハードウェアｋｓｋ
- 184 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 02:42:33 ]
- GPGPUって
文字列の計算とかできる。
AAAABBAACCAAAにCは何個含まれているかとか計算できるの？
いまいちどんな計算できるかわからない
- 185 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 19:20:23 ]
- 文字だって、１つ１つは数値でしょ。アスキーコードの
普通に出来るっしょ
- 186 名前：・∀・）っ-○●◎- ◆Pu/ODYSSEY mailto:sage [2006/03/17(金) 22:18:32 ]
- 整数演算性能には期待しないほうがいい気もするんだが・・・
- 187 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 00:11:39 ]
- 期待するとかしないではなくて可能か不可能かしりたい
現状Pentiumの100Mhzぐらいの処理性能でもいいから
可能かどうか知りたい
サンプルとか全然なくて書き方すら解らず困り気味
- 188 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 01:32:06 ]
- 文字コードを実数に変換して処理するとか（ｗ
- 189 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 03:03:19 ]
- 可能かどうかで言ったら、むしろ不可能なことの方が少ないだろう。
ただ184の処理は明らかにGPU向きではない。
というより184は>>131の2行目でも読んでくれ。
- 190 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 03:50:19 ]
- >>184 できるぞ。
例えば複数の文字列を２次元配列にする。これを８ビットパレットの入力画像とする。
パレットの内容は、調べたい文字の番号のパレットだけ 1 で他は 0 とする。
入力画像を
abcdefgh
aaaabbbb
aqswedef
pokuhywd
の 8x4 画像としよう。文字列が４本だ。
出力バッファを 1x4 の画像とする。これを 0 クリアしておく。
で、A を調べたいとする。
入力画像から、左から順に８回パレット参照して、出力バッファに"加算"してゆく。
1 1 1 1 1 1 1 1
1 2 3 4 4 4 4 4
1 1 1 1 1 1 1 1
0 0 0 0 0 0 0 0
８回行うと、出力バッファの内容は一番右になる。左側から、n 回目のフェッチ＆加算だ。
４並列でテーブル引きと加算が行えたわけだ。
テーブルの内容によっては、文字による重み付けも行える。
画像の内容を元にテクスチャフェッチもできるから、関数空間の計算結果を入れておくことで、複雑な関数を扱うこともできる（ピクセル間の線形補間が有効な精度のときに限る）。
事情が許すなら、RGB 別々の値にすれば３つの関数を同時に実行することもできる。
ちなみに縦長でアクセスしたりすると VRAM アドレッシングの問題でピクセルパイプがフル稼働できないから、実装時には工夫するように。
畳み込み演算を並列にやって効果が上がるものは検討の価値がある。
ライフゲームなんかは練習にいい。
ところで俺は 131 なんだが、そのときやってた PS3 のゲームはお蔵入りしたｗｗｗｗｗｗ
今ＤＳやってるｗｗｗｗｗ
おまいらはテクスチャフェッチのレイテンシ隠すのに涙目になってればいいさ、ばーかばーかｗｗｗｗｗｗ
- 191 名前：http://www.vector.co.jp/soft/win95/util/se072729.html mailto:http://msdn2.microsoft.com/ja-jp/library/h2k70f3s.aspx [2006/03/18(土) 22:16:50 ]
- TextSS のWindowsXP(Professional)64bit対応化おながいします
もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？
- 192 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 23:19:37 ]
- >>190
あー
お前特定できちゃいました
- 193 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 02:03:09 ]
- 興味あるのですがどこから入門すればいいのでしょうか
- 194 名前：デフォルトの名無しさん [2006/03/19(日) 09:41:45 ]
- >>190のVRAMアドレッシングの話って、詳しい説明あるとこない？
- 195 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 20:42:58 ]
- >>194
知らん。
しかしピクセルがＶＲＡＭ上で何故ジグザグに配置されているかを理解してれば問題ないんじゃないだろうか。
それ以上は機器固有の話だから、実測するしかない。
- 196 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 23:05:06 ]
- havok fx
ttp://www.shader.jp/xoops/html/modules/wordpress/index.php?p=230
- 197 名前：デフォルトの名無しさん [2006/03/20(月) 01:47:19 ]
- >>195
ジグザグに配置って初めて知ったんだけど、どういうこと？
spin.s2c.ne.jp/stoday03.html
の、ヒルベルト曲線順ラスタライズみたいな話ですか？
|
 |
