Codeplay Responds to NVidia's Cg

[artisan7]

here is a pretty interesting Topic
about what the competitioni say about Nvidia Cg language ,
and the response from some programers experience with Cg language
about its LiMits and Potentials..

Hope this topic clears some of the misconceptions that still
exist about Cg and its usefulness or lack of ..for today for the the
3dgraphics industry .


http://slashdot.org/articles/02/07/27/2351222.shtml?tid=152

.



.

 

[RussSchultz]

This is sort of old news(at least a month), and has been discussed a little bit already.

http://www.beyond3d.com/forum/viewtopic.php?p=16938&highlight=codeplay#16938

As mentioned before, look what codeplay's products are before swallowing their comments whole without a grain of salt.

 

[KimB]

Certain design considerations in the language, such as the lack of integers, break/continue/goto/case/switch structures, and pointers suggest a general lack of universal usefulness.

I don't see why any of these couldn't be taken care of by higher-level abstraction.

First of all, there's no reason for use of any integers in the VS, and the format in the PS is dependent upon the pixel format (and the format of the textures, etc).

As for the break/continue/goto/case/switch structures, all of those can be taken care of as long as there is dynamic branching in hardware, which there certainly appears to be in the NV30 (Granted, it's more limited for the PS, but it's still there, in effect). None of these need a hardware update to use.

After all, the break and continue are just branches. Goto is considered bad programming practice (and is not used in any high-level language I've used since BASIC), and case/switch can just be considered a set of "if" statements.

 

[LittlePenny]

Maybe I am just way out of the loop here, but NV30 has no ALU at all? The way Cg works this would make sense. Seems like a good way to cut back on alot of transistors, but with what sacrifice? With an ALU you could certainly use integer based arrays, goto statements, and breaks with no sweat. Having access to those types of functions would have made Cg all that more usable.

I wonder if Cg is used in OGL2.0, where this would leave non-FP based VPU/GPUs. I certainly don't think 3dLabs wants the P10 using its FP unit just to keep track of arrays. Seems like quite an inefficiency for those poor souls.

 

[artisan7]

"This is sort of old news(at least a month), and has been discussed a little bit already."
-----------------------------------------------------------------------------------
wow! sorry about that .never saw that topic.. lol


However the above link shows Very interesting! disscussions from programers there about Cg... most of them really welcome it..

 

[KimB]

The only reason for any integer operations, from where I'm sitting, is for low memory bandwidth hit in the pixel portion of the engine. All vertex ops have been using floating-point calcs for years. It's just not feasible to use integers for vertex calculations.

Additionally, if you're going to use integers in the pixel portion, it's pointless to force it the GPU to use integers for the math...the pixel formats of the framebuffer and textures will determine whether or not those use integers.

If anybody *really* wanted to use integers in their GPU (In a way that would require Cg support), I don't see any reason why they couldn't be added to Cg.

 

[pascal]

Thanks for the link artisan7.

Some food for thought.

 

[LittlePenny]

Well I agree on using floats for all pipeline calculations, but I still think having ints would make uses of non-mathematical instructions all that easy.

But now that I think about it, I don't see why there isn't a goto. How else would they do if statements in ASM?

 

[Fred]

At least the discussion is based on the technical merit of the language perse, and not some gross misunderstanding of the underlying concepts/endless rehashing about the politics.

As far as pointers go. I find it kinda ironic that a C programmer would throw dispersions about that, considering the nature of array's in C.

But regardless, off the top of my head, I don't know many apps where you couldn't use an array instead of a pointer.

Pointers are of course more elegant and produce vastly simpler to read data structures...

But to be honest, I don't think that the nature of shader programs really will necessitate that sophisticated of a data structure, where the difference really would become a nuissance. Correct me if im wrong on that point, I have never seen say a very long Renderman shader.

There's also additional considerations about the overhead for the compiler, and the debugging issues for developers within the microcode..

 

[Dio]

But now that I think about it, I don't see why there isn't a goto. How else would they do if statements in ASM?

It's very difficult to do goto on a vector-type processor (i.e. a GPU). The problem you get is that instead of being able to process 2 or 4 or 8 or however many pixels at once, you can't do them simultaneously because every pixel might need to take a different path through the program.

There's already hoops that have to be jumped through in hardware just to handle the addressing operator in the DX8 vertex shader. Potentially, every vertex currently being processed might have a completely difference source operand - that's a big problem if the number of ports on your register file SRAM is exactly the same as the 'typical' instruction consumption.

Just adding the idea that results might come out in a different order to how they went in (which is implicit if you have goto, unless you wish to stall) is a bad enough problem.

Initially, goto's and IF's will be handled by the use of conditional operator instructions (c.f. cmov on the Pentium 4). Some simple variants of these are already in DX8.

 

[LittlePenny]

Thanks Dio.

 

[KimB]

I would imagine it could be handled by having a decent-sized post-transform cache in conjunction with hardware that recognizes when a primitive is fully-transformed.

As long as the result of one vertex's program isn't dependent upon any other, there should be no parralelism problems. It just would require lots of cache to work right...