cg Lives! Nvidia shader lang for PS3 :)
- Thread starter pocketmoon66
- Start date
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.Ostsol said:
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.AndrewM said:
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.bloodbob said:
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.
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.bloodbob said:
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.
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.bloodbob said:
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.
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.
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.
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?bloodbob said:
Zeross said:
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.
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.
Similar threads
