360 First Gen Games Single Threaded?

[bapenguin]

According to the Inquirer (http://www.theinquirer.net/?article=27249), all the initial release games on the XBox 360 will be single threaded.

During a talk on multithreaded programming, Microsoft used the three core, two thread per core Xbox360 as an example.

The bombshell was that the first generation of Xbox titles, all of them, are single threaded. Not good.
I'm assuming the Microsoft Spokesperson is referring to first party titles, but this is interesting if it holds true, we could see a larger than normal gap in the quality of titles between the first gen/second gen release. Of course, this was from the Inquirer.

[BigJonno]

"It's a console, who cares?"

"That means that the next batch of 360 games will be even more AWESOME!"

"That's why they're so sucktacular. Sorry, that should be ***ucktacular!"

"Mmmmmm, Mario......."

Right, that's the relevant posts dealt with, who wants dibs on the derail?

:D

[NoName]

This isn't anything unexpected, and as the article mentions the PS3 launch titles are likely to be even worse. Most these games were already in development for the Xbox and just got shifted over to the 360. Then there's the learning curve for developing for the new system. This is why I'm in no rush to get a 360 at launch...

[Tennistoad]

The inquirer is right way more than they are wrong... Plus if pgr3 looks and runs as good as everyone is saying then once they do start multithreading watch out!!!!

/of course once they start multithreading *** will come out with the quantum powered xbox2060p which will only be using one quantum..

[NoName]

Right, that's the relevant posts dealt with, who wants dibs on the derail?

:D
We could always bring up how fitbabits was beat up by a 9 year old girl. (http://www.evilavatar.com/forums/showthread.php?t=6334&page=2&pp=18) That's a derail that never gets old! :D

[Schnoogs]

This is old news...Epic commented on this and the difficulties of coming up with a multithreading architecture. In fact they made it sound like even the best minds in the industry like Tim Sweeney and John Carmack are up against a formidable challange in coming up with multithreaded versions of their game engines.

Could be interesting...this may be a case where the technology is years and years ahead of the software.

In my efforts to write a multithreaded game engine it was very difficult coming up with a game loop that allowed for the concurrent access to the game data by the rendering, physics, and AI engines. Generally speaking the rendering engine is waiting on the physics engine which is waiting on the AI engine to update the game state.

Not an easy challange and we shouldn't be surprised if all these additional CPUs are spent doing nothing but loading level data to spare us those uncomfortable 20 second level load times.

My two cents....

[trip1eX]

Well don't forget the gpu is more important in how a game looks than the cpu. Tho you need a fast cpu to keep the gpu fed.

Anyway I demoed a few 360 games at Wal-mart. They looked like today's pcgames.

[Tennistoad]

In my efforts to write a multithreaded game engine it was very difficult coming up with a game loop that allowed for the concurrent access to the game data by the rendering, physics, and AI engines. Generally speaking the rendering engine is waiting on the physics engine which is waiting on the AI engine to update the game state.

My two cents....


My head just exploded.. It was already hurting after watching Primer last night and now you just finished it...

[Morratut]

This doesn't suprise me at all. Besides this bodes well. If PGR3 is a 1st gen 360 title using only 1 thread then :eek:

It means the games are just gonna get better. :)

[sTubbs]

I thought that this was already known considering that at E3 most major developers were saying that multithreading will not fully take hold for another 2 or 3 years. The problem is that devs are pretty much limiting their options right now if they choose to build an engine from the ground up based on multithreading, as their only real market would be the 360, and the investment is still too big too risk.

[Wonka]

I saw the guys behing COD2 on TV and they claimed that they had used at least a couple cores (one for AI, one for rendering etc). But it seems likely that this was not a very optimal process, and it also seems likely that most other games will not be using all the cores. Multithreading a game is truly a non-trivial task. My heart goes out to the poor bastards who have to mutithread on a PS3. That's going to be tough for them.

[Dracula-X]

This isn't a big deal, really. As was mentioned some titles like PGR3 are doing just fine, and it borders common sense that multithreading is something that will be a while before developers get comfortable with the idea. If they're pulling off stuff this good now, imagine what 360 games will be like 3 or 4 years down the road, should be insane...

[Morrolan]

I don't see why this is a bad thing. In fact, while it was unspoken, didn't everyone pretty much assume this? With everyone complaining that multi-threaded coding is hard, it would seem rather dumb to try to get a multi-threaded game out the door for launch.

While I'm POSITIVE that the games coming out of the end of this generation will look rediculously amazing, I don't think the leap from single to multi-threaded code will be as huge a step as you think, in terms of screenshots. What it will do is allow for amazing amounts of physics and AI, which is awesome. But poly counts, normal maps, advanced lighting, these things won't be all that influenced by this tripling of the processing power. As was said above, that's more (though not totally,) to do with the GPU.

[SynapseLapse]

I can't wait to see some of the fanboy rationalizations on this one.

"The x-box 360 is so amazing is can beat your ps2/pc/gcn/whatever with 1 processor tied behind it's back!"

[AzN.Homeboy]

Yeah, I don't see this as a surprise either. It's too new for developers to use in their first batch of games, which they are probably partly using to get acquainted with the hardware. First-round games never take full advantage of what's available... it's just a fact.

[Roc Ingersol]

A bombshell? wtf.
A bombshell would be relevant to whether the games are good or not.

This isn't even mildly interesting on a technical level.

[Vesper]

Actually, this is false, (in the case of Oblivion). Go check the technical interview with Gavin Carter, link (http://www.elitebastards.com/page.php?pageid=12316%20) Please note the following question/answer:

Elite Bastards: A previous interview mentioned using multi-threading to help speed up area/cell loading for when players move about the game world. Are the devs using multi-threading in other ways to facilitate game performance?

Gavin Carter: The game’s code takes advantage of the multithreaded nature of the Xbox 360 and multithreaded PCs to improve just about every aspect of the game. The primary function is to improve framerates by off-loading some work from the main thread to the other processors. We do a variety of tasks on other threads depending on the situation – be it sound and music, renderer tasks, physics calculations, or anything else that could benefit. Loading also gets spread across hardware threads to aid in load times and provide a more seamless experience for the player.

Once again the Inquirer has shown.....

[Schnoogs]

But poly counts, normal maps, advanced lighting, these things won't be all that influenced by this tripling of the processing power. As was said above, that's more (though not totally,) to do with the GPU.

This is not true...the CPU is in charge of things like Potential Visibility Sets, Hidden Surface Removal, etc. I suppose one could have a thread for traversing the BSP Tree or doing Portal calculations why the other is allowing the AI to update the game state. Then once the AI and physics are done manipulating the non static geometry the list of renderable polygons from the static geometry structure (BSP Tree, Oct Tree, etc) would be done.

Who knows

[bapenguin]

Actually, this is false, (in the case of Oblivion). Go check the technical interview with Gavin Carter, link (http://www.elitebastards.com/page.php?pageid=12316%20) Please note the following question/answer:

Elite Bastards: A previous interview mentioned using multi-threading to help speed up area/cell loading for when players move about the game world. Are the devs using multi-threading in other ways to facilitate game performance?

Gavin Carter: The game’s code takes advantage of the multithreaded nature of the Xbox 360 and multithreaded PCs to improve just about every aspect of the game. The primary function is to improve framerates by off-loading some work from the main thread to the other processors. We do a variety of tasks on other threads depending on the situation – be it sound and music, renderer tasks, physics calculations, or anything else that could benefit. Loading also gets spread across hardware threads to aid in load times and provide a more seamless experience for the player.

Once again the Inquirer has shown.....


Yeah, I'm pretty sure it must be first party titles since it was MS giving the speech.

[Schnoogs]

I can't wait to see some of the fanboy rationalizations on this one.

"The x-box 360 is so amazing is can beat your ps2/pc/gcn/whatever with 1 processor tied behind it's back!"

It can beat it...why? Because a single XBox 360 CPU is vastly more powerfull than the old 700 mhz Pentium 3 processor. Plus the GPU in the 360 is 2 or 3 generations ahead of the Geforce 3 GPU. Plus besides the GPUs increased clock and memory speed it has the ability to support the newest pixel and vertex shaders.

Throw in the fact that it has more memory, etc and you have yourself what would amount to a pretty kick ass PC!

[Mason]

Could be interesting...this may be a case where the technology is years and years ahead of the software.

I disagree with that. Hardware design of a multicore system is easy as cake, not to mention relatively inexpensive. Software design for such a system involves tons of huge problems that people are still doing PhD theses on. Making hardware which no one can provide software for doesn't really qualify as progress in technology.

You're right that it's a bitch of a problem for a generalized engine. Depending on the game genre there are certain amounts of parallelism you can extract, like the physics behavior of non-AI objects being run concurrently with AI, but in the end thread synchronization can have some major overhead that can eat up a lot of the benefits of the parallelism. And not to mention the development and debugging time that's wasted on the parallelism, bringing up game development costs.

In the end, the 360 and the PS3 are both failures, in the sense that they didn't even attempt to address these design issues in their hardware. They literally just dumped in some processors and assumed that game developers would figure out what to do with them in a few years. Developers who are independent enough to be able to speak up for themselves, like Gabe Newell, have had some choice things to say about this. I saw Newell speak at SMU's Guildhall graduation, and he ripped into all the hardware designers for screwing developers this way.

[Schnoogs]

I disagree with that. Hardware design of a multicore system is easy as cake, not to mention relatively inexpensive. Software design for such a system involves tons of huge problems that people are still doing PhD theses on. Making hardware which no one can provide software for doesn't really qualify as progress in technology.

You're right that it's a bitch of a problem for a generalized engine. Depending on the game genre there are certain amounts of parallelism you can extract, like the physics behavior of non-AI objects being run concurrently with AI, but in the end thread synchronization can have some major overhead that can eat up a lot of the benefits of the parallelism. And not to mention the development and debugging time that's wasted on the parallelism, bringing up game development costs.

In the end, the 360 and the PS3 are both failures, in the sense that they didn't even attempt to address these design issues in their hardware. They literally just dumped in some processors and assumed that game developers would figure out what to do with them in a few years. Developers who are independent enough to be able to speak up for themselves, like Gabe Newell, have had some choice things to say about this. I saw Newell speak at SMU's Guildhall graduation, and he ripped into all the hardware designers for screwing developers this way.

Your post prooves my point...

[Mason]

Your post proves my point...

Well it should, as I agreed with everything except the summation that hardware technology has "advanced" itself by simply providing a solution that poorly addresses the real needs of game development.

And of course people can figure out how to use these various hardware implementations. But the problems are that, first, the implementations on PS3, 360, and PC differ enough that I worry about the portability of highly hardware-thread optimized titles. 360/PC ports likely won't be too painful, but any other port is looking kind of grim. Second, in many ways it is a highly objectionable step backwards for hardware design.

As I'm sure we both know, contemporary CPUs have grown more and more in complexity in order to successfully extract parallelism from sequential instructions. This is a big sloppy kiss to developers, since it allows for pretty good performance while keeping the hardware relatively abstracted.

The coming generation of consoles reverses all of that by providing a lot of dirt-simple processors and expecting developers to extract their own parallelism. On a theoretical level you can make that run really really fast, just add programmers and simmer for a couple years. But the entire strategy of having more CPUs that do less work (in a scheduling sense) is to me kind of a cop-out, not a brave step forward.

[DoubleUranium]

Game developers need to stop bitching and suck it up. Multicores are here to stay and if you can't figure out how to use them you better start learning database administration because your peers are going to stretch their brains and figure it out.

[motor]

Well it should, as I agreed with everything except the summation that hardware technology has "advanced" itself by simply providing a solution that poorly addresses the real needs of game development.

And of course people can figure out how to use these various hardware implementations. But the problems are that, first, the implementations on PS3, 360, and PC differ enough that I worry about the portability of highly hardware-thread optimized titles. 360/PC ports likely won't be too painful, but any other port is looking kind of grim. Second, in many ways it is a highly objectionable step backwards for hardware design.

As I'm sure we both know, contemporary CPUs have grown more and more in complexity in order to successfully extract parallelism from sequential instructions. This is a big sloppy kiss to developers, since it allows for pretty good performance while keeping the hardware relatively abstracted.

The coming generation of consoles reverses all of that by providing a lot of dirt-simple processors and expecting developers to extract their own parallelism. On a theoretical level you can make that run really really fast, just add programmers and simmer for a couple years. But the entire strategy of having more CPUs that do less work (in a scheduling sense) is to me kind of a cop-out, not a brave step forward.

Actually, having the compiler do this parallel optimization for the programmers is a major area of research right now in compiler theory. It is a very interesting problem, if I didn't write games for a living it's what I would work on. Making super complex chips is turning out to be a dead-end, yields go down, costs go up and the complexity of the chips has a nasty way of increasing exponentially to get any real improvements. The correct way to beat the problem is to let the thing that knows the most about the code do all that optimization, that would be a programmer today, and a compiler tomorrow. Microsoft is already doing a ton of work on next-generation optimization and it was one of the hottest fields of research (other then military AI :) when I was a grad student.

[fitbabits]

We could always bring up how fitbabits was beat up by a 9 year old girl. (http://www.evilavatar.com/forums/showthread.php?t=6334&page=2&pp=18) That's a derail that never gets old! :D
Bastard! :D

[Schnoogs]

Actually, having the compiler do this parallel optimization for the programmers is a major area of research right now in compiler theory. It is a very interesting problem, if I didn't write games for a living it's what I would work on. Making super complex chips is turning out to be a dead-end, yields go down, costs go up and the complexity of the chips has a nasty way of increasing exponentially to get any real improvements. The correct way to beat the problem is to let the thing that knows the most about the code do all that optimization, that would be a programmer today, and a compiler tomorrow. Microsoft is already doing a ton of work on next-generation optimization and it was one of the hottest fields of research (other then military AI :) when I was a grad student.

Good to know this forum has a wealth of programming knowledge to draw from....good post

[mister_slim]

Actually, this is false, (in the case of Oblivion). Go check the technical interview with Gavin Carter, link (http://www.elitebastards.com/page.php?pageid=12316%20) Please note the following question/answer:

Elite Bastards: A previous interview mentioned using multi-threading to help speed up area/cell loading for when players move about the game world. Are the devs using multi-threading in other ways to facilitate game performance?

Gavin Carter: The game’s code takes advantage of the multithreaded nature of the Xbox 360 and multithreaded PCs to improve just about every aspect of the game. The primary function is to improve framerates by off-loading some work from the main thread to the other processors. We do a variety of tasks on other threads depending on the situation – be it sound and music, renderer tasks, physics calculations, or anything else that could benefit. Loading also gets spread across hardware threads to aid in load times and provide a more seamless experience for the player.

Once again the Inquirer has shown.....
So it's technically multithreaded but not close to true peak performance.

[Schnoogs]

So it's technically multithreaded but not close to true peak performance.

You're right...its "threaded" but who knows how close it is to the ultimate potential of the system. My guess is that it's nowhere near the full potential. I'll let history and common sense back that up...

The next few years are going to be interesting as the various studios devise strategies and come up with uses for all that extra processing power that defy our imaginations.

It may require new genres to appear that create gameplay in a more untraditional manner...less emphasis on graphics and more on AI or some other form of dynamic gameplay.

[Magnanimous Gnome]

Just to clarify:

Inquirer = a videogame news site, ala Evil Avatar, Gamespot, etc. etc. Based out of the UK.

Enquirer = A trashy US tabloid that follows Hollywood's "elite" to make up and/or sensationalize every trivial part of their lives. The Enquirer couldn't give a rat's ass about videogames, especially when it comes to the 360's multithreading abilities. ;)

To sum up:

Inquirer != Enquirer

[Schnoogs]

Just to clarify:

Inquirer = a videogame news site, ala Evil Avatar, Gamespot, etc. etc. Based out of the UK.

Enquirer = A trashy US tabloid that follows Hollywood's "elite" to make up and/or sensationalize every trivial part of their lives. The Enquirer couldn't give a rat's ass about videogames, especially when it comes to the 360's multithreading abilities. ;)

To sum up:

Inquirer != Enquirer

HA! That would be funny if the next time you're at the super market you see a photo of the XBox 360 vacationing on some exotic beach while holding hands with Mario...."XBox 360 seen with Mario on romantic get away...photos inside"

[NoName]

HA! That would be funny if the next time you're at the super market you see a photo of the XBox 360 vacationing on some exotic beach while holding hands with Mario...."XBox 360 seen with Mario on romantic get away...photos inside"
LOL, there's an idea. We can do our own gaming Enquirer here at EA, the E-equirer maybe? It could be fun...

[Mason]

Actually, having the compiler do this parallel optimization for the programmers is a major area of research right now in compiler theory. It is a very interesting problem, if I didn't write games for a living it's what I would work on. Making super complex chips is turning out to be a dead-end, yields go down, costs go up and the complexity of the chips has a nasty way of increasing exponentially to get any real improvements. The correct way to beat the problem is to let the thing that knows the most about the code do all that optimization, that would be a programmer today, and a compiler tomorrow. Microsoft is already doing a ton of work on next-generation optimization and it was one of the hottest fields of research (other then military AI :) when I was a grad student.

I agree entirely that this is the route computing will have to take, but the trick is when do you start? Switching to multicore computing when you have compilers that can extract parallelism on their own is a no-brainer, but last I heard these hadn't made it very far out of academia. It's kind of like saying, "Private transportation is the wave of the future, so we're replacing the railroads with highways. But we haven't perfected that internal combustion engine yet, so for now just make some trains that can run on highways." It won't be a problem if all those new highways make people invent cars really fast, but if that takes a while then you've put an unnecessary technical burden on one side so that the other side can try and be future-proof.

And to be honest it's hard to see such compilers working amazingly well using a traditional cache/memory system and branch-heavy code. Maybe I'm not intuitive enough to see where the "free lunch" is located. And, just off the top of my head, it seems like one would still end up with lots of situations in which you'd have to choose between traditional compiler- and algorithm-level optimizations and maintaining the potential for parallelism. Again, maybe I just lack insight.

Of course there are more to games than just physics, AI, and rendering, and most of the other tasks can benefit a lot from multi-core design. Sound, flexible input from video or audio devices, and streaming resources all make a lot of sense. But until we can pick apart the game loop, parallelism can only go so far.

[Jumpman44]

All I know is that Microsoft needs to send somebody out to these Wal-Marts to make sure their systems are set up properly. I went to mine and was disappointed to see that everything looked terrible on the HD screen. First of all, it was a 4:3 image stretched which made everything look way out of proportion. The Xbox 360 logo on the initial startup screen was shaped like an egg! Secondly, I have a hard time believing that it was connected to send the highest quality signal to the screen. Even in the "blades", the text on the screen looked blurry. I've got a 60-inch HDTV at home, and I know what high-def stuff looks like. This setup wasn't being show off in high-def. This is a shame because it is people's first impression of the system and it looks like total crap. Just some great fodder to feed all the PSfanboys.

[Mason]

You're right...its "threaded" but who knows how close it is to the ultimate potential of the system. My guess is that it's nowhere near the full potential. I'll let history and common sense back that up...

The next few years are going to be interesting as the various studios devise strategies and come up with uses for all that extra processing power that defy our imaginations.

It may require new genres to appear that create gameplay in a more untraditional manner...less emphasis on graphics and more on AI or some other form of dynamic gameplay.

AI will be an interesting one. I could see that working pretty well if you partially decoupled it from the game loop. You'd need things like movement (on a predetermined path) or other interactions (i'm in range now so do the thing I wanted to do) in sequence, but I could see breaking off some of the higher-order thought processes, like pathfinding, complex situation-based decisions, and visibility checks into their own hardware thread. Synchronization would be a trick, but then it always is.

I have no doubt that AI will be the next big thing. Just think about how many game genres are based on the concept of a static enemy that either stands around or moves repetitively/randomly until the player arrives. Those games will feel very different if everything is given more room to think and interact. Lots of potential there.

[Kentor]

Doesn't this subject come up a bit too often here?

[fitbabits]

Doesn't this subject come up a bit too often here?
Which subject?

[Kentor]

The difficulty of parallel programming, why game developers have problems with parallel programming, how x person on the forum would write parallel game code, how game y isn't leveraging platform z, etc.

[Vandenh]

motor is right. I am currently playing around with multi-threaded sollutions and it is not easy.... but that doesn't mean it cannot be done. A lot of very bright people are attacking the problem and I am sure some interesting uses can be found. My idea is that new game types should maybe be attemped that use multi-threaded features as a gameplay feature instead of forcing existing engines into the multi-threaded world, but that is a different story :)

[Kentor]

motor is right. I am currently playing around with multi-threaded sollutions and it is not easy.... but that doesn't mean it cannot be done. A lot of very bright people are attacking the problem and I am sure some interesting uses can be found.How many years do you think people have to learn proper concurrency theory and techniques? Most game developers have never written any amount of parallel code outside maybe a single course during their time at school.

I would not be surprized if no game developer leverages even a single parallel algorithm during the life span of PS3/360. Look at how much trouble most developers are having with just running mostly data independent code concurrently. A lot of the problems game developers are struggling over are classic reader/writer concurrency problems, but the shear weight of old non-thread safe code along with inexperience is bogging most developers down to what amounts to poking at concurrency with tribulation.

Would you trust someone who's had a year of professional C experience to write highly optimized portable code? Probably not. The experience just isn't there and this single year C person will not see a lot of the possible optimizations, or know of existing solutions. Maybe in another year or two they'll be somewhat decent. Give them maybe half a decade and you can call them competent. So why would you expect game developers who have basically never touched concurrent code professionally to be able to leverage parallelism to any great extent within the next couple of years?

[Xerxes]

Ok carmack liked the design and all that jazz of xbox 360... This is for mason about gabe "ripping" into it. Not all dev are griping.

[Mason]

Ok carmack liked the design and all that jazz of xbox 360... This is for mason about gabe "ripping" into it. Not all dev are griping.

Not all devs are independent enough of publisher and platform to have the liberty of griping. And Gabe Newell's speech raised a variety of concerns that seemed specious to me, I'm not citing him as a source of all truth, but then he and the programmers he works with are a damn sight more informed about these issues than you or I.

And did you even read the linked article? Even if they aren't actively complaining, actions speak louder than words.

And Carmack's working on how many XBox 360 titles? Rockets are more fun than video games, and if I could afford it I'd be playing with rockets too.

[Magnanimous Gnome]

HA! That would be funny if the next time you're at the super market you see a photo of the XBox 360 vacationing on some exotic beach while holding hands with Mario...."XBox 360 seen with Mario on romantic get away...photos inside"


Princess Peach and Lara Croft hump like gorilla's on private Moroccan beach!

THESE PICS HAVE TO BE SEEN TO BE BELIEVED!!!

[Achilles]

From everything I know this news isn’t true. It doesn’t help that they don’t have a single quote from anyone to support their argument.

Looks like others have already pointed out the false-ness of this article.

[Xerxes]

And Carmack's working on how many XBox 360 titles? Rockets are more fun than video games, and if I could afford it I'd be playing with rockets too.

He lost so he might be back on games already. How many titles? None but neither is Gabe. But one is showing interest and said that's were he's designing his next engine while game is complaining about how hard it is. I rather listen to the guy plunging in and trying stuff instead of the guy watching others get dirty. Sure it's a messy and confusing world but it's not going to get any less confusing not help solve the problems.

[Achilles]

He lost so he might be back on games already. How many titles? None but neither is Gabe. But one is showing interest and said that's were he's designing his next engine while game is complaining about how hard it is.Carmack is currently working on Wolfenstein for the 360 if I’m not mistaken. So for how many, the answer would be 1… engine.

[Schnoogs]

I could have sworn I read an article where Carmack complimented the 360 so you know he's messing around with one. Scary things happens when Carmack gets to implement his genius...I have faith that guys like Carmack and Sweeney will be able to devise engines that are multithreaded.

[Xerxes]

Thanks Achilles I forgot all about that one...

[Murmillo]

I could have sworn I read an article where Carmack complimented the 360 so you know he's messing around with one. Scary things happens when Carmack gets to implement his genius...I have faith that guys like Carmack and Sweeney will be able to devise engines that are multithreaded.
Don't forget about Cliffy B!!!

[bapenguin]

Just to clarify:

Inquirer = a videogame news site, ala Evil Avatar, Gamespot, etc. etc. Based out of the UK.

Enquirer = A trashy US tabloid that follows Hollywood's "elite" to make up and/or sensationalize every trivial part of their lives. The Enquirer couldn't give a rat's ass about videogames, especially when it comes to the 360's multithreading abilities. ;)

To sum up:

Inquirer != Enquirer

Trust me...I know this...but they really do pull a lot of things out of their assses, especially hardware related.

[TrackZero]

Which subject?

I think he's refering to you getting a beatdown from a 9 year old girl. ;)

[bobbler]

I hate working during the day... by the time I'm able to check these threads people are nearly done with them :/ I haven't read the thread, so I might repeat stuff others have already said...

I do have something to say though, some of you may not believe it. But... I'd be very suirprised if any game shipped with only using one thread/core -- it is nearly trivial to split a game into at least one other thread (granted, you may not gain the most peformance out of it, but you'll gain some, so it would be worth it -- especially if the target platform is well known). Devs have known that the Xbox360 would be multicore for over a year now -- if a dev team can't split that game into multiple threads knowing well in advanced (hell, if it was single core, lets say, and a dev team was told that all of a sudden the system was multicore... they should be able to split the gamethread into at least one other -- probably 2 -- in a week or twos time, fairly easily). Its complete horseshit to say that developers are only single threading their games -- splitting things into multiple threads isn't exactly the hardest thing, its taking full advantage of it while you do it that is (and debugging can be a pain in the ass as well).

