A question about tri-core game programming......
- Thread starter mistwalk
- Start date
mistwalk said:
That's one possible arrangement.
One of the reasons I heard MS choose a triple core is cause it's fairly easy to come up with 3 big chunks of relatively independent code to lift into seperate threads on current game engines, so you can at least start taking advantage of the two other cores without too much huge effort.
The load balancing in that arrangement would be nonexistant outside of level design. You'd end up having to make sure physics never needed more than one core and the same for graphics. It's certainly possible, but not very forgiving. The demand might not fit that ratio, or one of the cores may be quite underused.
Ideally, you could run the things not easily parallelizable on one core and group the parallel things into jobs and have threads on the other cores pick them off the queue. That way, when the demand of each subsystem varies over time, the CPU is more adequately leveraged.
Ideally, you could run the things not easily parallelizable on one core and group the parallel things into jobs and have threads on the other cores pick them off the queue. That way, when the demand of each subsystem varies over time, the CPU is more adequately leveraged.
Wow..its going to be real cool to see what devs are going to do with their game setups. It looks to be much harder to leverege 3-Cores, it seems as though in this generation your going to really have to plan ahead
(as far as resources go) as to what will be utilized. Is it really as hard as most people make it out to be? (Making sure that everything is running fine and try to make it so nothing is underutilised).
(as far as resources go) as to what will be utilized. Is it really as hard as most people make it out to be? (Making sure that everything is running fine and try to make it so nothing is underutilised).
Inane_Dork said:
In the end the choice is up to the dev, and because the cores are symmetric, you can set them up however you want, and use whatever load balancing mechanism you feel like.
If the dev decides other stuff is higher priority than optimizing the load balancing due to time and budget, then it's a perfectly valid choice to just chop the game into three threads and let that be that. That allows them to at least take partial advantage of more than one core, which is better than just running everything on one.
I will nod in vigourous agreement if the 3 cores didn't share the L2. But - I have never worked with such a thing before, and am *only guessing* the possibility of L2 thrash and contention if running 'too-different' threads with widely different memory access patterns/frequencies/(what-you-call-it).mistwalk said:
At the very worst, one CPU runs main application loop and logic, the other 2 handles fine-grained parallelism. Coarse-grained if memory access for specific thread instances are L2-friendly.
Riddlewire
Regular
I'm glad somebody started this thread. There's something I've been wondering about game architecture on multicore designs, but I always thought it was too stupid a question.
All the talk I've heard about programming for Xenon has focused on breaking up the calculation tasks from the point of view of a single game engine. Since that's an incomprehensible way to say it, I'll try to clarify. It seems that developers want to find out how to take engine architectures designed for single threaded processors and spread their 'needs' over multiple cpu cores (and threads). That sounds logical and I'm sure it's the main intent with multicore CPU designs. But might there be another way to approach the problem? Would it be possible to design your game like a... uh.. MMORPG-on-a-chip, but as a single player world? For instance, one core runs what would be a typical game engine for the player, managing all physics, sounds, interaction, etc. that the player is responsible for, but a second core does the same thing for the rest of the world, essentially acting as a world simulator independent of the player. This second core could obviously ignore any graphics related calculations and any sound processing that occurred outside of the presence of the player (unless said sounds were part of the gameplay component, e.g., one NPC attempting to approach another by stealth). A lot of new and upcoming games are attempting to create persistent but changing worlds in single player (This was the original idea behind Fable) and it seems to me that this would be a good way to do that. Sort of like having both the client and server in the same CPU, albeit with a different balance. And it's a design that programmers already have some experience with, though not exactly.
If this is an unfeasible or idiotic idea, then forget I said anything.
All the talk I've heard about programming for Xenon has focused on breaking up the calculation tasks from the point of view of a single game engine. Since that's an incomprehensible way to say it, I'll try to clarify. It seems that developers want to find out how to take engine architectures designed for single threaded processors and spread their 'needs' over multiple cpu cores (and threads). That sounds logical and I'm sure it's the main intent with multicore CPU designs. But might there be another way to approach the problem? Would it be possible to design your game like a... uh.. MMORPG-on-a-chip, but as a single player world? For instance, one core runs what would be a typical game engine for the player, managing all physics, sounds, interaction, etc. that the player is responsible for, but a second core does the same thing for the rest of the world, essentially acting as a world simulator independent of the player. This second core could obviously ignore any graphics related calculations and any sound processing that occurred outside of the presence of the player (unless said sounds were part of the gameplay component, e.g., one NPC attempting to approach another by stealth). A lot of new and upcoming games are attempting to create persistent but changing worlds in single player (This was the original idea behind Fable) and it seems to me that this would be a good way to do that. Sort of like having both the client and server in the same CPU, albeit with a different balance. And it's a design that programmers already have some experience with, though not exactly.
If this is an unfeasible or idiotic idea, then forget I said anything.
Riddlewire said:
that is a really cool idea and I could have sworn that I have read an MS guy describe something similar as to how the cores could be used.
who knows, maybe it is possible to do it that way?
Sounds like it would be easier and productive but I know nothing of programming.
So, basically, what I already said: "It's certainly possible, but not very forgiving."aaaaa00 said:
blakjedi said:
The developer can use as many or as few threads as he wants, but you need a minimum of three if you want something to be using every core. (Not saying your utilization will necessarily be good in this case, but it's up to the developer to decide what is good enough.)
Here's a question : will 6 threads be beneficial?
As I understand it, the double hardware threads is while one thread is sat idle, the CPU can work on another. But as the cores are in-order and devs are told to be careful how they manage cache, so we should see less cache misses and latencies (?), won't there be less thread idling? Will six threads working on that cache not cause more slowdown due to lack of available data than three threads? Or will the second thread per core be rigged to use data already available on the cache? Or will the second thread operate fairly transparently and effectively?
As I understand it, the double hardware threads is while one thread is sat idle, the CPU can work on another. But as the cores are in-order and devs are told to be careful how they manage cache, so we should see less cache misses and latencies (?), won't there be less thread idling? Will six threads working on that cache not cause more slowdown due to lack of available data than three threads? Or will the second thread per core be rigged to use data already available on the cache? Or will the second thread operate fairly transparently and effectively?
But that is a desktop environment, which does that have the realtime requirements of a game application - i.e. 'complete all the work that is needed to produce one frame in 1/30 second'. I mean, we can launch a few hundred processes/threads on our PC, the OS manages them happily, but the system slows down.
Your question is in the same boat as the comment I posted. My answer is the same. If this problem does materialize, resort to fine-grained parallelism, or only thread L2-friendly loops. Yes this does not sound ideal. There are good reasons why in all traditional SMP boxes, each CPU has an L2 of its own. By using a shared L2, a lot of complexity necessary for syncing L2 has been removed and makes the 3 cores simpler and cheaper. But you lose all the positives of a 'L2 of my own'. You gain some, you lose some. Nothing's perfect.
ShootMyMonkey
Veteran
This is kind of a problematic arrangement. Not impossible, but problematic in several ways. You can't separate Gameplay and AI from physics and graphics because they're linearly dependent. AI, for example, needs to know the state of the world (where everything is, what it's doing -- physics is kind of a small part of that, wouldn't you say?). You could theoretically do physics for the next frame while doing AI for the current one -- just need to watch out if you do that, though because the cache is so small for 3 CPUs to share and you have to be able to store backup world states.mistwalk said:
Similarly, both gameplay and AI include things like putting characters (whether player or NPC) into certain states, deciding animations, conditions, etc. That includes that the graphical calculations depend on to get things like which animations to skin to, where the camera will be, what objects ought to be rendered. You can, to a limited extent, be done with a certain character and do something like software skinning on it while the gameplay/AI code moves on to other characters.
Sound in the arena of music or ambient sounds alone is fairly independent of other things except for when the audio tracks need to change dynamically -- and really having a single frame of lag for that sort of thing may not be entirely noticeable. Sound effects are another matter, of course.
scooby_dooby
Legend
passby said:
i thought each core could partition some of the cache and use it exclusively.
