The Technical Difficulty In Porting a PS3 Game To the PS4 152
An anonymous reader writes "The Last of Us was one of the last major projects for the PlayStation 3. The code optimization done by development studio Naughty Dog was a real technical achievement — making graphics look modern and impressive on a 7-year-old piece of hardware. Now, they're in the process of porting it to the much more capable PS4, which will end up being a technical accomplishment in its own right. Creative director Neil Druckmann said, 'Just getting an image onscreen, even an inferior one with the shadows broken, lighting broken and with it crashing every 30 seconds that took a long time. These engineers are some of the best in the industry and they optimized the game so much for the PS3's SPUs specifically. It was optimized on a binary level, but after shifting those things over [to PS4] you have to go back to the high level, make sure the [game] systems are intact, and optimize it again. I can't describe how difficult a task that is. And once it's running well, you're running the [versions] side by side to make sure you didn't screw something up in the process, like physics being slightly off, which throws the game off, or lighting being shifted and all of a sudden it's a drastically different look. That's not 'improved' any more; that's different. We want to stay faithful while being better.'"
PS3 Optimization: Parallelizing code 7 ways (Score:5, Informative)
That's easy! I wouldn't try to run SPE units code on x86 but x86 code on x86. The "optimization" shouldn't have affected the Game or it's portability and that's why it's their own damn fault.
Optimized PS3 code is not what you think it is. Its not taking some general C code and rewriting it a bit to be friendlier to the underlying CPU architecture or rewriting it completely in assembly. The PS3's Cell processor is, in simplified terms, a general purpose CPU and six special purpose coprocessors. So optimization is really figuring out how to pull major pieces of code out of the general purpose and move it to the appropriate specialized coprocessor, and then add the control code necessary to coordinate the two. Or to put it even more simply, optimizing for the PS3's cell processor is really an exercise in parallelizing code 7 ways.
There's actually some validity to the GP's post. (Score:5, Informative)
You realize the PS3's hardware WAS exotic right? That's exactly why it's hard! Write code optimized for multiple SPE units, and see how well you can get it to run on x86.
There's actually some validity to the GP's post.
Ideally, you would write the game portably, knowing that you will need to potentially take it to market on a lot of platforms, if it ends up being a popular title, and so as a result, you'd have a minimal porting set that could just be compiled and run, with additional optimizations on top of that tuned for the platform on which it's going to run.
Although not done a lot recently, the implementation of the original libc had C versions for all the code contained therein, and then had hand optimized assembly versions that would replace the C versions on a specific platform.
The intent was to be able to get it up and running on a new platform fairly quickly by having a small *required* assembly language footprint in the context switch, bootstrap, and CRT0 code, and then optimize the C code to assembly on a platform specific basis once you wer up and running self-hosted on the platform. This also gave you the opportunity to check assembly optimizations in user space first, without breaking everything by trying something that wouldn't work because of some mistake, and ending up with a lot of work to back the changes out (this was back in the RCS/SCCS days, where source code control systems weren't as capable as they are today).
It makes sense to do the same thing for games; minimally, the complaints they had about shaders should have been totally workaroundable, given that Direct X doesn't allow indefinite termination shaders, and requires the code to be fully unrolled compared to, say OpenGL, where there's no guarantee that a shader terminates (one of the reasons a game can crash a Mac or Linux using OpenGL, but can't crash Windows, using the OpenGL compatibility layer -- if it won't unroll, then it's discarded by DirectX).
In any case, it does show that there were at least some corners cut, and just because the host library is similar, you shouldn't expect the hand tuned code to be at all similar, especially going from a Cell architecture PS/3 (essentially, a data flow processor) to Von Neumann architecture on an AMD processor on the PS/4. It's obvious that all the hand tuned pieces would need to be rewritten, just as if you were porting to Windows or XBox or some other platform that wasn't also Cell-based. You'd think if they had planned ahead for ports to other platforms other than the PS/3, that that planning would be directly applicable to geting the code running on the PS/4 as well.
Re:PS3 Optimization: Parallelizing code 7 ways (Score:5, Informative)
"This isn't about shaders."
I'm recalling a story about the production of Uncharted 2, also by Naughty Dog, mentioning that this is definitely about the shaders and other graphical effects.
The game engine is not just general gaming code, pulled apart and optimized, it was written for the specifics of the Cell CPU, and the PS3 architecture, then optimized at a byte level. One of the tricks Naughty Dog learned, was to leverage the 7 active SPE's in the Cell CPU to assist the GPU in rendering the scenes.
They have the SPE's do some of the tasks the ageing GPU can't, as well as physics.
Besides, the GP CPU in the Cell is not an x86 CPU core, it's another relic, a PowerPC core, and not a particularly fast one at that, IIRC its primary job is to manage the 7 SPE's
Re:PS3 Optimization: Parallelizing code 7 ways (Score:3, Informative)
Yeah, sure. But no.
Optimizing code for cell means re-writing the code so it operates on small data, and data is transferred explicitly between the cores.
The SPUs have fast communication between some of them, which means that if you run the wrong kernel on the wrong SPU the whole thing slows down dramatically.
This combined with all the explicit DMA transfers you have to do makes the code extremely architecture specific.
Essentially the only code that can stay "the same" is the code running on the MIPS core, which if they really optimized it is only control which kernel is executed on which SPU.
Re:There's actually some validity to the GP's post (Score:5, Informative)
They could decide between "write this platform-specific program in a suboptimal way so that it's easier to port to another platform" or "heavily optimize for the sole target platform in order to increase market success". I don't think the latter was an invalid choice. If anything, this story illustrates just how bad an idea it was to put a Cell in a game console.
Re:PS3 Optimization: Parallelizing code 7 ways (Score:5, Informative)
Minor correction: Cell's main CPU - called the Power Processing Element [wikipedia.org] - was a PowerPC processor, not MIPS.
Re:So someone didn't follow the practice ... (Score:4, Informative)
Had they followed the practice, they would have a version of the source code that runs correctly (but slowly) that they could optimize for different target platforms.
I expect that when they started, they had no intention of porting to other platforms.
Naughty Dog is Sony these days. They only make games for Sony platforms. So they targeted only the PS3. I'll bet when development started, Sony hadn't finalized PS4 plans.
Now the PS4 is out and desperate for games (go ahead, name a PS4 exclusive), so Sony is having them port it to PS4. And since the game was never intended for anything other than the PS3, they're running into difficulties.
I wouldn't blame the programmers for optimizing for the only platform they were told to target, I'd blame the managers for suddenly springing a new platform on them after the game was done.