First-Gen Xbox 360 Games Single-Threaded?

Scott Gualco wrote to mention a report at The Inquirer indicating that, despite the 360 itself being capable of multi-threading, first generation 360 titles will be single-threaded. From the article: "Every new machine has a nasty first set of games as the programmers work up to speed on the hardware. In this case, the up side is that there is about 6x the CPU power available and coming to a console near you in the second generation of games. The scary part is that everyone tells me that the PS3 is harder to program for than the Xbox360, and the tools are nowhere near the quality of Microsoft's. That means that even with an extra six months of design time, the initial PS3 games may be worse." Commentary available at Joystiq.

Comments

Most video games are single threaded

[AuMatar]

Multi-threading doesn't actually buy you much with video games, not much can be done in parallel. About all you could do with it is run AI on a separate thread. That'd buy you an advantage for strategy games, but not much for anything else (where AI is light). Look at performance testing of games on multicore chips- they don't outperform single cores.

Re:Most video games are single threaded

[Anonymous Coward]

AI, Music, player input, networking, "worldkeeping"... hell, even rendering is parallelizable.

Games are far more threadable than you think.

Re:Most video games are single threaded

[lividdr]

Current games don't run any faster on multiple cores than on single cores because these games are (for the most part) single-threaded. This isn't because they can't be, though - it's because the average home system is just a single core. It's a much more sophisticated problem to develop a threaded application, and the added development and QA expense isn't going to be worth it until there are a lot of multi-cored systems in use.

Most games do have a lot of potential for taking advantage of multiple cores. Take advantage of the extra core to run another thread with a more sophisticated AI in your shooter, add more background NPC scripting to your RPG, or develop an über-realistic physics engine.

As soon as multiple core systems start getting penetration within the consumer market, expect to see games take advantage of it. CPU speeds aren't increasing as fast as they have been in recent years. Software won't be able depend on running faster - it'll have to starting doing more things concurrently.

Re:Most video games are single threaded

[AuMatar]

Threading only makes sense if one of three conditions is true- either it allows you to do complex calculations early, a condition needs rapid handling, or the task is truely massive but can be handled with low communication by multiple threads. Very few things in games follow one of these.

Music has no advantage to multithreading it. You decode it to wav and send it down to the OS to play (yes, there is an OS, even on a console these days). Its not even like the DOS era where you had to set up the DMA to interrupt you at the half buffer point to fill over the used data. Perhaps if the games were generating music this would make a difference, but they aren't- they just play pre-created files and add in a sound effect occassionally. You could uncompress on another thread, but thats not much of a gain, as levels/areas tend to just have 1 song you load upon loading the game/level/area.

Player input is so rare an occurence (remember, we're at machine speeds here) that it doesn't make sense to give it its own thread. We're talking about something that occurs 2-3 times a second, to a GHZ processor. You'd have a thread with nothing to process 99.9% of the time, and who's time to process is extremely low priority (rememver, a long time to a CPU is a fraction of a second).

Networking- maybe. Of course, networking really is just another type of IO, and after already dealing with a network latency, a few more ms to wait won't be noticable. So there's little advantage to it having its own thread. And the actual sending is interrupt driven by the OS, so you don't need a thread to handle writing.

Worldkeeping and AI do make sense for complex AIs. Allowing decision making to occur on the player's turn would increase AI ability, allbeit at a cost in complexity (you'd have to guess at what the players turn would do). Good for turn based strategies like Civ and RTW. Not commonly done, though. Even Civ4 didn't multithread their AI off from the rest, and if there's any game that requires computational power its Civ.

THe other problem is that all of these things are very tightly coupled- rendering, for example, requires input from networking, IO, AI, every time they make a decision. Music needs to know what AI is doing and what the player/network players are doing. Etc. Compare this to a multithreaded server or computer app, where threads basicly just take a request and go off, just telling the main thread when they're done. Games would require a lot more interprocess communication, and that makes multithreading hard. High cost, with very low returns.

Now client server games are another matter- I'm sure MMO servers have multiple threads going. But notice how different that use case is- multiple loosely coupled computations, vs few highly coupled ones. ANd no rendering thread that basicly needs to know everything at all times.

Surely this isn't true

[applecrumble]

What the hell? Not a single XBox 360 programmer can work out how to create new threads and identify at least some processes that are not dependent one each other? That sounds like complete nonsense to me. There are plenty of easy ways to separate your level setup, game logic, sound processing, graphics, AI, physics etc. into different threads. I'm not saying taking full advantage of all cores is easy, but the idea that none of the game developers have the ability to use more than one thread is stupid.

