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

[Titanio]

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.

[Carl B]

I think he's just offering openMP and Cg up as examples, not linking them to Cell. But going to read the interview now. :)

[Titanio]

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..?

[Nite_Hawk]

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

[Carl B]

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

[nAo]

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.

[Titanio]

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 ;)

[Farid]

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?

[Bobbler]

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]

Wasn't that already hinted as possible a "long time" ago?

IIRC, there was a semi-ambiguous comment from Mark Deloura from SCEA a while back. But it was mostly speculation.

Maybe we should listen to zdnet.com more often:

http://news.zdnet.com/2100-1040_22-5606515.html

Cell will also use Cg, a language developed by graphics chip leader Nvidia for creating high-level graphics effects.

;)

[Shifty Geezer]

I too vaguely remember hearing something about running Cg on Cell, but I don't know where.

[mckmas8808]

Now exactly how would using Cg on Cell to do vertex shaders help a PS3 game?

[wireframe]

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.

[wireframe]

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.

[Titanio]

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

[DeanoC]

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.

[wireframe]

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 (http://developer.nvidia.com/page/cg_main.html) and Cg toolkit (http://developer.nvidia.com/object/cg_toolkit.html))

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.

[mckmas8808]

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?

[Titanio]

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 (http://developer.nvidia.com/page/cg_main.html) and Cg toolkit (http://developer.nvidia.com/object/cg_toolkit.html))

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

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 ;)

[Jawed]

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

[mckmas8808]

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

Oh okay, so more than likely they are using it then.

Cool.:cool:

[Shifty Geezer]

Does it matter though? Whether they're writing in C, C++, Cg, Fortran, PASCAL, hex-code or the Aztec language N'ahuatl, who cares as long as it's a good game?

[!eVo!-X Ant UK]

Just a Few simple questions if i may??

1. Does it mean that Cell is not as difficult to program because its using this Cg thing???

2. What does it mean to the GAMES???

[Jawed]

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
On the other hand, does Cg support objects?

Jawed

[wireframe]

Does it matter though? Whether they're writing in C, C++, Cg, Fortran, PASCAL, hex-code or the Aztec language N'ahuatl, who cares as long as it's a good game?
I thought it was fairly obvious that the Cell BE will be programmed using C/C++ with some inline assembly and that RSX will have shader code generated by Cg. That is, until I read this thread. :smile:

I'm completely lost as to what is being discussed. Are people thinking that Cg will be used to program Cell? If so, why? Why not use GCC?

EDIT: I am really hoping this is all just confusion as to what Cg is/does. Think Microsoft HLSL, or even GLSL if you must. Think Visual Studio (to some extent).

[wireframe]

Are you guys using Cg on the Cell?
Just to point out the confusion, I will use this question.

If DeanoC answers "yes," what will you take that to mean? That Cg is being used to program Cell itself or that they have CgFX and the Cg compiler running on Cell and its operating system?

[Titanio]

Just to point out the confusion, I will use this question.

If DeanoC answers "yes," what will you take that to mean? That Cg is being used to program Cell itself or that they have CgFX and the Cg compiler running on Cell and its operating system?

I think it's fairly clear he's asking if they're compiling Cg "shaders" to run on Cell. That's really what we're talking about here. The reason you might want to do this is if you had a set of shaders for RSX, and wanted to, for example, do some vertex shading on the CPU, you could compile to it from the same Cg code instead of writing new SPU C, or whatever. Maintain one set of code to compile to two chips.

[Jawed]

Also LS management could be problematic in Cg, unless it's extended in some way. Hmm... "unoptimised" sounds like the norm for code running under those conditions.

Jawed

[mckmas8808]

I think it's fairly clear he's asking if they're compiling Cg "shaders" to run on Cell.

Yes this is what I was trying to ask. I wonder if DeanoC and the guys are doing exactly this.

[wireframe]

So, the whole mystery is if the Cell will be used to augment RSX in shading and if the Cg compiler has been "tuned" to make this happen?

I must confess that I am not sure why this notion gets so much attention. Is there a general feeling that the vertex processors on RSX won't be enough? If you look at the proposed specs of RSX and its processing-to-bandwidth ratio, I'd say that there will be time for running shaders aplenty. Please enlighten me.

[mckmas8808]

So, the whole mystery is if the Cell will be used to augment RSX in shading and if the Cg compiler has been "tuned" to make this happen?

I must confess that I am not sure why this notion gets so much attention. Is there a general feeling that the vertex processors on RSX won't be enough? If you look at the proposed specs of RSX and its processing-to-bandwidth ratio, I'd say that there will be time for running shaders aplenty. Please enlighten me.

I'm not a programmer or anything, but honestly it's the lack of RSX information that has me thinking these crazy thoughts. It makes me feel like the RSX will be kind of a let down, so I'm trying to see if the CELL can help a little.

I hope I'm wrong.

[wireframe]

I'm not a programmer or anything, but honestly it's the lack of RSX information that has me thinking these crazy thoughts. It makes me feel like the RSX will be kind of a let down, so I'm trying to see if the CELL can help a little.

I hope I'm wrong.
A bit OT, but if you are subconsciously doing "damage control" for what you feel may be an inferior product, wouldn't this "solution" eat into other arguments that you may be having that Cell "is not all that"? Let's say you use Cell to augment RSX in this way, you'd be taking processing power away from Cell to do something else. See what I mean? :wink:

I don't get the feeling that RSX will be a let-down at all. If so, how? Compared to Xenos/C1? I choose to look at it this way: If Nvidia provided the graphics for the original Xbox and that worked out so that many thought it had the best graphics in its time, why wouldn't Nvidia be able to pull this off again? Just because it's the Playstation instead of Xbox doesn't mean Nvidia suddenly lost its marbles. In fact, I would argue the other way around. Now you can get a "pure" Nvidia solution that includes Cg because Microsoft is out of the picture. OpenGL is Nvidia's home base and there are no rolled in politics to use DirectX instead. That may not be necessarily better, but let's wait and find out, shall we? :smile:

[mckmas8808]

Oh I feel you are right, I'm just losing my mind waiting on this RSX information. I want to be wrong trust me, but I just really need some information on the RSX.

[ihamoitc2005]

Oh I feel you are right, I'm just losing my mind waiting on this RSX information. I want to be wrong trust me, but I just really need some information on the RSX.

Do not fear my friend RSX is fastest according to many developers including Xbox360 developers. RSX, if based on G70, is based on very efficient and proven design and in closed box environment will be fully utilized unlike in PC environment where game software is generic and not optimized.

[Bobbler]

Oh I feel you are right, I'm just losing my mind waiting on this RSX information. I want to be wrong trust me, but I just really need some information on the RSX.

You might end up in an insane asylum if Sony does what I think they'll do (i.e. not release information all, so people will assume PS3's graphical prowess has to do with Cell -- furthering of marketing never hurts). We'll probably have it trickle out sooner or later, but I wouldn't expect the information to come from Sony.

