🔒 Locked

Cg for ATI cards?

Started by Sander Apr 23, 2003 at 3:43 AM 20 replies 3.2k views

Original Post

Apr 23, 2003 at 3:43 AM

I want to buy a new video card and I think it''s going to be an ATI Raedon 9700 Pro. But will shaders created in Cg work on this card? And if I do program a shader in Cg on my system, do I need to make another one to run on Nvidia cards? How do the shader, the app and the different GPU''s (ATI and Nvidia) work together? I want to know this sort of things before I spend 400 Euro''s on a new card. Thanks in advance! Sander Maréchal [Lone Wolves GD][RoboBlast][Articles][GD Emporium][Webdesign][E-mail]

MrScruff

Apr 23, 2003 at 3:54 AM

From the cgshaders.org website

Was Cg designed for NVIDIA chips only?

No. Cg was designed to simplify graphics programming, regardless of the hardware that it runs on. Cg allows graphics chip manufacturers to easily and effectively expose the capabilities of their hardware by writing their own Cg compilers. These manufacturers have a unique understanding of their products, and are therefore the most capable compiler writers for their particular hardware. Programs compiled with Cg run today on DirectX 8-compatible hardware, and on any other vendor''s implementation of OpenGL, if it supports the NV_vertex_program extension (ARB_vertex_program support is coming soon, since it was only recently approved by the ARB).

Sander

Apr 23, 2003 at 4:28 AM

Okay I understand this. But can I use the compiler in the Cg SDK to compile the shaders? Or do I need to get a Cg compiler from ATI (they don''t have one on their site).

And do I need to compile the shaders twice (one for Nvidia cards and once for ATI cards) and include the one I need at runtime? Or will one compiled shader do for both chipsets?

Sander Maréchal
[Lone Wolves GD][RoboBlast][Articles][GD Emporium][Webdesign][E-mail]

assen

Apr 23, 2003 at 4:35 AM

quote:
Original post by smarechal
Okay I understand this. But can I use the compiler in the Cg SDK to compile the shaders?

The Cg compiler from Nvidia can compile the shaders to the DX8/DX9 shader assembly languages, and you can load and run those on an ATI card.

You can also use HLSL from DX9''s FX framework, which is quite similar to Cg. Either way, you''ll be allright with your ATI card.

davepermen

Apr 23, 2003 at 5:04 AM

why ever you care that much about cg.. but yes, it runs on ati cards, and no, you don''t need another compiler. just compile down to ARB_vertex_program and ARB_fragment_program profiles if you use opengl, or vertex_shader_2_0 and pixel_shader_2_0 if you use dx. you can run them then.

"take a look around" - limp bizkit
www.google.com

IronPeter

Apr 23, 2003 at 5:16 AM

Cg works fine on Radeon 9700. The only issue was .xyzx swizzle bug in the arb_fp profile:

TEX R0, fragment.texcoord[0].xyzx, texture[0], 2D;

R300 supports this swizzle very bad (many ALU cycles and + level of indirection in that case).

This bug was fixed in the Cg ToolKit 1.1.

assen

Apr 23, 2003 at 5:38 AM

quote:
Original post by davepermen
why ever you care that much about cg..

Because you''re more productive in a higher-level, domain specific language, than in assembly, that''s why. No matter how l33t you are at h4x0ring assembly.

Sander

Apr 23, 2003 at 5:41 AM

Thanks everybody. I finally got it

One last question (for davepermen actually): What''s so bad about Cg? It sounds to me you don''t like it very much. (I''m in OpenGL by the way so I guess HLSL isn''t going to do me any good)

Sander Maréchal
[Lone Wolves GD][RoboBlast][Articles][GD Emporium][Webdesign][E-mail]

davepermen

Apr 23, 2003 at 9:37 AM

just haven''t found any real use for it till now. cg does not help much in coding high level shaders. cg is much too low level for that. i see noo difference in writing float diffuse = dot(to_light,normal); or dp3 diffuse,to_light,normal; (wich is the way opengl asm allows me to code.. hehe. )

cg is an nvidia marketing hype, wich did not worked over a long long time. starts to get working now, but still i don''t see much use.

if it would be highlevel, it would be lightshaders, materialshaders, and deformationshaders. not vertex and pixelshaders. they remain low level.

cg was created to make the nvidia versions of vertexshaders useable. they are on their own about unusable. no variable names, complicated syntax.

cg doesn''t help artists much. they want to set up materials, lights. they don''t want to fuzz about vertex and pixelshaders.

and for me, as programmer, choise of language doesn''t mather really. both have the same features. variables and functions/instructions.