Re:Surely this isn't true

[Reality Master 201]

Threading well is harder than people seem to think. I've seen code written (not for video games, but for business applications) that makes extensive and very inappropriate use of threading such that the performance and scalability of the software is worse than if the programmers had just single threaded everything.

And are there any consoles that support threading now? For that matter, how common is multithreading in PC games? Most gaming machines (PC) have single chips and don't do multiprocessing, so probably people haven't got much experience in writing efficient, performant code for games that uses threading capabilities.

Not to say that threading games is impossible, or even particularly hard, just that when you bring a new technique/capability to a programming realm, it takes time to learn how to exploit it properly.

Re:Surely this isn't true

[Anonymous Coward]

I wouldn't be surprised if it were true; first generation games do not have the luxury of time or access to working, complete, hardware. What you're given is performance estimates which are garbage (with the exception of the Gamecube and Dreamcast in the last generation), 'similar' (ie very different) hardware, and an exec who thinks it is possible to produce a game that is '10 times beter than half life 2 in 18 months (with 10% the budget).'

How do they do it then?

You licence existing technology (Unreal Engine,Doom Engine, etc.) which for the most part have focused on a single threaded environment, and create content that runs at a 'acceptable' rate on the crappy hardware you've been provided (ie. 20-30 FPS) and hope that the real harware will provide better performance.

Re:Surely this isn't true

[radish]

I've said it before and I'll say it again, what is it with the slashdot fear of threading? Otherwise intelligent people seem to consider it (a) amazingly hard (b) brand new and cutting edge (c) only any use if you have multiple cores and (d) not really very useful at all to be honest. All four are false.

Using an appropriate language (for example, Java), and provided you know what you're doing, threading is not hard. One of the apps I am responsible for routinely runs 800+ threads on 16 processor boxes. I'm no rocket scientist, but it works. Threading is also not new, or rare. Taking a look at task manager on the XP box I'm using right now shows over 300 threads running, with some apps taking as many as 50. This is on a single processor box - threading works on a single processor because it allows you, the application programmer, not to have to write your own scheduler (for example, to handle blocking IO without locking up the GUI). The OS is usually better at these things than you.

Re:Surely this isn't true

[Anonymous Coward]

YallaYalla ...

Somehow you have to love the naive understanding that a given software technology can be optimized by throwing more threads at it. That's what all this marketing vodoo about multi-core and hyper-threaded hardware has got us into.

Adapting a single-threaded technology to make use of multi-core, massivly parallel hardware is a daunting task. To be precise, the studio I work at as a gamedev professional just threw 5 years of technology out of the window and started from scratch. Doing realtime concurrent calculations in the context of 3D-applications is a bit different than writing a web application.

And now we're supposed to replace and reimplement >5 years of hard-earned experience and existing code within the normal 18 month development schedule of a normal game title ? gimme a break ...

YallaYalla

Re:Surely this isn't true

[Tim Browse]

Of course it's not true.

In case it's hard to work out, here's an alternative (and, I suspect, wholly correct explanation):

You've had real 360 dev kits for not very long - you've had to limp along with some half-way house that probably emulates many things until then. Your game is a launch title. This means it has a hard deadline. Either you launch when the Xbox launches, or you don't. This is a pretty binary state of affairs.

You're under intense time pressure. Most of the tools you're using are new/revised, and you have to create assets that are a different level of detail/effort than the previous games you've made, so you need to learn a lot of new tricks again. While you're updating the game engine itself, of course. Everything's changing.

Now, do you want to add to this volatile mix a bunch of multi-threading stuff for core game mechanics, with all the new code/mechanisms this will entail, and issues produced by multi-threaded access to game data, sync issues, race conditions, etc. and jeopardise the launch date of the game?

Or do you want to do the best you can in the time you have available?

I know which I'd choose.

