cg Lives! Nvidia shader lang for PS3 :)

That assumes that the new platforms will support OpenGL. If it doesn't, or it supports its own proprietary API, you're stuck.

 

That's actually incorrect, if you're using the Cg runtime.

It's "portable" in that you can take your Cg code and use it with MS's HLSL as they are (almost) identical.

 

OpenGl is just an API whats to stop XYZ company writing a wrapper to whatever API the XBOX-2 is going to use? Nothing then you can run a GLSL compiler which compiles to whatever assembly language is used.

As chanolth has already state Cg won't work for R200 assembly it would require someone to write it say ATI. Cg only works on the DX/NV/OGL ASM platforms because Nvidia has already writing the code for it. Someone always has to write code for it.

Just because something has less support for it doesn't make it less platform independant.

 

Umm the Cg runtime comes with profiles already with it if you downloaded a really old version of the Cg runtime and tried to get it to compile PS3.0 shaders I doubt it would.

Which means instead of shipping new assembly your argument says we will support new platforms by shipping the whole compiler with new profiles. Regardless it still requires an update.

 

Considering that you can write a Cg program so that it compiles via HLSL, this is hardly a problem. Granted, you can also write Cg programs that won't compile via HLSL, but the similarity of the languages should still make porting most shaders from Cg to HLSL trivial.

Sure, if one exists.

That's like saying that Cg having support for both Direct3D and OpenGL targets makes anything supporting it less portable. Makes no sense.

 

I didn't think anybody cared about programming for the R2xx anymore.

 

That could proably be done, but it would be a hell of alot of work. It'd certainly be much more work than writing a compiler profile for Cg.

Why do you even bother mentioning the R200? It isn't supported by GLSL either. There's no difference between either in that example.

 

Okay you have two langauges.

Language 1 you get a compiler on your platforms. ( And you ship the source code ).
Language 2 you get a byte code compiler for your platform as each platform has a different byte code VM and then you get an interpter for the byte code on each platform.

You write your software only using standard lib calls and not using any platform specific features. I.E. in the case of C it would be standard C libaries.

Which would you be better off with?

Now if you seriously think your better off with Language 2 because you can go off and fiddle with the byte code fine go code with .NET and Java for preformance since you guys can optimise the byte code.

Sure those 2 are platform independant but that only because they produce 1 set of byte code where as Cg produces multiple so its not the same.

 

C/C++ is language 1. They compile directly from the high-level language down to the platform specific byte code.

Python is language 2. It compiled down to bytecode and is interpretted by the redistributable.

AFAIK, Java and .NET are a combination of both. They all initially compile down to a platform independant immediate language. The immediate language is converted down to platform specific byte-code by the redistribution. They are not interpretted languages.

Now, which would one be better off with? Either way is fine, really. The difference is that with language 1 you need the full compiler and with language 2 you simply need to convert the immediate language.

For GLSL you must distribute the high level code and hope that the compiler exists on the target platform. If it doesn't exist, you're screwed.

For Cg you compile the high level language down to the appropriate byte-code and distribute that. If the compiler doesn't support the platform, your screwed.

The difference is that the latter can be made to support the platform. As long as details about the platform's byte-code is available, this is possible. The former requires that the platform's developer be open to adding supporting a foreign API.

 

When the API is an industry standard rather then multiple priopertry standards for the byte code ( With the exceptoin of the ARB ASM ).

 

How does this at all apply, though? There is no industry standard API -- the industry being game and entertainment-platform development. With that in mind, how is GLSL a better choice than Cg for portability?

 

Cg won't like compile to byte-code on PS3. For example Vertex Shaders may compile down to CELL SPE instructions, and there may be a new type of shader, a Geometry Shader which compiles to SPE programers.

Moreover, why go Cg -> bytecode (pixel shader) -> VLIW GPU when you can go Cg -> compiler IR -> VLIW GPU. As GCC4.0 shows you, and as I have been arguing on this board for the last 2 years, assembly language sucks as an intermediate compiler language. The choice of intermediate representation is vital on compiler performance, and GCC only learned this lesson after years of sucking with RTL and finally switching to Tree SSA.


The reason why you don't go the GLSL route is because you don't own the syntax. PS3 may demand new shader types, like tesselators, geometry shaders, PHYSICS SHADERS, etc which you write as short programs in Cg and compile down to CELL SPE Apulets. This may require extending GLSL beyond just new library calls. To program CELL, you need a new language that is "stream oriented" for small subtasks.

Hence, extending GLSL but still calling it "GLSL" would be worse IMHO than simply creating your own language and extension, optimized for CELL+GPU.

Those hoping that somehow PS3 games will port easily to PC and XBox2, and hence want console games to be written AS IF they were going to be compiler on a PC with DirectX or OGL2.0 are hoping too much.

 

Oh so the OpenGl ARB isn't an industry body? geeze I wonder why they have all these different companies as members like ati and nvidia and apple and stuff.

 

AFAIK. Cg wont have anything to do with CELL - only the gpu programs.

You can still have some code portability.

 

It's highly expected that the Cell's SPE would deal with the TnL and other Vertex operations.

 

Yes but IBM has stated that SPE will be programmed using traditional C/C++
Cg isn't general enough for this task, it's too deeply tied to GPU and their current shortcomings.

 

The ARB defines the standard to which OpenGL is defined. Outside of OpenGL they have have no influence other than marketting. No one has an obligation to provide support for the API other than for supportting software previously written for a given platform. New platforms use whatever they want and if they decide not to support OpenGL, how portable does that make your GLSL code?

 

Some stuff will be written in C/C++ and some will be written in Cg. Vertex shaders will likely NOT be written in C++ most of the time. You *could* write them in C++, but you would

a) lose the ability for less technically inclined people (art pipeline oriented people) to edit them
b) the ability to move shaders freely between CELL PPC core, SPE core, or GPU VS core.

When you need complete generality, you're likely to program in C/C++. However, for the art pipeline, effects are likely to be managed and written in a higher level language customized for the effects domain.

Just like with game logic and AI. Some stuff is written in C/C++, and some is written in the engine's scripting language. IBM could state that "SPE will be programmed in C/C++", but they have no control over the tools and middleware market and what will evolve.

NVidia has the opportunity to enhance Cg to make it more general, capable of handling displacemap mapping/tesselation/geometry shading ala RenderMan, or perhaps adding the ability to process physics ("physics shading") or generalized DSP routines.

Demanding that the PS3 be limited to standard OpenGL makes zero sense. And any game that is not a shitty-port, but written for the PS3 specifically, is not going to run on a PC very well.

So the idea that PS3 developers should be forced to write portable, multiplatform code is insane.

The PS3 is likely to have a market of third party compilers, concurrent languages, etc because concurrent programming is hard, and traditional tools available frankly suck. IBM's marketing not withstanding, there is no generally accepted solution (e.g. language, tool, and library) that produces high performance, generalized concurrent code, that is reliability debugged.

It is an area of rich research.

 

I have to wonder why this topic keeps popping back up.

Who cares, it's not like consoles have ever stuck to "standard" API's. Even Xbox which is as close as it gets has a number of extensions to "standard" DX8.

We write every shader for every platform now, and I wouldn't really expect it to be any different with the next gen stuff.