|
|
 |
| [Aug 23, 2008, 1:30 pm ET] - Share - Viewing Comments |
Carmack on multi-threading in id Tech 5 on bit-tech.net has some quotes from
the Rage presentation by id Software's John Carmack at the
Intel Developer Forum (IDF) where he
discussed multi-core and multithreading support in the upcoming vehicular action
game. How the game will offload rendering onto one core and game logic to another is
described, as well as descriptions of a number of different threads the game
will run, allowing some functions like AI to operate asynchronously from
tick-based game state processes.
27 Replies. 2 pages. Viewing page 1.
< Prev [ 1 2 ] Next >
| 27. |
Re: No subject |
Aug 28, 2008, 06:28 |
MacD |
|
|
I always wondered about that: AI and physics seem to have a lot of overlap (hell, even rendering gets in there, when doing geometry culling), so I've always wondered why those systems don't operate on one unified underlying datastructure. Wouldn't the ram space savings be usefull, as well as only having the one dataset to have to operate on instead of performing three operations on three different datasets (even if those three datasets are optimised for their relevant operations [pathfinding/AI on simplified geometry])?
|
| 26. |
Re: Rending? |
Aug 25, 2008, 00:34 |
Creston |
|
|
I don't know enough about threading to definitively argue whether it's true or not. It seems false because if the game reserves 100% of your single core processor, your OS is going to crash really really really quickly.
In any case, it could be a lot better. 
Creston
|
| 25. |
Re: Rending? |
Aug 24, 2008, 12:28 |
DrEvil |
|
|
It's not really reserving, it's a byproduct of most games deliberately trying to go as fast as they can(more fps the better?). Often if you have vsync on you should notice the game doesn't chew 100%, since it becomes throttled at your monitors refresh rate. It depends on how the games update loop is set up. If the game update loop is uncapped, it will chew all your CPU in the name of pushing more FPS. Even if the game has a capped update loop it depends on how its capped, as some games will spin in a loop until time to move on to the next frame rather than sleep the thread and give up some CPU to the OS. It's not representative of how multi-threaded games are set up to expect that adding more cores spreads things evenly. We have a long way to go to get to that point.
|
| 24. |
Re: Rending? |
Aug 24, 2008, 07:22 |
Efflixi |
|
|
He speaks the truth. I can launch warcraft 3 and takes 100% of one of my 4 cores just sitting at the menu. It's simply reserving it.
|
| 23. |
Re: Rending? |
Aug 24, 2008, 05:11 |
kyleb |
|
|
I seriously, seriously doubt that that is true, but even if it is, that still makes it worthless for gaming. Because 100% core usage is 100% core usage, whether the game is actually using it or not. It is true, and it doesn't make anything worthless. It just keeps the processors dedicated to the task. Games have been doing that for ages, and many old games will show 100% on a core even on the latest CPUs, but then you can run another fairly CPU intesive task on the same core without slowing down the game at all.
|
| 22. |
Re: No subject |
Aug 24, 2008, 04:06 |
swaaye |
|
|
You can tell that these multicore CPUs are not what the programmers dreamed of having to deal with. Processes just to manage processes, yada yada. Extra inefficiencies galore, validation nightmares, etc.
|
| 21. |
Re: Rending? |
Aug 24, 2008, 01:55 |
Creston |
|
|
A lot of games will use 100% of a core or more just keep the processors reserved for the applcation, not really making use of them.
I seriously, seriously doubt that that is true, but even if it is, that still makes it worthless for gaming. Because 100% core usage is 100% core usage, whether the game is actually using it or not.
Creston
|
| 20. |
Re: Rending? |
Aug 24, 2008, 01:03 |
kyleb |
|
|
And do you really think the PS3 version is only going to use 3 cores, too? 3? The PS3 only has one core. 
True, but that's assuming that Core 1 is always precisely 100% loaded and nothing more. A lot of games will use 100% of a core or more just keep the processors reserved for the applcation, not really making use of them.
|
| 19. |
Re: Rending? |
Aug 24, 2008, 00:20 |
Creston |
|
|
That's not a poor threading implementation per-se, it's just there may not always be something for that thread to do. If you have a thread for sound, and you're in a quiet place, well it's not going to be doing much.
True, but that's assuming that Core 1 is always precisely 100% loaded and nothing more. Most of the time, Core 1 is 100% loaded and there's still 10 or 20% (numbers pulled out of my ass as an example) that's trying to go on core 1, so your game is slowing down anyways. Even though core 2 has 80% CPU cycles to spare.
Ideally, both cores would run at 60-70% and have room to spare when shit goes crazy in your game. (and, obviously, if you have four cores, they'd run at 30-35%.)
Creston
|
| 18. |
Re: No subject |
Aug 23, 2008, 23:46 |
DrEvil |
|
|
XBox 360 has 3 cores running 2 hardware threads each. That's 6 threads. That could easily take advantage of quad core in the ideal world where the port was that clean and direct, which isn't always the case.
In our products at work(360,PS3 games) that typically involves the game thread, a rendering thread, 1-3 physics threads, 1-3 animation update threads if the game has expensive animation requirements, a misc thread which is sort of a mishmash of systems that are not expensive enough to require an entire thread(networking, sound, might even also chew through some asynchronous collision queries or help with some other physics or animation work). Generally it's pretty difficult to thread AI, because it accesses so many other systems it often can't easily be run parallel to physics update(AI generally does a lot of collision queries). Further, often AI has a small set of expensive tasks that can more easily be offloaded to another thread than the entire AI. Pathfinding in a seperate thread, asynchronous raycasts/shape casts, the cover finder I did for Mercenaries 2 is run on a different thread. In my experience it's easier to do that than to attempt to put the AI on its own thread or something. AI access a lot of world data, and physics data, so it's difficult to do it in parallel to those systems, unless you double buffer or can stagger some systems so that they don't run at the same time. Not impossible, just tricky, and often not worth it if you can make simpler decisions about what to move to a different thread.
|
| 16. |
No subject |
Aug 23, 2008, 23:15 |
beigemore |
|
|
Um.. I'm fairly certain Quake 3 never supported multiple cores. Try playing it on anything with two or more cores and watch it randomly stutter unless you force it to one core.
|
| 15. |
Re: No subject |
Aug 23, 2008, 22:00 |
Aero |
|
|
Bah you already can do it, it's just that programmers in general don't know how to think multithreaded from the start. It's mostly "get the thing running as fast as possible serially". As soon as you start thinking "The AI is its own unique brain that we query when we need something, and that figures out on its own what to think about next", things fall into place.
Unfortunately, it isn't nearly that simple. Just creating a bunch of threads assigned to different sub-systems won't get you very far. If you have an AI loop running on one cpu, and its not being queried, you're just wasting resources, so clearly it can't just be running all the time. Also, what happens when the AI thread needs data from another thread in order to do its thing? Or when another thread needs data from the AI thread? One is going to stall while waiting for the other, and that's no good at all. What happens if they both need to work on and from the same bit of memory at once?
You end up wasting a lot of time because everything is interdependent and the whole thing can stall waiting on one thread, and then we have all but one of the processors effectively doing nothing while one of them crunches some data another needs to do something which yet another needs, and so on.
The difficulty is making sure each processor is doing something useful all the time.
This is something that is ridiculously hard to just do by hand, so we need compilers to do it for us. And they will, hopefully, some day soon. A lot of very smart people are still trying to figure it out.
( No I'm not an expert, I just know what I don't know. )
|
| 14. |
Re: Rending? |
Aug 23, 2008, 21:11 |
Jerykk |
|
|
What evidence we have so far, namely the Doom3 engine, and the various permutations of it, suggests that Rage will be highly parallel regardless of what the "lead platform" (as if that is even an issue here) is. Maybe. Guess we'll just have to wait and see the benchmarks.
|
| 13. |
Re: Rending? |
Aug 23, 2008, 21:07 |
sponge |
|
|
The engine is not a port of a 360 game though. It has been designed for each platform to take advantage of that platforms advantages....or so they say. Kind of. The main strength is that the texture virtualization allows the engine to scale up or down to the hardware running on it. Instead of having to worry about managing textures for PC, Mac, Linux, 360, and PS3, you can use the same assets on all of them, and the engine will sap up whatever memory it's able to. Instead of having a technical limitation, you only have a storage limitation.
|
|
 |
|
|
|
|
|
|
|
|
I am free of all prejudice. I hate everyone equally.
- W. C. Fields |
| 11. |
Re: Rending? |
Aug 23, 2008, 21:00 |
sponge |
|
|
Tell me, how many 360 ports take full advantage of a quad core CPU? I never made any mention of threads. I simply stated that a game designed for the 360 is unlikely to take full advantage of a quad core CPU. You can't really have "multi-core support" (which is a poor term to use in general) without having several threads. Hyperthreading, SMP, and multiple-core processors are all supported by virtue of using threads. In this case, threads and multi-core support are the same thing.
For recent example, ET:QW uses 6 or 7 different threads for all the various subsystems, which means the game could take up to a 6 core processor. That doesn't mean it'll use them fully though. You'll have a separate thread for input, which is not going to tax a whole 2.8GHz core. A recent patch added a threaded renderer on top of that, splitting up the workload more. The more parallel things can be run, the better off you are no matter what platform you're on.
Threads can even be useful on a defined platform because as threads are created and destroyed, the full load can be balanced better. You can remain pretty confident that the ET:QW console ports don't combine threads in order to fit on the 360's 3, because they don't have to do that in order for it to run.
A game designed for a console has zero correlation with how many threads it may use internally. Multi-threading is non-trivial to do well no matter where you are. The fact that the Source engine still is in this day a single-threaded engine (probably owing somewhat to it's Quake 1 roots as was discovered a few years back) is evidence for that.
What evidence we have so far, namely the Doom3 engine, and the various permutations of it, suggests that Rage will be highly parallel regardless of what the "lead platform" (as if that is even an issue here) is.
This message was edited at Aug 23, 21:03. |
| 10. |
Re: Rending? |
Aug 23, 2008, 19:59 |
Jerykk |
|
|
Are you just trolling now, or are you really just not that technically inclined? Do you honestly believe that every XBox 360 game ever made or ported to the PC only uses 3 and exactly 3 threads total? You do realize that threads existed long before even SMP processors did and have little correlation to cores, right? And do you really think the PS3 version is only going to use 3 cores, too? I guess I'm just not that technically inclined. Tell me, how many 360 ports take full advantage of a quad core CPU? I never made any mention of threads. I simply stated that a game designed for the 360 is unlikely to take full advantage of a quad core CPU. There is one 360 port I know of that has and that was Lost Planet. Aside from that, I can't think of any other examples.
|
| 9. |
Re: Rending? |
Aug 23, 2008, 19:32 |
sponge |
|
|
There are games that use multi-core processors, but still do so inefficiently. (they will use 100% of core 1 and 20% of core 2, for example). That's not a poor threading implementation per-se, it's just there may not always be something for that thread to do. If you have a thread for sound, and you're in a quiet place, well it's not going to be doing much.
Rage is being designed for the 360 so I don't think it'll take full advantage of quad core CPUs. Are you just trolling now, or are you really just not that technically inclined? Do you honestly believe that every XBox 360 game ever made or ported to the PC only uses 3 and exactly 3 threads total? You do realize that threads existed long before even SMP processors did and have little correlation to cores, right? And do you really think the PS3 version is only going to use 3 cores, too?
|
| 8. |
Re: No subject |
Aug 23, 2008, 18:16 |
wonkawonka |
|
|
Probably multi-CPU support won't really come into its own until development tools have reached the point where programmers can implement efficient multi-processor programs without having to get into the nitty-gritty. Bah you already can do it, it's just that programmers in general don't know how to think multithreaded from the start. It's mostly "get the thing running as fast as possible serially". As soon as you start thinking "The AI is its own unique brain that we query when we need something, and that figures out on its own what to think about next", things fall into place.
|
27 Replies. 2 pages. Viewing page 1.
< Prev [ 1 2 ] Next >
|
News script copyright © 1999-2009 James "furn" Furness & Blue's News.