(Aside: I see a lot of comments about audio, etc - of course multi-threading for stuff like audio playback is a no-brainer. Trust me, that's not the sort of thing that game devs are talking about when they say multi-threading games is hard. Conversely, multi-threading audio playback is not exactly a huge win anyway. The chipsets on these consoles do all the hard stuff - all the audio playback engine is doing is filling buffers and updating playback parameters. Exactly how long do you think that takes anyway?)

How can it get worse?

[Qzukk]

first generation 360 titles will be single-threaded ... the initial PS3 games may be worse

They'll be half-threaded?

Re:How can it get worse?

[Ayaress]

Sorry to reply seriously to a joke, but my guess is they'll have the same problem as early PS1 and PS2 games. They may have threading issues just like the Xbox360 as well, but I'm still betting on graphics being the one that'll hurt.

Remember the early PS1 games? A lot of them were 2D or mixed 2D/3D (Final Fantasy VII had 2D environments with chunky, lego-man 3D characters, many others had 3D environments with 2D objects in them). It was a good while before good-looking fully 3D games were the norm, and even then, there were 2D games that came out like Valkyrie Profile and various fighters that looked much smoother than simmilar 3D games.

Then the PS2. A lot of the early games looked butt ugly when compared to the recent releases. To look back at GTA3 next to San Andreas on the PS2, it's hard to believe they're on the same system. Do the same with the PC or Xbox, and although there's a difference, it's not nearly as marked.

When the Game Cube and Xbox each came out, they both looked (at least to my taste) a fair bit better than the PS2. Before long, though, the PS2 games were a good match with the other consoles.

With the lackluster screens being shown so far and the quantity of "bullshots," I don't think the PS3 titles will live up to the system's touted graphical power.

Not too surprising

[dividedsky319]

It seems like a lot of the things dealing with the Xbox360 have been rushed... I mean, here it is less than a month before it's released and I still don't think there's a 100% accurate list of games that will be available on the day of release.

This seems like the easiest place to cut corners. If the game will run fine using single threads, there's no incentive to develop a more streamlined game when time is of the essence.

This always seems to happen with systems, though... games coming out later in the system's lifespan look a lot nicer than games early on. As they use the SDK more they'll learn tricks to make things run and look better.

Re:Not too surprising

[xgamer04]

This seems like the easiest place to cut corners.

I guess I thought the place where most 360 (and Xbox) games cut corners, was, you know, gameplay. It's pretty easy to make a game with flashy graphics on hardware like this, and especially since your graphics programmers and artists are jizzing all over the place with their HD textures and such, but it's a lot harder to make a game that's actually good. I'm not saying this stuff won't sell, obviously it will (it's new and shiny, we love that), but the quality (and fun) will probably suffer until at least the 2nd generation of games.

Middleware

[Admiral Ackbar 8]

The middleware they all use probably isn't there yet. Once it is I think you will see more multi-threading.

All I know is that doing it on you own is very challenging and adds so much complexity (race conditions and locking to name a few) that it's probably not worth the effort. Really all these systems need for great graphics is a kick butt graphics card!

Sounds familiar

[nevergleam]

I'm suddenly reminded of that Anandtech article from a couple months back about how developers were:

1) Not enthusiastic about using multiple threads and
2) Very disappointed in both the 360's and the PS3's single-threaded CPU performance.

It was pulled pretty quickly, and the story is that the article was pulled to protect the anonymous source.

SDK tools?

[Red Flayer]

The scary part is that everyone tells me that the PS3 is harder to program for than the Xbox360, and the tools are nowhere near the quality of Microsoft's

I told Sony over and over again that they'd better include an IDE with their SDK... they really dropped the ball on this one.

Not entirely true

[PIPBoy3000]

This has been discussed on Evil Avatar for awhile now. It seems that for Oblivion at least, that statement isn't entirely true

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.

That's not to say that writing software for multiple cores is easy. It's actually extremely hard to synchronize the various tasks that run on the different cores. I suspect that most early games will run slowly on a single core or somewhat inefficiently on multiple cores. It will be quite some time before developers can figure out how to use all of them efficiently enough.

The developer's dream is a single processor console that has a very fast CPU. Unfortunately that's hard to manufacture, so they're stuck with something less than ideal that can be made cheaply with today's technology.

Developers said

[thegamebiz]

Lots of developers said quite a while ago in something I read on either GameSpot or EGM that most, if not all, of the first generation Xbox 360 titles would be single threaded. Using multiple threads is still a new technology and one that many developers are still only beginning to learn. I remember them saying that around the third and fourth generation of games is when you'll begin to see them take advantage of multiple cores.

Re:Developers said

[Kazriko]

Actually, The Playstation 2 actually had 3 threads running inside of the Emotion Engine alone. One on the MIPS main processor, and one each on the two Vector units. There was also a seperately programmed MIPS IO chip on the board as well. Asymmetric multiprocessing is a well known factor in video game development, going all the way back to the arcade machines that first had high end sound (The old arcade games frequently had a Z80 main processor and a 68000 sound chip.)

Symmetric multiprocessing was tried before as well, back on the Sega Saturn. It wasn't nearly as successful.

I've Worked On (almost)Every Console

[Anonymous Coward]

I've worked on almost every console over the past decade or so and worked on every area of game engineering - graphics,AI,physics, and even sound recently.

