Slashdot Mirror


The Technical Difficulty In Porting a PS3 Game To the PS4

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.'"

4 of 152 comments (clear)

  1. Re:PS3 Optimization: Parallelizing code 7 ways by Animats · · Score: 5, Interesting

    The PS3's Cell processor is, in simplified terms, a general purpose CPU and six special purpose coprocessors.

    The "coprocessors" are decent general-purpose computers. The problem is that they only have 128K of RAM each. They can access main memory, with high latency but good bandwidth, through a DMA mechanism. (There's also a relatively conventional NVidia GPU on the back end, so the GPU part of the job isn't the big difference. This isn't about shaders.)

    That 128K of RAM is too small for a frame. Too small for a level. Too small for any big part of game state. PS3 programming thus consists in turning a problem into some form of streaming process, where data is pumped into Cell processors, processed a bit, and pumped back out. This is a signal processing architecture. It's great for audio. Sucks for everything else.

    The PS3 was a "build it and they will come" architecture. It was cheap to make, but large numbers of smart people spent years trying to figure out how to use the thing properly. (Sony basically gutted their US R&D group to beat on that problem.) In practice, a lot of games did most of their work in the main CPU (a MIPS machine) and the GPU, using the Cell processors only for audio, fire and explosions, particle systems, and other tasks that didn't have a lot of interconnected state.

  2. Re:There's actually some validity to the GP's post by _Shad0w_ · · Score: 5, Insightful

    Alternatively they're really good programmers who got explicitly told "make this run like shit off a shovel and don't worry about portability - this will only ever be on PS3". You can say "but we should really write portable code", but if SMT still tell you to ignore portability then you're left with either doing what you're told or quitting.

    --

    Yeah, I had a sig once; I got bored of it.

  3. Re:So someone didn't follow the practice ... by Anonymous Coward · · Score: 5, Insightful

    Is it a good practice for cases like these? I argue not.

    Let's say that we do create a reference version, then optimize. Since we are intending to push the hardware to its maximum, we have to assume that we will hit the occasional performance wall. How do we deal with that? We change the behavior of the program to fit within the limitations. This means that our definition of correct behavior has changed and the reference version is no longer correct. So, we update our reference version to match the version we plan to publish. This involves backporting the changes, then carefully testing to verify that the behavior is exactly the same as in the optimized version.

    We're left with the question: Why do we call it a reference version if it is derived from the version that is supposedly derived from it?

    The optimized version is the real reference version. The "reference" version is really just a port to a hypothetical platform. And, rather than just porting the final version, we are porting every bit of wasted effort along the way.

    We get all the cost of the PS3 to PS4 port, dragged out over the whole path of development, with no target platform to sell it on. Sure, porting "reference" to PS4 will be cheaper than PS3 to PS4; however, PS3 to reference to PS4 will be much more expensive than directly porting PS3 to PS4.

    So, best case, we spend more money to save time porting to a platform we never intended to support. Worst case, we spend a lot of money on a port that doesn't go anywhere. It's a lose-lose.

  4. Re:PS3 Optimization: Parallelizing code 7 ways by Anonymous Coward · · Score: 5, Funny

    Still too little. 640k would have been enough for everyone.