Is PS3 hard to develop for, because of CELL or ...

Discussion in 'Console Industry' started by gongo, Jan 9, 2010.

  1. Carl B

    Carl B Friends call me xbd
    Moderator Legend

    Joined:
    Feb 20, 2005
    Messages:
    6,266
    Likes Received:
    63
    I wouldn't overthink Sweeney's comments anyway - they are *literally* yesterdays news. Programming for Cell now (or more accurately, development) is of course much easier just due to the greatly expanded and mature set of tools available. I also don't think the data > code aspect is at all retrograde; it's more like, back to the future.

    That said of course, when you read the various threads on game costs and work hours at these dev houses, the obvious resentment towards Cell in the early days is easy enough to understand, since you had the majority of younger game developers completely sideswiped by the architectural shift.
     
  2. assen

    Veteran

    Joined:
    May 21, 2003
    Messages:
    1,377
    Likes Received:
    19
    Location:
    Skirts of Vitosha
    So what tool, which has been proven in shipping title, is there to take a modest subsystem, e.g. 3000-5000 lines of code, accessing randomly a modest amount of memory, e.g. data structures of about 2 MB, and turn it into production-quality SPU code and the associated LS/DMA management?

    Sure, the profilers and debuggers have gotten better since the initial "horrible tools" phase, but the core difficulty of moving code to an array of SPUs without access to shared RAM is still there, and there's no replacement for the old-fashioned blood, sweat and tears involved.
     
  3. T.B.

    Newcomer

    Joined:
    Mar 11, 2008
    Messages:
    156
    Likes Received:
    0
    Software cache?
    Seriously, fetching a cacheline through DMA is about the same costs as an L2 miss. I think there are even implementations available on DevNet.
    Some teams even code their PPU stuff so that it works on buffers, allowing them to move the code between PPU and SPU by replacing memcpys with DMAs.

    But I think the issue is one of perception (And sorry Assen for singeling you out like that, but I think it's a common one). You cannot expect to take a piece of code with less than ideal performance characteristics and have it turned into high-performance SPU code automagically.
    But then again, do you really need to? The SPUs are fast, and they are many. So even if your less-than-ideal-for-PPU code ends up being less-than-ideal-for-SPU code, so what? It's off your PPU and you were probably no using that SPU anyway.
    Now if you really want optimized code, then optimizing on the SPU is a lot easier than on the PPU. Actually, with the tools at hand, it's hilarious how easy it is to get close to peak performance. Heck, I have performance critical assembly code that literally utilizes the SPE at 100%. And I'm not some sort of superhuman assembly ninja.

    From my own experience, the main issue is to actually get started with SPU development. It will take you a month or two to get all the concepts in your head and to be comfortable with the ideas involved. When you're neck deep in development, no senior programmer has that much free time, so the SPUs stay unexplored. This is actually a serious problem, because if someone on the team thinks "Hey, maybe this could go onto an SPU!", there will be no local expert to help him set it up. So the barrier of entry remains. (*)
    (As I understand it, that's the reasoning behind Insomniac's SPU Shader approach.)

    Once you actually do work with the SPUs, and once you actually do have the "Data first!" mindset, it's not that hard. Certainly not 5x harder than single-threaded. It isn't really harder than writing good multi-threaded code, in my experiece.


    Absolutely true. If you are as drowned in work as most people are, then re-engineering an existing system is hard to justify. But maybe you don't need to, and hopfully the next design will be better for manycore.

    Personally, I postponed all SPU work for basically a year on Sacred2, simply because I had no time at all to even think about it. Then my first SPU program was a painful mess while I struggeled with the programming model (protip: Do not spend days minimizing local store access. Duh. :)).
    By the time I had finished my second program, I was hooked.

    (* Well, you can always as on DevNet.)

    Disclaimer: I work for Sony and I write SPU code all day. And I like it. ;)
     
  4. JPT

    JPT
    Veteran

    Joined:
    Apr 15, 2007
    Messages:
    2,009
    Likes Received:
    393
    Location:
    Oslo, Norway
    Your back in the game business, great, so when can we expect your next title? ;)
     
  5. Crossbar

    Veteran

    Joined:
    Feb 8, 2006
    Messages:
    1,821
    Likes Received:
    12
    Did you get head-hunted after the Eurogamer article?
     
  6. paawl

    Newcomer

    Joined:
    Feb 3, 2007
    Messages:
    113
    Likes Received:
    0
    For the record, Core Duo wasn't even available until months after it would have been needed for Xbox 360. (Core Duo was released to manufacturing in January 2006, Xbox 360 entered manufacturing in mid-2005.)

    Microsoft's only other choices for CPUs at the time would have been 2 GHz dual-core CPUs like the PPC970MP or Athlon 64 X2, or a 2.8 GHz dual-core Pentium 4 (likely without hyper-threading). Both of the x86 chips were significantly more expensive than either the PPC970 or the chip MS ultimately chose, and none were available from a second-source.

    So, MS got three cores instead of two, six hardware threads instead of two, a lower price (probably by more than $100), and a second source arrangement. I'd say their choice was pretty clear.
     
  7. T.B.

    Newcomer

    Joined:
    Mar 11, 2008
    Messages:
    156
    Likes Received:
    0
    I'm working on 1st part technology now, so while there is no title that's actually "mine", I may get to stick my fingers into all kinds of pies.

    A friend referred me, but I'm sure the interview was a plus. Still, I owe grandmaster a drink. :)
     
  8. JPT

    JPT
    Veteran

    Joined:
    Apr 15, 2007
    Messages:
    2,009
    Likes Received:
    393
    Location:
    Oslo, Norway
    So you've become a Sony SPU Ninja then, drops into an office in the middle of the night and moves performance critical functions to SPU's...... without the dev team knowing about it :lol:
     
  9. Billy Idol

    Legend Veteran

    Joined:
    Mar 17, 2009
    Messages:
    5,984
    Likes Received:
    822
    Location:
    Europe
    :lol::lol::lol:
     
  10. Graham

    Graham Hello :-)
    Moderator Veteran Subscriber

    Joined:
    Sep 10, 2005
    Messages:
    1,479
    Likes Received:
    209
    Location:
    Bend, Oregon
    Well, now that everyone has had a go at epics numbers, I'll just mention I did also say:
    :mrgreen:

    Disclaimer: I don't work for Sony, but I am currently writing SPU code all day. I tolerate it :razz:
     
  11. NRP

    NRP
    Veteran

    Joined:
    Aug 26, 2004
    Messages:
    2,712
    Likes Received:
    293
    Wow, didn't realize you weren't in NZ anymore. Congrats on the new job!
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...