It is clear to me that Microsoft is in full press damage control right now.

I don't know where the hell this notion that "game developers will need to time to adjust to the scary new world of multithreading" came from. But wherever it did come from it is complete bullshit.

Console game developers have been writing parallel code for a long,long time. Hell, I've been writing multi-threaded game code on my dual G5 for two years now. It took me maybe ten to fifteen minutes the day I got mine to look up how to spanw off a new thread in OS X and throw a huge chunk of code off in its own thread running on the second G5 chip resulting in a huge performance jump.

Not only have we been writing parallel/multi-threaded code, it just isn't an area of game development that is that interesting. My latest console game we spent about a half day moving code around to maximize parallelism. And then we got right back to working on the actual difficult stuff in making a modern console game.

The performance of the 360 has been shockingly underwhelming. The seemingly endless excuses about devkits or only using one core and so on indicate Microsoft knows they have really botched the 360 hardware and software tools. I am glad my company is skippng the 360 like we did with the Dreamcast.

The PS3 is an utter dream machine for game programmers. The hardware and tools kick ass. If you do graphics programming, you NEED to find some way to get your hands on one. I'm not saying break the law to get your hands on one, but I'd understand if you did...

Re:Cutting edge stuff!

[Yocto Yotta]

You should of hyperlinked the word "new" to a site that talks about how long multi-threading has been around. That actually would have done the trick quite well. Your welcome. =)

Re:'everyone' tells you, do they?

[Rayonic]

I wasn't aware that everyone had PS3 development kits.

Don't act silly, he clearly means 'everyone who has a PS3 dev kit'.

You're right that the dev kits are still beta, but you have to realise that the launch titles are being developed right now.

Re:'everyone' tells you, do they?

[oGMo]

How about some actual reporting, the last half of that summary was totally unneccessary.

Seriously. What's with the XBOX-fanboy Sony-hating articles (or moderators, posters)? With "difficulty of development" we have to look at two different, but relavent points:

• The PS2 was hard to code for. Harder, possibly, than any other platform, historically. It also has the largest library of high-quality games. So, being hard to code for doesn't mean much. It's not like the whiny gamers who moan about difficulty of development are actually doing development. Smart developers (which excludes Tim Sweeney) say things like "The PS2 is hard. But look at the cool things we're doing with it."
• Sony is also not stupid or deaf. The PS2 required a lot of low-level programming right on the metal. Why? Because they listened to PS1 developers who said that's what they wanted. They are also aware of the PS2 difficulties out the door (which was later remedied by numerous devkits), so this time they've got numerous different kits.

How's that for some actual (factual) reporting? (Unfortunately, I can't find the link to the chart that shows how many orders of magnitude bigger the PS3 SDK is in terms of support libraries than the PS2/PS1. If someone can find this, please post.)

I've seen the PS3 Instruction Architecture

[BeforeCoffee]

I downloaded the PS3's SPU instruction set pdf from the IBM download page. After reading that doc I thought, "Wow, this instruction set looks FUN!" It kindof reminded me of when I moved from MOS6502 to Intel 8088 - how much more fun it was to bit fiddle with the 8088. I think PS3 games are going to be a lot of fun to write code for - for bit fiddlers and premature optimization freaks. Will it be harder to code PS3 for than the XBOX 360? Unless Sony does something amazing with their SDK, I would say yes. But the rewards will probably be much higher with the PS3. I read something about being able to drop code sequences onto a SPU stream for scheduling execution, I thought that was a nifty idea. There's all these nifty buses on the Cell processor, connecting SPU's, for data sharing. Complicated, but allows for sophisticated designs.

That's funny...

[nobodyman]

The PS3 is an utter dream machine for game programmers. The hardware and tools kick ass.

Ah, I see. Mr... Anonymous, is it? Thanks for the insight. And I guess you would know, since you've developed on every console in existence. Except dreamcast and xbox, and any before the past 10 years.

  That's pretty funny, because there's this programmer out there named John Carmack who kinda disagrees with your views. Although, who the heck is that Carmack guy qnyway anyway? He's only written about a half-dozen 3D game engines from scratch and designs rockets in his spare time. He clearly doesn't have your level of expertise, what with your unknown work on these unspecified games at your unnamed employer.

Re:That's funny...

[pslam]

That's pretty funny, because there's this programmer out there named John Carmack who kinda disagrees with your views. Although, who the heck is that Carmack guy qnyway anyway? He's only written about a half-dozen 3D game engines from scratch and designs rockets in his spare time.

