カレンダー

09 | 2017/10 | 11
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31 - - - -

Eモーション

作品紹介

チェンジジョーカー
爆乳エルフちゃん飼育生活
ラブヴィーナス
マーメイドビーチ
午前0時のスナイパーズ
ダークネス・ヒーローズ
3DOL
湯煙混浴露天風呂の罠
痴漢鉄
いけないバスタイム
お兄ちゃんといっしょ♪
ラブセックスライフ
リアル痴漢タイム

月別アーカイブ

RSSフィード

実験中

-------- -------- --------

■ブログ内全記事

 全ての記事を表示する

アクセス解析です

新・リアルタイム3D【萌え】研究所
■ジャンル : 同人 / デジタルフィギュア / リアルタイム3D / エロ
マルチコアの性能を最大限に引き出す為に~
って言いながら暫く悪戦苦闘していたのですが。無理みたいです。

沢山の作業を1人でやるより、2人で分けてやった方が早く終わります。
単純に考えれば半分の時間で済みます。

ところが実際には、
作業を2人に分ける時間が必要で、作業が終わった分を集める時間も要ります。
2人が同時に終わるとは限らないので、終わった?って聞いて待ってなきゃいけません。
もし作業に必要な資料が一つしか無ければ、2人で交代で見る必要が有ります。
2人の机が凄く離れていたら、資料を借りに行くのに時間が掛かるかもしれません。
もし作業結果を一つの表に纏める必要があれば更に遅くなります。
理論的な理想値は2人で2倍なのですが、現実には1.8倍位が限界で
条件が悪ければ1人でやるより遅くなる事もあります。

60FPSでゲームを動かすには、少なくとも60回は
処理の分割とマッチングを行わなければなりません。
入力の受付や処理の結果を画面に表示する為に60回必要になるからです。
分割が一度で済むバッチ処理的な物であれば速度向上に有効ですが、
コンマ秒単位で処理結果が頻繁に必要で分割回数が多くなるゲームプログラムでは
速度を向上させるのが難しいようです。

ゲームに不向きだと言うのは10年以上前から分かっていた事なのですが、
最近のPCでは速くなるかも知れない!とか新しい高速化の手法があるのかも!?とか
淡い期待を抱いたりしたのですが。私にはハードルが高かった様です。
この記事に対するコメント

ご無沙汰しております。
懐かしのセガサターンにもCPUが二つ入ってたんですよね。
で、某格闘ゲームの開発初期段階では一個のCPUに一体のキャラクターを
制御(?)させて、2対のキャラクターを表示する、というやり方が試されたらしいのですが、すぐに
「ダメだこりゃ!」
となったそうです。
太古の昔からマルチコアってのは扱いに困る奴だったんですね。
【2008/11/29 土】  ヂロー  [URL] [編集]


描画の処理を2つのスレッドで行うのではなくて
メインスレッドから描画の処理自体を切り離して別スレッドにした方が
効率がいいような気がします。
【2008/11/29 土】  とも  [URL] [編集]


ヂローさんこんばんは!
背賀田三四郎(?)と専務のハートビートを一つに同調すれば長引く不況も何言ってるんだ俺は

セガサターンのナンちゃって64ビット級の印象が強いので、苦肉の策の付け刃的なイメージがあるんですよね
クロック数は頭打ちだし、最新ゲームの技術もマルチタスクの分散型処理に移行しつつあるのですから
時代を先取り(?)していたとは思うのですが

ハード的にはマルチコアに移っていくと思いますし、今後ソレを利用する技術も増えていくでしょうが
例えば、物理演算などの今まで出来なかった重たい処理がリアルタイムでも出来る様になる事と、
今までやってたリアルタイム処理が軽くなるのとは微妙にニュアンスが違うと思っています

正直自分には無理っぽいので、寝て待ってたらそのうちリアルタイム3Dでマルチコア対応で
簡単にゲームが作れるツールが出るんじゃないかな~とか・・・




ともさん、お久しぶりです~
ぶっちゃけ描画部分だけを単体で回してみたんですが
それ程スコアが変わらないんですよ
描画部分が一番負荷を食ってる部分なので・・・

入力系やメニュー操作系のフォアグラウンドだけ軽くなっても
肝心のキャラクターがカクカクしてたら余り意味がないので

今回ゲームの仕様も増やしているんで、そこら辺の負荷が減らせればと思って居たのですが
なかなか思うようには行かないみたいです
【2008/11/30 日】  groe  [URL] [編集]


私がテストしたときは三角形の頂点の座標を変更しながら
徐々三角形を小さく描画する簡単なプログラムを
1スレッドと2スレッドのパターンで作りましたが
マルチスレッドの方が三角形が早く小さくなっていました。
ちなみにGPUのシューダーを使ってプログラムしました。

ひょっとすると実行環境やプログラムの負荷によって効果は変わるのかも
しれませんね
【2008/12/07 日】  とも  [URL] [編集]


シェーダーを使用しているのなら尚更、マルチスレッドで早くなったと言うのが
イマイチ私の頭では想像が・・・
CPU側の処理を幾ら並列化しても、GPUや描画処理を担当するグラボが一つである以上
その部分の処理能力を上げるのは理論的に不可能に思えてしまって

しかし世間ではマルチコア対応で早くなって当然的な論調もありますから
何がしかの対策は必要になるとは思うのですが・・・
今の私には実現する手段や技術力は無い事は言うに及ばず、方法さえ想像が付きません

負荷を減らして早くするのは難しいので、方向性を変えて
今と同じ負荷でもっと沢山処理を増やす事を考えています
でもコレをやっちゃうとシングルコアのPCでは動かなく成っちゃうかもしれないので
諸刃の剣なのですが・・・
【2008/12/07 日】  groe  [URL] [編集]


想像ですが、描画処理の負荷が小さいときはGPUのアイドル時間が
多くなるので、マルチスレッドにするとその分、多く描画できるのではないでしょうか。
逆に負荷が大きいときはGPUがCPUの足をひっぱってGPUの描画性能分の処理しか
できないのだと思います。
【2008/12/08 月】  とも  [URL] [編集]


私のPCは、価格とか省スペースとか夏場の冷却とか色々考えてオンボードを選択して
しまったので、最新の3D関係ではやはり描画がネックと成ってしまいます。

製作側としては無闇にスペックを求める必要は無い!っとか、むしろ微妙な方が
ユーザー環境に優しいソフトを作れる!とか考えたのですが、
如何にも世間でトレンドの3Dエロゲが走らない憂い目に・・・

環境による違いは怖いですね。自分の環境で高速化と思ってやった事が、
実行環境が変わると逆効果だったりする可能性もありますし。
出来るだけオプションなどで選択出来る様に作りたいと思っています。

今作ってる作品は、マルチコアを想定していなかったので、余り効率化出来ないばかりか
とりあえず動作させて検証する為にかなり強引に弄った部分もありまして
オプションで切り替えられる様に両立したり、保守性に問題アリアリな状態ですが。
【2008/12/08 月】  groe  [URL] [編集]


この記事に対するコメントの投稿














管理者にだけ表示を許可する


この記事に対するトラックバック
トラックバックURL
→http://emo3d.blog26.fc2.com/tb.php/983-2a321428
この記事にトラックバックする(FC2ブログユーザー)
この記事を編集する
この記事は管理者のみ編集可能です。
編集