i don''t think i''m 1337 because i don''t use cg. i know of tons that feel 1337 because they integrated cg and still have nothing more to show up.

oh well.. and the great cg-enabling cards, called CineFX.. well. nobody has to talk about nvidias hair dryer..

"take a look around" - limp bizkit
www.google.com

assen

Apr 23, 2003 at 10:40 AM

I agree, the semantics remains low-level, but the higher-level syntax is very convenient for experimentation. dot is an extreme example, try a simpler sequence of arithmetics and see what's more readable.

Shader fragment:

quote:

float3 eyevec3 = IN.position.xyz - campos3.xyz;
eyevec3 = normalize(eyevec3);
eyevec3.xz *= 0.3 / eyevec3.y;
OUT.tex1.xy = 0.125 * (IN.position.xz - eyevec3.xz);

versus (roughly equivalent piece of code, pulled out of the compiler output for the above shader)

quote:

add r0.yzw, v7.xxyz, -c12.xxyz
dp3 r0.x, r0.yzw, r0.yzw
rsq r0.x, r0.x
mul r1.xyz, r0.x, r0.yzw
rcp r0.x, r1.y
mul r0.x, c13.z, r0.x
mul r0.xyw, r1.xz, r0.x
mov r1.xz, r0.xyyw
add r0.xy, v7.xz, -r1.xz
mul oT1.xy, c14.xy, r0.xy

And this:

quote:

and for me, as programmer, choise of language doesn't mather really. both have the same features. variables and functions/instructions.

is simply absurd. Would you program a Turing machine because it's functionally equivalent?

[edited by - assen on April 23, 2003 11:43:37 AM]

davepermen

Apr 23, 2003 at 10:55 AM

cg doesn''t bring much to a higher level, espencially if you code for lower end profiles.
btw, i always talk about pixelshading expiriences.

there, its actually only a one-to-one function mapping to the original ps1.1-ps1.3 assembler instructions and you have to remember the order as well, as you had back in the days. or call it a one-to-one-mapping to the texture_shaders and register_combiners.

there, higher level is useless.

for ps2.0 and vs2.0, yep, its quite neat. still.. pixelshaders with about 60 instructions don''t yet NEED cg.

and i see no point in coding for gfFX cards, so i don''t have the need to code for more than 60 or so instructions, and i have no need to use the really crappy asm of nvidia presented, wich does not have variables and all..

sure, if cg is an enhancement, it is useful. but most the time its a one-to-one-mapping of assembler instructions. and _THEN_ it is not useful.

does it mather if i say

float diffuse = dot(to_light,normal);

or

let diffuse = to_light dot normal

or

dp3 diffuse,to_light,normal

or, dunno..

diffuse = to_light.normal

it doesn''t really. thats syntax that differs, but not usability.

cg doesn''t higher levelize (hehe, funny word) much. much too less to be really worth the effort.

"take a look around" - limp bizkit
www.google.com

davepermen

Apr 23, 2003 at 11:02 AM

quote:

float3 eyevec3 = IN.position.xyz - campos3.xyz;
eyevec3 = normalize(eyevec3);
eyevec3.xz *= 0.3 / eyevec3.y;
OUT.tex1.xy = 0.125 * (IN.position.xz - eyevec3.xz);

quote:

add r0.yzw, v7.xxyz, -c12.xxyz
dp3 r0.x, r0.yzw, r0.yzw
rsq r0.x, r0.x
mul r1.xyz, r0.x, r0.yzw
rcp r0.x, r1.y
mul r0.x, c13.z, r0.x
mul r0.xyw, r1.xz, r0.x
mov r1.xz, r0.xyyw
add r0.xy, v7.xz, -r1.xz
mul oT1.xy, c14.xy, r0.xy

how about:

  
sub eyevec,IN.position,campos;
;normalize
dp3 eyevec.w,eyevec,eyevec;
rsq eyevec.w,eyevec.w;
mul eyevec,eyevec,eyevec.w;

inv temp.y,eyevec.y; fuck i forgot how the x = 1/x func is named!
mul eyevec.xz,0.3;
mul eyevec.xz,temp.y;

sub temp,IN.position.xz,eyevec.xz;
mul OUT.tex1.xy,temp.xz,0.125;

sure, its longer than the asm output above. sure, its less readable than cg. but actually i even don''t know in the cg code what you actually archive with it. and for example the normalization is simple to read in both cases, and the variable names remain.

dunno if i made some errors. haven''t touched pixelshaders for a longer time anyways, other stuff to do.

"take a look around" - limp bizkit
www.google.com

davepermen

Apr 23, 2003 at 11:03 AM

hm. my code is actually shorter.. oops. does my code work? (except for the inv that should be called rcp..:D)