Unlike the other reply, I do disagree with John Carmack. I don't think he really knows what he's talking about in this case. The Xbox 360 is based on multiple (mostly) symmetric general purpose cores, whereas the PS3 is based on having a single general purpose core and multiple DSPs. This is a huge difference!

The DSPs on the PS3 are much, much faster than the PPC core, and your code will run faster even if you just farm a task to a DSP and wait for it to finish (i.e not parallel). They are harder to program than the PPC core, but hey that's what Devkits and proper code design were invented for. Probably the majority of your team doesn't need to know how to program it - they just call the appropriate API function like "BlendSpanLine" or "CopyBuffer" a couple of experts (or Sony) wrote for them.

I think when Carmack commented on the state of parallelism in consoles, he didn't quite grasp how different the approach is on the PS3 and how much better a solution it actually is. Sony and friends correctly identified that (I'll hand-wave here) 90% of processing is taken up in 5% of your code, and that 5% is generally a tiny little loop you can hand optimise and shove on a DSP. I mean, FFS this is exactly what we're doing on PCs using the shader engines on graphics cards! Why complain when the PS3 offers the same thing but more versatile and more parallel?

Brave New Software

[vga_init]

I remember back in the day when games were making the transition from 2D to 3D graphics. At the time, 2D games in fact had much better graphics, but we suffered through the transition because after sufficient development had taken place the 3D would eventually surpass it. In the mean time, we were happy simply because 3D had a special kind of novelty, and it helped open up gameplay to new possibilities.

I'm guessing that this works the same for any new technology. Console game developers are not familiar enough with the new hardware in order to milk it for all that it's worth, and until they can figure out how to do that then there will be that grace period where the older, single-threaded games or what-have-you are going to be more stable and better written. Once they are done catching up. however, the results will be worth the wait (hopefully).

Actually, there is that part of me that really misses beautiful 2D games.

I'm not saying Carmack is wrong...

[cgenman]

...but it isn't like he's spent a lot of time programming PS2 or Game Cube games. He's spent years optimizing PC code. Of course it will seem simpler to him.

Carmack also doesn't sound like he even has a PS3 dev kit. He's making an easy decision based upon the architecture he and his company is most familiar with. It's probably the right decision for him, recognizing that his company farms out console ports. But until a traditionally multiplatform developer speaks up, all judgement should be on hold, lest rampant fanboyism ruin business and artistic decisions.

Being from a PS2 house that has dabbled in other platforms, the PS2 is just fine as a system. It has quirks, but it isn't like people come to work every day dreading touching the thing. All of the systems have their individual irritations. I'm guessing that the next generation will be similar: the systems will be similar enough (revolution controller excepted) that you make your game on whatever platform will ensure the most people experience it. Fanboyism has a place, but it shouldn't be in development decisions.

Thread safty solution

[digital.prion]

Interesting.

I was just think about the same thing this morning which is a programming language designed from the ground up to be multi-threaded.

Here's a few ideas, let's see if we can get some other intelligent folks to join in.

** Contracts
I imagined having "contracts" much like C# has with interfaces. With a threaded "contract" code is checked at compile time instead of having runtime "gotchas".
"Contracts" would prevent any piece of code from spawning a thread and those objects/functions that did spawn threads would have coinciding "contracts" for the object/thread being called.

** Intelligent IDE
In Eclipse (not the best I know) there is a built in refactor. I can do all sorts of stuff like pull out a class, create stubs, infer generic types, convert anonymous to nested class and the like all with an automated process!
Now imagine if the IDE could check a class for it's thread safety-ness(sp) all before compiling. All a programmer would have to do is highlight a section of code and select the TYPE of thread (1 processor/multi thread, Dual processor single thread,etc) and then the IDE would use game theory to adjust the classes members all on the fly! Possible?

Ok that's just two, lol, but the whole emphasis is on:


*Compile time, safety for threads

*IDE on the fly thread contract correcting,regression and basic race condition checking

*Intelligent compiler warnings regarding possible inappropriate thread usage

*Thread Cases(?) - A restricted system of compile time thread safety where various *types* of threads have different access to other threads.. (private, public, protected) similar to classes. Prevents certain objects under this TYPE of thread from calling another TYPE of thread.. basically, more compile time safety

*Thread hierarchy(?) a strict system of enforcing what threads and objects (within a given thread) can call or pass/share data with another thread and object in another thread. Helps the compiler know how to optimize and the programmer find tricky logic errors


Ok that was wordy. Did it help to explain the vision I was having? Does this coincide with trends or ideas you had?

Cheers!