Cell Interview w/developer Mike Acton

[Carl B]

Let's see if we can ride this whole RSX thing out with more of a focus on what PS3's really about... Cell!

Interview

 

[pipo]

Nice one!

 

[Carl B]

I know it's pretty long... it's kind of overwhelming in a sense for the less technical readers. I may be putting up an abridged version as well for those whose eyes would otherwise glaze over.

But to pick an aspect of the interview to set tone for discussion, I will say this - the entire idea of forming an entire code library around branch-free half-precision instructions to me is totally fascinating. And what I love about it and Mike, is that it's being done without any set expectations on returns - simply with the notion in mind that the journey itself wll likely yield positive results.

I meant to link to it in the article actually, but this is a link to the code library as it stands thus far:

http://www.cellperformance.com/articles/2006/07/branchfree_implementation_of_h_1.html

 

[darkblu]

a good article. and a heads-up to keep an eye on cellperformance.com.

 

[Arwin]

Truly awesome interview. It's almost a FAQ on Cell Programming in itself. :bows:

 

[patsu]

xbdestroya, thanks for the article. Been waiting for something like this for quite sometime now. I suppose we can never have some numbers to accompany the article given the NDA.

Mike's insight and knowledge is helpful. I'm working on a Cell project myself (something related to a virtual world with Cell network ). I have the basic request/forward/response, interpreter and navigation framework up and running since April, but there is a memory leak somewhere that forces me to restart the server every 2 hours at the moment. Haven't got the time to work on the Cell-specific part yet (but soon will).

Am trying to gather enough time and resources to move forward, given my day job. Will definitely keep an eye on CellPerformance.com (visited it once before).

Also look forward to more indepth articles from you. Would you be covering the DMA and XDR part (I need programming details to shorten my digging and development time ) ? Thanks again for the effort.

 

[Carl B]

Truly awesome interview. It's almost a FAQ on Cell Programming in itself. :bows:

I agree, I view it like that as well honestly... I think Mike enjoyed this whole thing to a large extent because on top of everything else, it provided a sounding board to get some of the key ideas he's discussed on CellPerformance.com summarized in one place/piece. It was almost the perfect storm of practice vs theory, and that he's genuinely excited about Cell all conveys through clearly.

Frankly I hope CellPerformance takes off in a big way; Mike himself is clearly possessed of a firm grasp on the architecture.

 

[Carl B]

xbdestroya, thanks for the article. Been waiting for something like this for quite sometime now. I suppose we can never have some numbers to accompany the article given the NDA.

Mike's insight and knowledge is helpful. I'm working on a Cell project myself (something related to a virtual world with Cell network ). I have the basic request/forward/response, interpreter and navigation framework up and running since April, but there is a memory leak somewhere that forces me to restart the server every 2 hours at the moment. Haven't got the time to work on the Cell-specific part yet (but soon will).

Am trying to gather enough time and resources to move forward, given my day job. Will definitely keep an eye on CellPerformance.com (visited it once before).

Also look forward to more indepth articles from you. Would you be covering the DMA and XDR part (I need programming details to shorten my digging and development time ) ? Thanks again for the effort.

I was actually thinking of asking him to do a Q&A session today at either PSINext and/or here, but his and I's schedules are just too far off from each other. But I would say that if you went to CellPerformance and either emailed him directly or posted in the forums (though they are young at the moment), you would almost certainly get a personal reply. Depending on the depth and complexity of the issue of course... I should add caveats before I commit Mike in his absence!

But anyway, not sure what's next on my target list for interviews. I'm waiting to see how TGS plays out and what the public info situation is afterwards.

 

[joebloggs]

Interesting stuff...

PSINext: Mike I wanted to end on this particular question, because I think it’s no secret the level of speculation there has been on message boards around the Web as to the potential for Cell to assist with the graphical output of the Playstation 3. The ray-cast clouds in 'Warhawk' seem to represent at least one example of Cell-assisted exotic rendering… and geometry and image post-processing effects seem to be what jump to mind most readily for ways in which Cell might normally assist. In what other ways do you think Cell might be utilized on the graphics side?

Mike Acton: Well, each developer is going to have their own tricks and ideas, and it's hard to speculate on what sort of amazing things we'll see over the lifetime of the Playstation 3. There are a few that seem like obvious choices:

o Compression; both image and geometry data. For the amount of content I expect to see over the course of this generation of games, real time decompression of just about everything that is pumped to the GPU will be a must-have. With the right techniques, at times working with compressed data will actually be faster than uncompressed data on the SPUs!

o Improved 2D graphics. Not just user interface elements, which in my opinion don't get nearly enough attention in games, but in any 2D image used in the game. I expect to see animated image, normal and depth maps - not the wasteful and uninspired flip-book style we see occasionally now, but fully skeletal, curved animations. It could, for example, be a tattoo with dozens of different animations depending on the mood of the character, or maybe leeches that attack and crawl under the skin of the character. And fonts. Real fonts. I want to see beautifully rendered, perfectly set fonts at any scale.

