GDC08: Insomniac SPU Best Programming Practices

Discussion in 'CellPerformance@B3D' started by Mike Acton, Feb 28, 2008.

  1. Mike Acton

    Mike Acton CellPerformance
    Newcomer

    Joined:
    Jun 6, 2006
    Messages:
    47
    Likes Received:
    2
    Location:
    Burbank, CA
  2. neilcostigan

    Newcomer

    Joined:
    Feb 28, 2008
    Messages:
    2
    Likes Received:
    0
    Not much to say except thank you for sharing this.

    One question..
    "When is it better to use asm?
    When you know facts the compiler cannot (and can take advantage of them)‏
    i.e. almost always."

    Really ?

    I've attempted this for pipe-lining in a small domain, and found that reordering at the intrinsics level appear to give me as much control.
    granted it was a small body of code heave on shuffle and integer operations.
    but 'thinking ahead of the compiler' at the intrinsics level appeared to offer me as much control as I needed.

    -neil costigan
     
  3. Carl B

    Carl B Friends call me xbd
    Moderator Legend

    Joined:
    Feb 20, 2005
    Messages:
    6,266
    Likes Received:
    63
    The presentation itself I thought was very well put together, in terms of setting up the context of the development environment and then presenting IG's solutions to such, with of course an emphasis on the SPU Shading.

    I noticed this quote from your R&D post:

    I think it just comes down to team goals/philosophy in terms of what other devs are dealing with. Obviously your situation is very different from a cross-platform situation, so for a lot of folk I think it turns into more of a theory lesson than something they may feel practical to their own development. As for PS3-specific devs, by this point I think we can recognize that there has been a *lot* of effort put into internal systems and tools at the major players, and there's probably a fairly high mental barrier towards re-construction for the time being.

    This actually brings me to a question regarding Insomniac's own case. When you arrived, what was the chain of events that saw the SPU shading model be suggested, and were there dissenting opinions?
     
    #3 Carl B, Feb 28, 2008
    Last edited by a moderator: Feb 28, 2008
  4. Npl

    Npl
    Veteran

    Joined:
    Dec 19, 2004
    Messages:
    1,905
    Likes Received:
    6
    The obvious thought: Thanks alot for sharing :yes:.

    Just got a question regarding the "deffered effects" on Resistance 2. If I understood right, you process effects for frame n with the state of frame n-1.
    - What kinda stuff are those "effects", do they affect game-state (ex. physics) or are they only visual?

    Also, it appears to me that you need alot more buffers in R2 compared to R1 (deffered effects, prealloc push-buffers,..).
    - Given that memory is a very scarce resource in the PS3, is the benefit of having SPUs more active always worth it or are you already balancing SPU-Time (which requires additional buffers for working undisturbed) vs. Memory (for Textures, Geometry, whatever)?
     
  5. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,333
    Likes Received:
    129
    Location:
    San Francisco
    I attended your presentation Mike and I had so much fun!
    Unfortunately many ppl in the room were not laughing at your 'jokes', I wonder why.. :)
     
  6. Mike Acton

    Mike Acton CellPerformance
    Newcomer

    Joined:
    Jun 6, 2006
    Messages:
    47
    Likes Received:
    2
    Location:
    Burbank, CA
    Yes. Really.

    Of course writing asm gives you the opportunity to write better code. There tons and tons of transformations that just haven't been coded into the compiler's optimizer that you can do yourself. There are classes of transformation without a way to even describe to the compiler (an obvious example being optimizing branches and branch hints outside the very simplistic cases).

    However, I certainly wouldn't say that intrinsics can't get you very far. You can get quite a lot of the "power" from using intrinsics (well, just so long as you're using the si_* intrinsics and not the lame spu_* ones) But as you said, you do end up spending a lot of time "predicting" the compiler, when you could in fact just write what you want in the first place.

    If using si_* intrinsics and letting the compiler do your register coloring and pipelining is all you need, then I'd say that's fine. But you are almost certainly leaving some performance on the table. But those final bits might not be valuable for your application. Or you might not have the time/resources/experience/etc. to take advantage. And that's fine too.
     
  7. Mike Acton

    Mike Acton CellPerformance
    Newcomer

    Joined:
    Jun 6, 2006
    Messages:
    47
    Likes Received:
    2
    Location:
    Burbank, CA
    I would say that appearances may be deceiving here. Compared to a legacy system without well designed data, the newer systems tend to use much less data. It may appear they need more buffers (and it may actually be true in some cases) but since the data is well organized and designed properly there isn't as much waste.

    When you design the data, it ends up being very clear what data is actually required (how much is actually necessary) and how you can/need to optimize for information density. And when you do make memory vs. speed trade-offs, there are very clear places in which to do it.
     
  8. TimothyFarrar

    Regular

    Joined:
    Nov 7, 2007
    Messages:
    427
    Likes Received:
    0
    Location:
    Santa Clara, CA
    Mike, I was not at GDC, but the slides are awesome, to the point, and inline with what I also believe is the way forward in the future of highly parallel machines ... as parallelism increases, algorithms become more and more performance bound on managing the flow and locality of data.

    It is somewhat sad that a lot of people are thinking this way and completely missing the point. The "situation" is exactly the same for everyone. The PS3 is a parallel machine, 360 is a parallel machine, the PC is becoming a parallel machine, GPU+GPGPU/CUDA/CTM is a highly parallel machine, Larrabee is going to be a highly parallel machine, etc, etc. The future hardware doesn't map to the old serial way of thinking. You either adapt or your code will run slow, it is so simple. Sure you can just about get away with bad code now on the 360, but for the next generation of consoles (or the end of this generation), I don't think so.

    Regardless of managed memory or cached memory, the concepts and methods Mike has presented is highly portable. In the case of cached memory, that method results in optimized cache locality and cache utilization (something extremely important when multiple threads are sharing L1 on a single core, and multiple cores are sharing L2), and a predictable way to optimally prefetch. Good data locality, minimal sync points, branch elimination, and vectorization are all required to be able to extract great performance out of the 360 as well.
     
  9. Carl B

    Carl B Friends call me xbd
    Moderator Legend

    Joined:
    Feb 20, 2005
    Messages:
    6,266
    Likes Received:
    63
    Timothy I think you missed the context of what I said, I wasn't making a judgment on the programming model - which if you browse through my post history you'll see I'm quite a fan of - I was simply stating in plain terms why the uptake among developers might be slow, especially for cross-platform devs who have automation tools at the center of what they do. It was a post in response/to explain why Insomniac might be a "lone-wolf" at the moment, as brought up in Mike's R&D page. I agree with you wholeheartedly that this is the future... but certainly you must agree with me that a lot of devs are going to procrastinate in shifting their thinking until they're either dragged kicking and screaming and/or new tools come in.

    Yes yes, I know I know. :razz:

    Hopefully this post has done its job of clarifying that I was simply explaining the reasons for industry inertia, not a post validating said inertia. Insomniac is way out in front here in terms of their philosophy, and they deserve a lot of credit. Mike especially has been championing these points for quite some time now, independent of and pre-dating his time there, and the existence of this sub-forum in general is a subset of those efforts.
     
  10. TimothyFarrar

    Regular

    Joined:
    Nov 7, 2007
    Messages:
    427
    Likes Received:
    0
    Location:
    Santa Clara, CA
    Truly sorry Carl, I did miss what you were saying!

    I agree. Many devs are afraid of the change. Partly because many non-core devs are not trained on and isolated from the hardware. So even though Mike's model is really simple it seems really complex because it is new way of thinking. The most common thing I get is, "but how do you parallelize common game code?". The approach I'm using is to try and give the other devs I work with some background knowledge on the hardware backed up with profiling of actual current game code to explain why things work slow (to put everything into practical terms). Then going through patterns which work fast. Definitely going to take some time before people catch on to a style which works well on parallel machines...
     
  11. Mike Acton

    Mike Acton CellPerformance
    Newcomer

    Joined:
    Jun 6, 2006
    Messages:
    47
    Likes Received:
    2
    Location:
    Burbank, CA
  12. Shifty Geezer

    Shifty Geezer uber-Troll!
    Moderator Legend

    Joined:
    Dec 7, 2004
    Messages:
    43,577
    Likes Received:
    16,029
    Location:
    Under my bridge
    This should be taken up and preached at all levels of computer education :
    This is why developers struggle, because their thinking is backwards. CPU's crunch data. The way you supply data is the limiting factor in CPU utilisation. I think perhaps you under-represent the importance of code, as a lousy implementation of an algorithm is going to impact performance. But the importance of Data has been so underappreciated that pedestalling it will help rebalance the industry. Think data first!
     
  13. paawl

    Newcomer

    Joined:
    Feb 3, 2007
    Messages:
    113
    Likes Received:
    0
    To be fair, I think that programmers learn to elevate code above data
    for a reason. In many (most?) programming environments, performance
    isn't the problem; development time, code maintenance, and the
    complexity of the system over its lifetime (which can sometimes span
    decades) are the problems. My biggest challenge at work is making
    sure the code is correct; performance is definitely not my concern.
    I'll just buy another cluster for about what one man-month of
    programmer time costs.

    Obviously, this is not the situation at all for games
    programming, and it's good that you try to beat it out of game
    programmers heads. Just don't start talking that way to my
    software developers! :)
     
  14. ShootMyMonkey

    Veteran

    Joined:
    Mar 21, 2005
    Messages:
    1,177
    Likes Received:
    72
    This is certainly where the source of a lot of differences lie for multi-platform and third-party developers and devs who are part of a network of multiple studios and such. The low-level aspects of going as data-parallel as possible, making jobs as tiny, totally independent, and self-managing as possible, enforcing certain absolutes so that you don't mess with "arbitrary-ness".. it all sounds good on paper, and you can easily make a case for it on other platforms.

    The problems in uptake don't really lie there, but in the effects on a team as a whole. It's easy to tell the engine team to do this, and they probably would have some success doing so. But then when you do need to support multiple game teams and develop on multiple platforms simultaneously, providing everyone on the game teams with an API and tools, maintainability, shareability, extensibility, flexibility, exposing things in a "friendly" way (particularly to non-programmers on the teams) all end up becoming much more important. It's one thing to say "optimize your data", and it's another thing to say "make sure everybody does it all the time for all things." It's one thing to say "this worked beautifully for us at Insomniac for Resistance and R&C" and another thing to say "we can make a multiplatform middleware product that centers on this idea, and licensees must follow suit in their development, else it's just a waste of time."

    I've been personally working on stuff that gives designers a hell of a lot of power (which they do want), but also allows them to pollute the codebase (and this includes spawning threads and jobs), and I can't exactly demand they to be cautious about instruction latency and DMA access. So the best thing I can do is ensure that everything going on behind the scenes is fast, and damn sparse in usage such that the overall impact is tiny (and for the time being, it is). Still, when you're exposing interfaces to designers, my first concern ends up being not "how is the data organized?", but "can designers make sense of this?" It's so easy for me to think that what I'm doing is easy to follow, but it's probably easier to forget that it may not be so simple to someone else.
     
    #14 ShootMyMonkey, Mar 16, 2008
    Last edited by a moderator: Mar 16, 2008
  15. Panajev2001a

    Veteran

    Joined:
    Mar 31, 2002
    Messages:
    3,187
    Likes Received:
    8
    SMM, reading your posts makes me think that at a future GDC or devstation meeting it would be great if Insomniac pushed out some presentations developed by their artists and game/level designers (for both online and offline gameplay).
    After 2 games completed and shipped which featured a lot of content and many hours of gameplay prepared for the user (and a third game well under way) I would like to hear about more about the experience, problems, successes, etc... of non-programmers in teams such as Insomniac and Naughty Dog.

    It is true that not having to license their code outside and not doing multi-platform development allows them to be more focused on pushing a certain HW platform, but that is a different argument from the one you are making about the interaction between the engine team+tools related programmers and non-programmers on the team as it would be a problem in your studio SMM even if you were PS3 focused.
     
  16. Shifty Geezer

    Shifty Geezer uber-Troll!
    Moderator Legend

    Joined:
    Dec 7, 2004
    Messages:
    43,577
    Likes Received:
    16,029
    Location:
    Under my bridge
    Better yet, an open debate with a panel of artists and coders from both sides, and an audience to offer questions and POV. Stick some devkits in the room with some of the tool being used and actually see the things in action. See what the artists can get their heads around when they try, and what coder-induced problems they face. I feel a lot of the arguments are being discussed in the vacuum of academia with polarized experiences throwing out perceptions. We know that people are using data-centric methods and are being successful with it. We know that other devs are having to accommodate art pipelines and such and can't afford the luxury of certain methods. I think both sides could do with ambassadors to each others arenas to see what's working, what isn't, and where their viewpoints fit in.

    We need a 'Wife Swap' but rejigged for 'Artist/Developer Swap'!
     
  17. ShootMyMonkey

    Veteran

    Joined:
    Mar 21, 2005
    Messages:
    1,177
    Likes Received:
    72
    One of the Sony dev day meetings a while back in Foster City kind of gave the impression that Insomniac, at least, is willing to set a lot things in stone (on a project-by-project basis, that is) and tear things down and reconstruct over and over on the assumption that nothing you use in one project is going to apply to the next anyway. It seems to me that in order to pull that off with any measure of success, you'd need to have a lot of things very well-defined very early on in development, and I don't know how often that happens at all.

    To top it off, we sort of have to worry about "licensing" our code. Not exactly, since it's still to another studio under the same SCi wings, but basically having 5 games on one codebase with what is really a single engine+tools team means there's suddenly a focus towards becoming a "product" and hitting that "1.0" milestone for the engine and tools. And that does raise all sorts of concerns. At least when you have the people who demand things of you in the same building, you can find out what they need by just heading over there and talking to them... what do you do when the artist or designer using your stuff is 3,000 or 10,000 miles away?

    Ugh. I just got an image in my head of a reality show like that... and given the nature of so many reality shows, I half-expect it to be hosted by John Romero. Well, okay, John Romero and Ryan Seacrest, but the latter only because he's friggin' everywhere. :razz:
     
  18. minty

    Newcomer

    Joined:
    Jul 9, 2007
    Messages:
    3
    Likes Received:
    0
    I see both sides of the discussion, maintenance being a key driver as important as performance for many situations, but what struck a chord with me was the 'lie' that says model the 'real-world' objects.

    I'm all for structure and a follower of OOD for many a year, but I think I've got a little too set in my ways in having say 300 car objects managed independently. Yes I can have a list of them and iterate nicely over them, but so what? One can lose sight of occasions when having a car fleet object and managing that directly might be more effective.

    I see that as applicable far beyond the world of high performance games engines...

    Sure there are occasions where the cars or ogres or swooping galaxians are needed as separate entities but the OO mantra does tend to sub-consciously encourage me to break things down to that level when actually managing them just as a fleet might help maintain the data and functionality in one place.
     
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...