"take a look around" - limp bizkit
www.google.com

Sander

Apr 23, 2003 at 11:30 AM

Hehehe, I didnt want to start a flamewar here

Anyway, I have no experience whatsoever with ASM. Say Davepermen is right and it''s just a syntax difference. Then I''m better off with a syntax I know (That''s C) so Cg is easier for me to learn.

And if davepermen is wrong (and Cg truly is a higher level language), then in the future i''m better using Cg and I will be even better of learning it right now.

Thanks for clearing everything up guys

Sander Maréchal
[Lone Wolves GD][RoboBlast][Articles][GD Emporium][Webdesign][E-mail]

assen

Apr 23, 2003 at 11:43 AM

quote:
Original post by davepermen
btw, i always talk about pixelshading expiriences.

Ahhh... ok, that''s where it is. I always talk about vertex shaders. We use standard TSS for the pixel level.

Pixel shaders prior to 2.0 are an abomination - they are supposedly a general computing model EXCEPT that you have to remember that it only works if you do this and this. And after you wrap it in Cg, it doesn''t get prettier.

Vertex shaders, on the other hand, are much more general even at DX8 level (pre-vs_20), and you can write almost everything in Cg and the compiler somehow does it.

It''s quite possible that your code is shorter, and therefore faster. The compiler is far from perfect. The point is that Cg is easier to tweak, try new things etc.

Coding for DX9-level cards will (I _really_ hope) become relevant, with the dirt-cheap 5200s.

ArnoAtWork

Apr 23, 2003 at 12:19 PM

I have installed the Cg SDK from NVidia web site and the shaders only modifying vertex are really slow. As I have a GeForce2, vertex shaders run with no problem. But why CG is so slow? Does Cg requires GeForce3 even for vertex operations?

davepermen

Apr 23, 2003 at 12:49 PM

quote:
Original post by assen
Ahhh... ok, that''s where it is. I always talk about vertex shaders. We use standard TSS for the pixel level.

heh okay..

quote:

Pixel shaders prior to 2.0 are an abomination - they are supposedly a general computing model EXCEPT that you have to remember that it only works if you do this and this. And after you wrap it in Cg, it doesn''t get prettier.

exactly.

quote:

Vertex shaders, on the other hand, are much more general even at DX8 level (pre-vs_20), and you can write almost everything in Cg and the compiler somehow does it.

as i said. no use for vertexshaders here.. so i never need more than about 4 dp4 and 3 dp3 and some mov anyways:D

quote:

It''s quite possible that your code is shorter, and therefore faster. The compiler is far from perfect. The point is that Cg is easier to tweak, try new things etc.

that was just actually a joke. never planned to beat the compiler:D funny i''ve done it anyways somehow:D

sure, for tweaking its great..

quote:

Coding for DX9-level cards will (I _really_ hope) become relevant, with the dirt-cheap 5200s.

OUCH!!! you know that the 5200 cannot run any pixelshaders fast enough for realtime?!?! at least no dx9 pixelshaders. that card SUCKS! bether get a radeon9600pro. that does not need powersupply, that does not need cooling except a tiny fan, that can get overclocked to sometimes near 9700 performance, that is small, that is not 140° hot in the computer, and runs pixelshaders and vertexshaders much much faster.

please don''t get any gfFX card, not any nv30 based chip. they are such a crap.

don''t you read hw tests?

please don''t do that failure, or you will never believe into nvidia again.........

"take a look around" - limp bizkit
www.google.com

sjelkjd

Apr 23, 2003 at 4:05 PM

Quite frankly, any claims that writing shaders in assembly is "easy enough" are complete crap.

Just try going back to a shader you have and modify it. It takes way too long and is way too annoying.

the Speed Bump

Apr 23, 2003 at 4:24 PM

Cg works just fine on the 9700 pro. (it's sweet! :D)

edit : It won't work on the 8500 until ATI implements the proper GL extensions, though. That's probably the biggest (only?) downside to Cg.

I'm hip because I say "M$" instead of "MS".

[edited by - the speed bump on April 23, 2003 5:26:18 PM]

masonium

Apr 24, 2003 at 1:52 AM

well, asm can be annoying to alter, but if you comment it well, then it''s actually not so bad. I admit, when i wrote my first HLSL code, it was actually pretty intuitive and easy to write. I wouldn''t say it was easier to write than my first ASM shader, but i understood the code more after looking at it with HLSL.
Just my incoherent 2 cents;

''There''s something out there....something stupid...''
''I think I''m going to be ill. Is that a problem for you?''
''[You] overestimate my conscience by assuming that I have one.''
- Daria

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.