- 1 名前：仕様書無しさん mailto:sage [2006/09/21(木) 19:41:41 ]
- 27スレ目から、
フリーソフトとシェアウェアでスレを分離しました。
前スレ
フリー、シェア作者のぐち 26
pc8.2ch.net/test/read.cgi/prog/1153186762/
- 977 名前：973 mailto:sage [2008/03/22(土) 01:01:27 ]
- >>976
そこは理解してる。
そうじゃなくて人間が見えないくらいの速度で画面更新するソフトに対して、描画を何割か端折るって事なんだが…。
「キャッシュするなどで」「過剰描画を抑制」するわけだから。
それ以前に、単純に描画API呼び出しだけ別スレッドに流し込むって手法だけでも、描画結果待ちのブロッキングは解消されると思うけど。
モデルとしては「描画スレッド」「内部処理スレッド」に分割するイメージで。
書き忘れたが>>973ではAPIフックする高速化全般について考えてたからマルチコア関係ないチューニングも混ざってる。
混乱させてすまん。
以下話の行き違いがあったどうでも良い話題。
BitBltとかは上手くアクセラレーションが効けばビデオメモリ→ビデオメモリにはなるらしいから、システムメモリと競合はしないケースも有る。
メインメモリがコアごとに独立して無い以上、メモリ他IOが多い処理同士は並列化しても衝突する…が、逆に言えば「CPUキャッシュに収まる処理」とそれ以外(「ビデオメモリ⇔システムメモリな処理」とか)の組み合わせであれば問題無い。
筈。
- 978 名前：仕様書無しさん mailto:sage [2008/03/22(土) 09:36:49 ]
- Su
- 979 名前：仕様書無しさん mailto:sage [2008/03/22(土) 09:58:35 ]
- >>977
＞モデルとしては「描画スレッド」「内部処理スレッド」に分割するイメージで。
このモデルの概念なら「メインスレッド」と「作業スレッド」と言うことで
マルチスレッド機能が搭載されたwin95の時に既に確立していた。
最近はSMP以前に書かれたコードがマルチコアが当り前になってタイミング的な
バグが顕在化してるようだけど。
ともあれ>>971の具体的な案を聞きたいと言うのには共感。
- 980 名前：仕様書無しさん mailto:sage [2008/03/22(土) 13:54:39 ]
- そこをバラしてしまったら何食わぬ顔でパクるやつがいるからなあ。
実際マルチコアで様々高速化のプログラミングしていれば、
どういった事が高速化可能かがわかるよ。
ちなみに、DirectXやOpenGLなどはマルチスレッドレンダリングという方法で
コマンドを効率よく送り込むことでパフォーマンスを上げることができる。
色々なゲームで既に行われている。
- 981 名前：仕様書無しさん mailto:sage [2008/03/22(土) 14:44:47 ]
- ↑ケチだな、もうチキッと詳しく。
アイディアくらいは良いだろう♪
とりあえず次スレも立てた。
pc11.2ch.net/test/read.cgi/prog/1206164024/
- 982 名前：仕様書無しさん mailto:sage [2008/03/23(日) 12:00:18 ]
- >>979 >win95の時に既に確立していた。
確立してる割には実践して無い例も多いのが嫌なところだ。
自動でマルチコア向けに最適化しなおすってのは相当面白そうだが…
>>980
楽にパクれる簡単な方法ならばらそうがばらすまいが結局パクられるかと。
この手の最適化はやたらと面倒な手順でやらないと出来ないと思うが(100%解析しきる事は無理なんで)、
そうするとよりベターな結果を出せるエンジンを目指して同種のソフトで削りあいになるだろうさ。
- 983 名前：仕様書無しさん mailto:sage [2008/03/23(日) 13:06:28 ]
- 同種のソフトに対してイヤガラセしてんだろ？ おまえらｷﾓｯ
|
 |