o More complex character skeletons. Transforming a character's skeleton animation data on the GPU generally means limiting the number of influences each vertex can have. I'd like to see some complex characters with a thousand bones or more, where the skeleton can be re-arranged depending on the circumstance, and some amazing animation (for which you'd need the above compression) to go along with it. For instance, fantasy games have a lot of opportunity to explore character complexity on the Cell. While it's not impossible to achieve that character complexity using the GPU, it is a task well suited for the SPUs.

o Lighting - I hope that we'll finally see the death of baked-in lighting. I don't mean to say that lighting influences, light and shadow maps, and combined lights won't be cached. But there will always will be some freedom for those values to be changed by the artists at runtime, even if they can't change every frame.

o Particle systems and effects. And I don't mean a shower of points or sparks! Effects are especially well suited to offloading to the SPUs, so I expect this is the first place we'll see the complexity of animation, physics and graphics really come together.

o Vertex animation. There's almost certainly going to be a mountain of water effects, plasma-type effects, velocity field effects, etc. that will make their way into the games simply because these are excellent entry points into Cell programming.

o Terrain generation. IBM has already put together a ray-cast terrain generator, but I expect to see something a little more GPU friendly. With broadband built into the Playstation 3, who knows? We might even see an earth based game that generates its backgrounds on the fly using Google Earth!

And of course continued work on procedural images and geometry, and maybe offloading some Cg onto the SPUs.

At the end of the day, I don't know all the ways developers are going to take advantage of the Cell for graphics over the lifetime of the Playstation 3. No doubt, these are things we'll be working on right up until the moment we get our Playstation 4 devkits!

 

[ROG27]

This one I found particularly interesting:

o Improved 2D graphics. Not just user interface elements, which in my opinion don't get nearly enough attention in games, but in any 2D image used in the game. I expect to see animated image, normal and depth maps - not the wasteful and uninspired flip-book style we see occasionally now, but fully skeletal, curved animations. It could, for example, be a tattoo with dozens of different animations depending on the mood of the character, or maybe leeches that attack and crawl under the skin of the character. And fonts. Real fonts. I want to see beautifully rendered, perfectly set fonts at any scale.

Can I get some OCTO-CAMO in the house? I just couldn't imagine MGS4 without it now. And now I know why Kojima decided it could be implemented effectively.

 

[ROG27]

The following bullet points:

o More complex character skeletons. (assets that don't just look good, but move well, too.)
o Vertex animation. (animation that requires fluidity..liquid, plasma, fire, motion blur, etc.)
o Lighting (different types of dynamic lighting/shadowing)
o Particle systems and effects. (particle systems, effects, post-processing effects, animations, physics)

are helping push Sony's agenda for focusing on improved lighting, animation, physics, and effects. The combination of the above I hope will prove to increase the level of immersion in gaming. Because as it stands right now, the level of immersion has been stagnant for about 5+ years now. I truly believe that the layers of depth that can be added by these elements might (if implemented correctly) increase the level of immersion. The amount of programs which can be run in parallel is pretty astounding. The only thing I didn't see him cover was ai and simulation, which will tie all the bullet points above together and make them work cohesively in a game.

 

[scificube]

Extremely excellent article!!!! Please, please continue with articles of the type and pedigree!

 

[Carl B]

Thanks SciFi! I'll of course work to keep the dream alive.

@Rog27: Yeah I should have asked a specific AI question to tell you the truth - I had meant to, but forgot... which is unfortunate since I would have liked to see if there was any specific method Mike had tossed around in his head or in practice that showed above par performance.

For now though I think we just have to rely on the branching part of the interview as being the next-closest candidate to an AI answer, pending some other angle on it.

PSINext: Mike, from reading CellPerformance.com it seems a number of your articles have focused on helping programmers with the avoidance of branchy code. Are there any particular scenarios coding for Cell that you feel branch-heavy scripts will be unavoidable? What is your advice on how to deal with those situations?

Mike Acton: There are certainly some situations for which eliminating branches is not a real option, or at the very least it is extremely difficult. Here are some examples:

o High-level decision making: In complex codebases where there are many different workload options, it pays to branch. This is the essence of LOD, for example. Objects which are smaller and further away don't deserve as much CPU or GPU time as objects which are at the center of the user's attention. Often both the data and the code need to be selected based on some function, and this decision would be made relatively few times compared to any branches within the workload itself. These branches can and probably should be reduced by trying to make the high level design in terms of groups of objects rather than object-by-object.

o Abstract interfaces: Codebases which rely on the ability for the code itself to be changed based on the "type" of object or situation are forced not only to branch, but branch in the most unpredictable ways. Abstract interfaces are often lauded for the ability to simply change the implementation of a system while maintaining the interface. This is a popular pattern in test-driven development, where complex systems not under test are replaced with simpler systems in order to verify that the communication between that system and the system under test is done correctly. In this scenario, as with many other common uses of abstract interfaces, the selection of the interface is only done once, but all of the code throughout the system that may use it must pay the additional price. When possible, it's always better to make those decisions at link time and simply have different libraries with the same interface. In the cases where the decision must be made at runtime - for example loading a different module based on the user's settings - try to keep the interface as high-level as possible to minimize the impact it may have on the system as a whole.

o Virtual functions: Although these are really a type of abstract interface, they deserve special mention. Virtual functions are usually a matter of trading one bad solution for a worse one in terms of performance. A typical example might be to implement a Draw() or Update() function in game objects so that pointers to all game objects can be stored in a list somewhere and iterated on together. This pattern often leads to both poor icache performance, due to different functions being loaded into the cache in an unpredictable order, and poor dcache performance due to different, unused sections of the objects being loaded at each step. This is all in the name of making the list iteration simpler. When tempted to use a virtual function, programmers should consider hoisting the decision to a higher level instead. Based on the realization that the number of different implementations is fixed at compile time, the data is better stored in groups based on the implementation type and with a single function for each group. So rather than Cube :: Draw() and Torus :: Draw(), I prefer DrawCubes() and DrawTori().

o Irreversible or side-effect driven code: There are plenty of examples of execution paths which cannot be reversed and must only be executed based on some condition. There is no avoiding branching in these cases. For example, this applies when deciding to print some value to the screen or handling an error condition.

o Data interpreters: As an example, this can refer to a code interpreter for a scripting language or an interpreter for network data. In these cases the execution order is fixed and the data is very unpredictable from one section to the next. The natural tendency is to provide low-level functionality (i.e. one that echoes a typical processor instruction set) that is generic enough to handle any conceivable situation. This type of code would benefit most from peephole optimizations based on actual usage. Programmers should analyze the real-world data and find common patterns that can be combined into a single instruction or packet.

I should point out that I'm not suggesting that branches should never be used. Usually anywhere where the cost of misprediction is outweighed by what is gained from eliminating a large section of code (or even a series of additional branches) is a good use of a branch. I’m simply suggesting that it is better to make a habit out of minimizing branches - it's easier to add in branches where they would improve performance than it is to guess the performance impact of removing any particular branch in a completed system.

The ability to eliminate or minimize branching is an increasingly important part of the programmer's skillset. Beyond scalar integer or floating point code, SIMD programming is always about keeping pipelines filled as long as possible. This also extends to shader programming for modern GPUs. On CellPerformance.com, I chose to concentrate on this aspect of Cell programming early on because there are not a lot of resources for programmers to draw from when learning these techniques. However in the end, it's just one of a great many topics that I'd like to cover; there's simply not enough time to give every subject the attention it deserves. If any of your readers want to volunteer to help me write an article and learn about the Cell in the process, I could always use the extra help!

 

[Darkon]

Thanks for that article Xb , will there be another one soon ?

 

[Carl B]

Thanks for that article Xb , will there be another one soon ?

'Soon' is a relative term I guess... it takes time, which I think both Marco and Mike can attest to at this point! Not really trying to rush things out the door per se.

But, yeah, I hope so - I'm looking for the post-TGS timeframe for the next 'big' project. Some project idea'll come to me as that date approaches.

 

[Bohdy]

Excellent interview, and very informative. GREAT work, Mr. x

 

[Shifty Geezer]

It was nice to see him consider various tasks generally regarded as 'SPE Unfriendly' as mappable onto the hardware if you change the datatype. The Data-based philosophy is definitely the way forward in designing applications.

BTW : What exactly does Mike Acton do? Does he just research techniques at High Moon or is he working on a particular game or engine?

 

[Carl B]

It was nice to see him consider various tasks generally regarded as 'SPE Unfriendly' as mappable onto the hardware if you change the datatype. The Data-based philosophy is definitely the way forward in designing applications.

BTW : What exactly does Mike Acton do? Does he just research techniques at High Moon or is he working on a particular game or engine?

Yeah I liked the credit the SPEs got for 'non-obvious' workloads as well, certainly a positive for Cell.

Mike's more or less R&D-focused on best practices right now is the impression I get, but although I didn't ask, I'm sure that transates directly into engine work the team is doing. They are presently working on a PS3 title, though he couldn't go into any details with me as the game has not been made public yet.

Here's a bit of his bios from CellPerformance as to his history:

Most recently, Mike was the Lead Special Effects Programmer for Darkwatch at Highmoon Studios (previously Sammy Studios) in Carlsbad, CA. Previously Mike has held Lead Programming, Playstation 2 Engine Development and Research roles with Yuke's, VBlank and BlueSky/Titus. He worked for Sony Interactive Studios in PSX development.

Mike has made regular appearances as a speaker at SCEA develpment conferences and has spoken at GDC.

Mike Acton is not a framework-happy C++ programmer. He actually likes C. And assembly. In his spare time he develops hardware on FPGAs in VHDL.

PS - I revised the navigation system in the article, such that each section is reachable from the others now.

 

[rounin]

Well done Please keep it up with more interviews. Exclusives like this do a site good