Bethesda: We Can't Make Dawnguard Work On the PS3

An anonymous reader sends this quote from Geek.com: "PS3 gamers may now never get access to the content in Skyrim's Dawnguard DLC. That's the news coming out of Bethesda via their forums. Administrator and global community lead Gstaff posted an update on the state of PS3 DLC for the game, and it's not looking great. Gstaff explains that releasing sizeable DLC is a complex issue, and it seems like for the PS3 it might be just a bit too complex. No detail is given as to what the specific problem is, but Bethesda is preparing PS3 gamers for the reality that Dawnguard, and for that matter any other Skyrim DLC, may never reach the platform. I'd like to know what the exact problem is they can't overcome, but I'd also like to know if this is a failing on Bethesda's part or a shortcoming of the PS3 architecture. Maybe Sony should pay Bethesda a visit and see what's going on." In other Skyrim news, a mod for the game that attempted to recreate J.R.R. Tolkien's Middle Earth, has received a Cease & Desist letter from Warner Bros, causing development to stop.

Comments

I've developed for the PS3.

[Anonymous Coward]

It's a strange architecture. Most modern machines are symmetric-multiprocessor (SMP). That means programming is very straightforward - all the processors share the same memory space and each processor can do any work you like, so you just have to worry about the normal threading issues (race conditions, deadlocks, etc.) but it's otherwise just standard multithreaded programming.

The PS3 is not SMP - it has one main processor with 256MB of non-video RAM (a big chunk of which is reserved for the OS) and a lot of smaller coprocessors that have very limited RAM (256K). If you can fit chunks of work nicely into 256K, then the thing screams. If you cannot, then you have to do most of the work on the main processor, in less memory than is available on the Xbox360. In other words, you've gone from 6 hardware threads on the Xbox to 2 on the PS3. The combination of less general-purpose processing power and less usable main memory is a really hard problem to solve.

Now, for a lot of games, the Cell is great. Fighting games, puzzle games, art games, ARPGs, JRPGs, platformers. Any time you can offload individual character animation or rendering to the SPEs, you win. The PS3 can animate and render a whole lot more mobs in a scene than the Xbox360 can. If you have a physics calculation like waves on water or swarm movement that is easily separatable into small chunks, the PS3 is also superior.

But think about an open-world game - especially one with the sort of wide-open spaces and anyone-can-go-anywhere gameplay of Skyrim. We did open-world games and we constantly had trouble because physics and AI could interact over a long distance. We broke the world up into cells and aggressively limited the range of some computations to avoid this problem, but still, a lot had to run on the main processor because once the size of a physics calculation or a pathfind exceeded 256K, you couldn't do it on the SPEs. And believe me, pathfinding data alone in an open-world game is always going to be larger than 256K! AI in modern games is expensive, and we know that Bethesda takes their AI very seriously.

Maintaining a large, persistent world also means keeping track of lots of stuff, and that means memory. On the PC, you have practically unlimited swap and tons of main RAM, so it's not an issue. On consoles you have limited RAM and swap space and fragmentation can kill you if you dead. To be honest, I'm surprised the game runs as well as it does on the Xbox360, but again, you have more memory there and they have the ability to "steal" RAM from graphics if they need it, whereas you can't on the PS3.

So while I wish Bethesda had overcome the technical hurdles and made the game workable on the PS3, I can hardly fault them for coming up short. It's just not a platform well-suited to the type of game Skyrim is.

Re:I've developed for the PS3.

[non0score]

While I can attest the parent poster did actually develop for the PS3, I am sadden by the fact that he/she didn't get a chance to learn the tips&tricks of PS3 SPU programming that will, in all honesty, apply to all sorts of performance optimization work. Now to the parent:

For one, if you're worried about SPU local store memory size, there are tricks to do double/tripple/etc... buffering. There are also libs doing software caching if you're inclined. At the end of the day, you just have to realize that local store latency to main memory isn't all that different from an L2 cache hit on a "normal" CPU - they're both around 500-1000 cycles. Only difference is that for SPUs, it's manual work to DMA it over from main memory and syncing. But really, that's only 4 extra lines of code that you can wrap up into two macros.

But I think the real trouble isn't the hardware architecture, but your project's data layout. If the code accessing data all over the place (e.g. "over long distances"), then you're getting crappy performance anyway. It's not like the CPU has great prefetching (that you can't unwrap and do in the SPU anyway) or any out-of-order execution. So if you're just getting L2 misses all over the place (in your PPU), you're just stalling the CPU for those 500-1000, plain and simple.

If anything, the SPUs make you VERY concious about your data layout. At the end of the day, you're going to get much, much more improvement in speeds via good data layout (as a first step anyway) than, say, doing super-low-level assembly programming. The L2 latency wayyyyy outweighs the 10 cycles you're going to save on your tight inner loop after going to ASM. The real benefit of ASM is if you have all your data laid out in a way that you don't stall, then the throughput really matters.

For reference, people at my workplace have done AI updates on the SPU. They've also done full screen SPU post processing, animation (like you said), physics, etc...and even pathfinding! I'll even take your example. Do you need all 256k? Can you not cull out data on the PPU that you know won't be needed off hand? If you already compartmentalized each cell, then you certainly have enough information to work for a while on one cell. Then you can grab the potential references to each adjacent cell as you path to them and stream them in as you continue working. You can even predict which cells you need ahead of time and prefetch them, and discarding them when it doesn't look like you'd need them as you process more of your current cell. It's not like your A* isn't operating on triangles anymore, so you always have a finite set of triangles that you have to compute through before you can do anything else.

It really is all about the data, man.