• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            牽著老婆滿街逛

            嚴以律己,寬以待人. 三思而后行.
            GMail/GTalk: yanglinbo#google.com;
            MSN/Email: tx7do#yahoo.com.cn;
            QQ: 3 0 3 3 9 6 9 2 0 .

            Game Engine Planning

            Over the past couple of months I have been reading a lot about writing games and engines for multiprocessor machines and it is definately a non-trivial problem! It is complicated even more if you want to make full use of the processors on most home computers (currently single-core), the Xbox360 (Triple-Core with two hardware threads per core) and the PS3 (Cell-Processor)! From what I have been reading there are many ways to get use of multiple processors. The simplest, if you have an already existing codebase is called Synchronous Functional Parallel and looks like this:

            The idea is to take parts that are easily independant and break them off into their own thread. The hard part is to pull the bits out of an existing system and make then run in parallel. It is also unlikely that you are going to find that many things to run at the same time so you would make use of only 1 or 2 of the processors and even then the time for the cycle would be dictated by the longest running process since each process needs to resync each frame so you could, in theory, spend quite a bit of time waiting. The next possible configuration is called Asynchronous Funtional Parallel.

            The down side of this method is that it would require almost a complete rewite if you had an existing engine. We don't so this is not a problem for us! The benefits are that you don't need to sync the threads each frame so each one can run independantly and any time one thread needs to interact with another thread it would just grab the latest state of that thread. This may cause threads to use old information from other threads, but you would only be behind 1 or 2 frames and that shouldn't be noticable. A downside that we would need to be concerned about is the fact that there are a limited number of tasks that you can break your engine into. For example if you look at the picture, there are three. If we had a quad-core processor the fourth core would be completely unutilized! Another way to do threading is to break things up according to the data being processed instead of the tasks that need to be done. This is called Data Parallel.

            As you can see this is a somewhat synchronous approach in that each thread must finish before it enters the rendering stage. That means that again the time that section takes is dictated by the thread that takes the longest. The biggest benefit here is that you can break this up over an arbitrarily large number of processors and have them all fully utilized, a down side is that things can get pretty complex if the objects in your game need to interact. It's not unmanagable, but it's something that will require quite a bit of thought to get right!

            In reading an article about the rewrite of Valve's Source Engine they say that they have decided to use a Hybrid solution but they don't go into the details as to what it looks like. I think that the best hybrid would be to have something that looked like the Asynchronous Functional Parallel and then break each function down into data objects.

            This would allow the function to be sort of a Data Object Manager and it could break them up as it saw fit. Or example in the Physics function it may choose to break the objects into chunks by area so that the objects that are most likely to interact are in the same thread. This would have the synchronous issue where the time to execute would be dictated by the longest execution time, but it would only be in that function and not compuded by each function and so should be less noticable. It also has the benefit that it can be scaled across an arbitarily large number of cores.

            I would really like to get peoples opinion on this last setup as it's the one that I am leaning towards using.

            posted on 2007-01-28 20:37 楊粼波 閱讀(164) 評論(0)  編輯 收藏 引用

            午夜精品久久久久久毛片| 国产 亚洲 欧美 另类 久久| 久久人人爽人人爽人人片AV东京热| 国产精品日韩深夜福利久久| 久久性精品| 国产精品99久久99久久久| 久久精品国产精品亜洲毛片| 久久精品国产99国产精品导航 | 久久精品女人天堂AV麻| 久久免费大片| 成人久久精品一区二区三区| 久久亚洲精品无码观看不卡| 97久久精品无码一区二区天美| 狠狠色伊人久久精品综合网| 无码人妻久久久一区二区三区| 国产成人精品久久亚洲高清不卡| 久久久久精品国产亚洲AV无码| 国产伊人久久| 久久国产精品久久精品国产| 久久久国产精华液| 久久亚洲av无码精品浪潮| 国产精品99久久久久久人| 久久久久久久女国产乱让韩| 久久精品国产国产精品四凭| 狠狠色丁香婷综合久久| 久久久久亚洲国产| 色综合久久天天综线观看| 色综合久久天天综合| 97热久久免费频精品99| 久久综合噜噜激激的五月天| av色综合久久天堂av色综合在| 午夜视频久久久久一区 | 亚洲色欲久久久综合网东京热| 国产午夜福利精品久久| 久久精品国产清高在天天线| 777午夜精品久久av蜜臀| 国产精品久久久久免费a∨| 久久最新免费视频| 亚洲国产成人乱码精品女人久久久不卡| 午夜不卡888久久| 99久久精品免费看国产|