[mckmas8808]

You might end up in an insane asylum if Sony does what I think they'll do (i.e. not release information all, so people will assume PS3's graphical prowess has to do with Cell -- furthering of marketing never hurts


NOOOOOOOO!!!!!

[Jov]

So, the whole mystery is if the Cell will be used to augment RSX in shading and if the Cg compiler has been "tuned" to make this happen?

I must confess that I am not sure why this notion gets so much attention. Is there a general feeling that the vertex processors on RSX won't be enough? If you look at the proposed specs of RSX and its processing-to-bandwidth ratio, I'd say that there will be time for running shaders aplenty. Please enlighten me.

How about seeing it this way. What exactly is enuff? Do we even know Sony's goals? Maybe the RSX isn't enuff for what Sony and their devs want to do for next-gen gaming.

This does not automatically mean its not up to par or beyond the Xenos.

[DeanoC]

Are you guys using Cg on the Cell? Nope not at the moment but we (NT) have a Cg parser in the archived codebase from Xbox days so we probably could, of course without a bucket load of optimisations it would suck. But if one guy (Simon when he worked with us at JAM) could write one, why couldn't a big corp like Sony.

For why you would want to... the honest truth is that C and SIMD code don't mix. Quite frankly GCC (and VC) suck at it, so if you do any vector maths you usually end up doing it in intrinsics which is basically a macro assembler. HLSL/Cg are better designed for vectors so it much easier not to end up in intrinisics.

[Titanio]

Would there be much value in Sony investing resources into a specific version of Cg for RSX? Or would the standard compiler be pretty much as good for it as it could be?

I ask because Sony does seem to have put people onto Cg compiler optimisation and the like. Will there be a specific RSX version? Of course, they may also be looking into a Cell version too.

[DemoCoder]

Cg provides benefits that raw C programming doesn't because you can use the effects framework stuff to describe effects and a semantic linkage between variables in shaders and in GUI effects editors. You see this in Microsoft's FXC. It's good that artists don't need to hack C code to edit essential effect parameters and can use high end 3D modeling tools to tweak shaders.

But Cg could also be extended, to support DirectX10 features like geometry shaders. These geometry shaders would then be compiled via the Cg compiler to run as an SPUlet. You'd do vertex and geometry shading for some objects, and the Cg compiler/runtime would transparently decide whether it needs to run on the SPU+GPU or just the GPU. Don't forget Cg is also a runtime interface to OpenGL and not just a parser.

You wouldn't run general purpose SPU code in Cg, but code that conforms to well known stream-based algorothms could have an execution model in Cg where it would be efficient to write code using that language (e.g. Geometry Shaders)

[flick556]

The objects in cg and the language in general is tuned towards parralelism. I think the compiler already does quite a bit to unroll loops and avoid branches also. If performance is good I'm sure developers will find uses for it. If we conceptualize a vertex to be simply a vect4 input than it can easily have uses outside of graphics, especially if we can do some things with the output other than pass it to the pixel shader.