An interview with Alex Chow on Cell Programming models (he mentions Cg..?)

Titanio

Legend
http://www-128.ibm.com/developerworks/library/pa-expert8/

It's dated 22 Nov, but I hadn't seen it discussed here - sorry if old!

Very interesting read. One bit that jumped out at me:

dW: Do the programming models require some pre-knowledge by the compiler?

Chow: The currently released compiler and toolchain do not have pre-knowledge of any programming model. Some other compilers, for example, openMP and Cg, define their own programming model through their languages.

Cg...as in Nvidia Cg...?! That's the only Cg compiler I've heard of at least. The implications would be...:D

The rest is well worth reading aswell. Some other info there like the cost of a context switch on the SPU (20 microseconds) too.
 
Last edited by a moderator:
I think he's just offering openMP and Cg up as examples, not linking them to Cell. But going to read the interview now. :)
 
xbdestroya said:
I think he's just offering openMP and Cg up as examples, not linking them to Cell. But going to read the interview now. :)

There is an openMP compiler for Cell though..

I didn't think to question that he wasn't linking them to Cell, just whether there was some other kind of Cg compiler out there! It seemed very much like he was saying "well this doesn't but these do". Unless many other compilers don't have similar characteristics, it would seem rather coincidental that he'd choose to mention Cg also, given NVidia's involvement on the other side of the bus so to speak (especially given that his other example is on Cell too). It also happens to be the one other compiler amongst those mentioned that isn't explicitly IBM related - why would he know much about it..?
 
Last edited by a moderator:
Titanio said:
There is an openMP compiler for Cell though..

I didn't think to question that he wasn't linking them to Cell, just whether there was some other kind of Cg compiler out there! It seemed very much like he was saying "well this doesn't but these do"...

I seem to remember there being some discussion about CG and cell a number of months back, but I really can't remember any of the details. It certainly would be nice. :)

Nite_Hawk
 
Well in any event just finished reading the interview: good interview! The first half is especially interesting I feel.

...dW: The current way that the documentation seems to keep pointing to is that the SPE executable stuff is embedded within the ELF as a section. Is there any model development towards having the SPE executable as its own stand-alone file that can be read in by a framework application?

Chow: Yes, we do have that. We have a runtime environment that can take the SPU stand-alone executable as-is and run it on an SPU. We call such stand-alone SPU executable, SPUlet.

dW: Is that built on top of, like, the SPUFS model (See Resources) that was developed in Boeblingen?

Chow: SPUFS is a resource representation model that the kernel uses to manage SPU-related resources. Though the representation provides a clean boundary between what user-level applications can do and what kernel does, it is not convenient for an application programmer to use directly. Our additional runtime environment provides two different models for the Cell programmer. One is the SPUlet model. A programmer simply creates an SPU executable, and our runtime environment can load it to an SPU and start its execution. In this case, the SPU executable is a stand-alone file. It does not need to be included in a CESOF file. Another model is called SPE-thread model. It is also built on top of the SPUFS representation. A programmer using the whole Cell resource usually programs to this SPE-thread model that allows the programmer to manage more than one SPE program or thread. We use CESOF to piece together these different SPE programs and PPE programs into a single executable image.

dW: And another term that I noticed you used in your paper was "double-buffering." I'm aware of the use of the term "double-buffering" in video composition, but it is also the correct term in this application?

Chow: It is a term and technique frequently used by PS2 game programmers. Of course, there is a similar concept in video composition. Because the DMA engine and the CPU can operate independently, we start the data transfer of a new piece of data while we are processing the old piece of data. In the video composition term, we are drawing the next frame while we are showing the previous frame. A similar technique used by the MPI programming is called "prefetching."

dW: I see a lot of "mailboxes," references to input and output "mailboxes." Is that basically a DMA address?

Chow: No. The mailbox is a special set of registers of SPE and PPE. Each SPE can communicate with the PPE through these registers. A PU program can simply send or receive 32-bits data to and from SPU . It can be used as a very simple synchronization mechanism between PPU and SPU programs.

dW: Is it polled or interrupt-driven?

Chow: Both -- the architecture can support both...
 
Last edited by a moderator:
Titanio said:
Cg...as in Nvidia Cg...?! That's the only Cg compiler I've heard of at least. The implications would be...:D
That you could compile a vertex shader to run on a SPE, nothing ground breaking here.
 