In addition, we've already heard from devs that are using multiple threads, and some, like the CoD2 dev team are using all three cores -- so if you don't believe my statements above, you should realize that the statement "from microsoft" is not rooted in any sort of truth, especially since they spoke in absolutes.

Again, either MS is trying to do some weird marketing by saying that, or Inquirer is not very bright and misunderstood (which is highly likely, Inquirer isn't exactly known for their ability to get things right).

Edit: let me correct something before some little ass comes and tries to quote a dev proving me wrong: Multithreading a game is not "difficult", multithreading a single component of a game (like the rendering engine, or physics engine, or ai, or sound) is difficult -- it is not a difficult task to put the render, physics, ai, sound, etc, all in seperate threads if one wanted to and planned ahead a small amount, since the algorithms in each thread would be whole. The super difficult part of multithreading things (the stuff people have gotten PHDs in) is trying to split single algorithms into multiple threads... that type of stuff is nearly silly to even bother with. No game has any excuse for using only one thread, even launch titles -- I don't believe PGR3 is using one thread, not because the game looks too good, but because Bizarre has to have devs with at least some sense of programming abilities and if they thought for a few minutes about it, they should be able to split the game up into a couple different threads and gain some performance without much difficulty.

[Thenetcase]

I don't see how this is a bad thing.

On the other hand, I don't believe the Inquirer. If they said that the Earth was round, 24,900 miles around at the Equator, I still wouldn't believe them until I proved it from another source.

Peace
-TNC-

[BlindSwordsman]

This seem completely bogus to me. Multi threading with multiple cores is not that hard. No developer in their right mind will throw away that much cpu power - especially someone making a first party game. We will be using every thread and core for sure in Too Human.

[Xerxes]

I mean if you can use just one core we are talking about the specs of a high end computer of today. We can say is problematic to do the multithreading but aside from Gabe Newall not many people are bitching. Very few in fact while everyone is biting the bullet. They may have never made games on multithreading but if not this generation, the next so they might as well jump on it why they are still in the game. Who knows, if we can atleast fathom some of these games as next gen maybe in 2 or 3 years when the wave of games come around we are looking at way more advanced stuff. Hopefully console lifespans are longer and we don't get Xbox 720 in 5 years. It's not impossible.

[Zeal]

This seem completely bogus to me. Multi threading with multiple cores is not that hard. No developer in their right mind will throw away that much cpu power - especially someone making a first party game. We will be using every thread and core for sure in Too Human.

Most developers don't even know how to write multi-threaded code.

[bobbler]

Most developers don't even know how to write multi-threaded code.

Most developers wouldn't need more than a weekend to learn how to do it, if they needed to.

Here's an example with pthreads:

Create the main game loop (for everything but rendering) and another function that has an endless loop in it (for rendering). Pthread the rendering function off before you start the main game loop and pass the stuff needed through global vars with mutexes. In the main game loop then you use mutexes to lock/unlock the variable (a struct or whatever you need to pass the data) and pass the data between them -- you could even check to make sure that the data was updated before trying to render, so you don't go and render things twice, etc, etc. Sure, you won't get 100% performance gain, because with mutexes you'll probably stall yourself a few times waiting for it to unlock, but you'll gain more than if you had it on a single core.

That is nearly trivial, even for someone who "doesn't even know how to write multi-threaded code".

[notcivx]

Which subject?

That subject over there.

[fitbabits]

That subject over there.
Oh, right, clear as mud then!

[Thenetcase]

I love it when people who don't know crap about programming try to explain how hard it is to program... or how easy it is.

Multithreading isn't hard, but if the developers were initially designing these games for another platform to begin with, it's entirely possible that they weren't able to convert the whole game to multithreading. I could be wrong, but that's just the way it looks to me.

-TNC-

[RicoSuave77]

First gen titles never utilize the full power of the console, whether they have one CPU or 23. This is nothing new or unexpected.

[Mason]

Most developers wouldn't need more than a weekend to learn how to do it, if they needed to.

Here's an example with pthreads:

Create the main game loop (for everything but rendering) and another function that has an endless loop in it (for rendering). Pthread the rendering function off before you start the main game loop and pass the stuff needed through global vars with mutexes. In the main game loop then you use mutexes to lock/unlock the variable (a struct or whatever you need to pass the data) and pass the data between them -- you could even check to make sure that the data was updated before trying to render, so you don't go and render things twice, etc, etc. Sure, you won't get 100% performance gain, because with mutexes you'll probably stall yourself a few times waiting for it to unlock, but you'll gain more than if you had it on a single core.

That is nearly trivial, even for someone who "doesn't even know how to write multi-threaded code".

Uh...hey dude, we've had parallelism of that level for a few years now. It's called a "GPU", you see it handles rendering on the graphics card, thus making rendering have a trivial impact on the CPU.

Breaking up the game loop through parallelism is what people are focusing on at this point, and no, that isn't trivial.

The point someone made earlier about how very few people could intelligently apply an algorithm across multiple threads should be re-read. Anyone can take multiple independent algorithms and make them parallel, but splitting up a single sequential algorithm without killing the performance benefits through synchronization and synchronized access is not at all simple.

For example, trying to do AI calculations while physics calculations are occurring could be problematic, since you're evaluating lots of conditions which may change in the middle of the calculation. Even with threadsafe data access, one can very easily introduce a ton of subtle race conditions simply because prior branching can't be relied upon. Lots of these would fall under the "eh, so the AI is off by a timestep, doesn't matter" category, but the potential exists for real showstoppers.

Like if a collision on the physics thread changes an object's state. No matter how carefully or often the AI thread checks the object's state, there's always the possibility that the state will change between when it is checked and when the AI thread manipulates the object. The only recourse is to lock all write access to an object when you branch based on its state (on top of the usual write-locking), which adds even more overhead and thread contention, and of course the need for careful coding to avoid deadlock. There are easy coding procedures to avoid these things, but then there are easy coding procedures to avoid most common bugs, yet they still occur.

[bobbler]

Uh...hey dude, we've had parallelism of that level for a few years now. It's called a "GPU", you see it handles rendering on the graphics card, thus making rendering have a trivial impact on the CPU.

Breaking up the game loop through parallelism is what people are focusing on at this point, and no, that isn't trivial.

The point someone made earlier about how very few people could intelligently apply an algorithm across multiple threads should be re-read. Anyone can take multiple independent algorithms and make them parallel, but splitting up a single sequential algorithm without killing the performance benefits through synchronization and synchronized access is not at all simple.

For example, trying to do AI calculations while physics calculations are occurring could be problematic, since you're evaluating lots of conditions which may change in the middle of the calculation. Even with threadsafe data access, one can very easily introduce a ton of subtle race conditions simply because prior branching can't be relied upon. Lots of these would fall under the "eh, so the AI is off by a timestep, doesn't matter" category, but the potential exists for real showstoppers.

Like if a collision on the physics thread changes an object's state. No matter how carefully or often the AI thread checks the object's state, there's always the possibility that the state will change between when it is checked and when the AI thread manipulates the object. The only recourse is to lock all write access to an object when you branch based on its state (on top of the usual write-locking), which adds even more overhead and thread contention, and of course the need for careful coding to avoid deadlock. There are easy coding procedures to avoid these things, but then there are easy coding procedures to avoid most common bugs, yet they still occur.

You can shelve the attempt at trying to teach me. I stand by my remarks that splitting a game into at least 2 threads is a rather trivial task, and would gain some performance (as I said, it wouldn't be a 100% gain because the nature of mutex/semaphores). And maybe you're not familiar with how a game works, but there is still quite a bit of rendering done on the CPU. I'd love to hear from a dev that disagrees with me, the ones I've heard from personally hold the same sentiment I do.

The point you seem to be making a lot through out your post doesn't really disagree with what I said, infact I made the point in one of my posts already. Splitting things into multiple threads that are rather sequential will obviously have some overhead since variables/information/etc has to be shared between them (like physics will need to give information to the renderer, etc). This however is usually not enough to make it perform worse on two cores than it would on one. Just make sure to lock your data whenever you want to read/write and then you're set (about as well off as you can be when multithreading stuff). The overhead is there, yes, but it doesn't nullify the performance gained by taking advantage of extra resources. Taking full advantage of multithreading so that you actually gain a substantial power increase is another story, thats where devs need to get creative.

I've done work on multithreaded stuff before, and the app I'm working on now at work has around 6 threads at any given time (it isn't game related, but it has quite a few endless loops and data needs to be shared quite a bit). I'm no expert, I'll free admit that, but I've come to realize that multithreading stuff isn't inherently difficult like everyone says... it's getting scalable performance out of it that is (doubling the clock speed performance vs adding a second core performance).