nAo said:
That you could compile a vertex shader to run on a SPE, nothing ground breaking here.

I wasn't thinking so much technical issues, but more that to me it would suggest tighter collaboration between NVidia and Sony than I might have expected. A clearer manifestation of all that CPU<->GPU talk too. But it does also raises other technical issues, who's answers could or would be interesting (like balancing between SPUs and vertex shaders - manual or automatic? etc.)

And confirmation that we could compile a Cg vertex shader to Cell would be new ;)
 
Last edited by a moderator:
Titanio said:
And confirmation that we could compile a Cg vertex shader to Cell would be new ;)
Wasn't that already hinted as possible a "long time" ago?
 
Vysez said:
Wasn't that already hinted as possible a "long time" ago?

I think the only hint came out of speculation about how it would be kind of cool to be able to use Cg on an SPE -- I don't remember any rumor from any sort of official source (like a leak from IBM or Nvidia). Not sure there was any solid evidence to come to any conclusion -- it seems it is definately a possibility now though!

Although, I'm not really sure what you'd really want to use it all for in a vast majority of the cases, but more choices is nice, I suppose.
 
Titanio said:
The implications would be...:D

Like has already been stated, he is using Cg as an example. One obvious reason for this may be that the Cg compiler has to made to work with Cell as Cg is part of the Playstation 3 development platform.
 
mckmas8808 said:
Now exactly how would using Cg on Cell to do vertex shaders help a PS3 game?
Cg will be used to code, notably shaders, for the RSX. It would make sense to have Playstation 3 compatible Cg (hence Cell compatible and exploiting) to prevent having to cross-compile from another platform. Cg on a Cell workstation keeps it all under one roof, so to speak.
 
wireframe said:
Like has already been stated, he is using Cg as an example. One obvious reason for this may be that the Cg compiler has to made to work with Cell as Cg is part of the Playstation 3 development platform.

It'd be the odd one out then..

Does Nvidia provide for Cg running on PC CPUs (as a backup, emulation etc.)? This wouldn't be a million miles from that anyhow..
 
Titanio said:
I wasn't thinking so much technical issues, but more that to me it would suggest tighter collaboration between NVidia and Sony than I might have expected.
Why would it suggest a closer collaboration? Cg is an open standard, non nvidia people could and have written there own parser... if you had to choose a vector C like language, Cg would be a reasonable one to start with and it would have nothing to do with NVIDIA.
 
Titanio said:
It'd be the odd one out then..

Does Nvidia provide for Cg running on PC CPUs (as a backup, emulation etc.)? This wouldn't be a million miles from that anyhow..
I don't really understand what you are saying or asking. Cg is ultimately a compiler that takes something like C syntax (hence "C for graphics" = Cg) to generate GPU code. It is Nvidia's "equivalent" to Microsoft's HLSL. So, if you are saying "Cg running on PC," I take it you mean the Cg Toolkit, which currently exists for Windows, Linux, and MacOS X. (Main page/introduction and Cg toolkit)

What I am saying is that it will (does) also exist for the Playstation 3 development platform as this technology is part of that platform, along with OpenGL ES and what-have-you.
 
DeanoC said:
Why would it suggest a closer collaboration? Cg is an open standard, non nvidia people could and have written there own parser... if you had to choose a vector C like language, Cg would be a reasonable one to start with and it would have nothing to do with NVIDIA.

Are you guys using Cg on the Cell?
 
wireframe said:
I don't really understand what you are saying or asking. Cg is ultimately a compiler that takes something like C syntax (hence "C for graphics" = Cg) to generate GPU code. It is Nvidia's "equivalent" to Microsoft's HLSL. So, if you are saying "Cg running on PC," I take it you mean the Cg Toolkit, which currently exists for Windows, Linux, and MacOS X. (Main page/introduction and Cg toolkit)

I'm wondering if this can compile to PC CPUs? My guess is no, but..

DeanoC said:
Why would it suggest a closer collaboration? Cg is an open standard, non nvidia people could and have written there own parser...

I wasn't aware of this ;)
 
mckmas8808 said:
Are you guys using Cg on the Cell?
DeanoC's implication appears to be that Cg makes for a very good Vector C programming language.

Since Cell's design is so strongly focussed on vector processing, Cg seems to make a good match. Regardless of whether the code is for graphics or physics etc.

Jawed
 
Back
Top