Farcry is low efficiency because of Cg Compiler

engall

Newcomer
Is it true that Farcry demo is low efficiency because of Cg Compiler?
Do you remember Tomb Rider AOD with Cg?
If you forget ,check here.
http://www.beyond3d.com/forum/viewtopic.php?t=7422&highlight=tomb

Cg really harms the performance of ATi cards .
I found out Farcry was compiled though Cg Compiler.
Is that possible when you use HLSL ,the performance of ATi cards will improve considerably?
And What about Farcry final Version ?
 
Because do you see NVIDIA cards using Cg at all? They use PS1.1, at least in the demo.
 
The Farcry Demo use

58 PS 2.X and 246 PS 1.1 on >= NV35. Not sure about < NV35

108 PS 2.0 and 244 PS 1.1 on R3XX

All 2.0 and 2.X shader are compiled with the MS HLSL compiler and not Cg. You can see it if you check the shadercode.

Not sure about the PS 1.1 Code because there are not much difference betwenn code that is compiled with the cg compiler and the MS HLSL compiler.

I know this numbers because I have written a little bechmark that test the speed of each single shader in farcry (and other apps).
 
Demirug said:
The Farcry Demo use

58 PS 2.X and 246 PS 1.1 on >= NV35. Not sure about < NV35

108 PS 2.0 and 244 PS 1.1 on R3XX

All 2.0 and 2.X shader are compiled with the MS HLSL compiler and not Cg. You can see it if you check the shadercode.

Not sure about the PS 1.1 Code because there are not much difference betwenn code that is compiled with the cg compiler and the MS HLSL compiler.

I know this numbers because I have written a little bechmark that test the speed of each single shader in farcry (and other apps).
Shockingly impressive, thank you! :oops:
 
Doomtrooper said:
You going to make that app public :?: :D

There was a german public release version of the app. Because of the low interest I have quit working on it. Maybe they use of the .Net 1.1 framework and Managed DX was the reason.
 
digitalwanderer said:
Demirug said:
The Farcry Demo use

58 PS 2.X and 246 PS 1.1 on >= NV35. Not sure about < NV35

108 PS 2.0 and 244 PS 1.1 on R3XX

All 2.0 and 2.X shader are compiled with the MS HLSL compiler and not Cg. You can see it if you check the shadercode.

Not sure about the PS 1.1 Code because there are not much difference betwenn code that is compiled with the cg compiler and the MS HLSL compiler.

I know this numbers because I have written a little bechmark that test the speed of each single shader in farcry (and other apps).
Shockingly impressive, thank you! :oops:

IMHO Halo use a more impressive number of shaders.

394 PS 1.1
272 PS 1.4
272 PS 2.0

Same for all DX9 chips.
 
Demirug said:
IMHO Halo use a more impressive number of shaders.

394 PS 1.1
272 PS 1.4
272 PS 2.0

Same for all DX9 chips.
I was just impressed that you figured out how many of each type there were.
 
digitalwanderer said:
I was just impressed that you figured out how many of each type there were.

That was easy. A friend of me using a DX-Wrapper (3d analyze) that write all shaders to a file. A second programm scan this file and convert all pixelshader to a configfile for my shader benchmark app. During this work it count the number of shader of each type.

The big problem with this is that you do not get the Texturestage setups. Because of this i do not have config files for UT2004 (only 1 PS 1.4) and X2 (no pixelshader at all).
 
hey, speaking of Halo with 3DAnalyze, how the hell do you get it to work and not cause a CreateProcess error on startup?
 
Demirug said:
The Farcry Demo use

58 PS 2.X and 246 PS 1.1 on >= NV35. Not sure about < NV35

108 PS 2.0 and 244 PS 1.1 on R3XX

All 2.0 and 2.X shader are compiled with the MS HLSL compiler and not Cg. You can see it if you check the shadercode.

Not sure about the PS 1.1 Code because there are not much difference betwenn code that is compiled with the cg compiler and the MS HLSL compiler.

I know this numbers because I have written a little bechmark that test the speed of each single shader in farcry (and other apps).

Are you sure that these numbers are meaningful ?

I mean shaders are sent to the GPU when they are used and I presume that this is done per object. If you use different walking way when capturing shaders you'll introduce a difference in the captured shaders file.

Moreover the same shader is sent more than once.

So I think that you should try to use the same walking way to capture the shaders and you shouldn't count the shaders but uniquely the different ones.
 
There is probably only 1/2 the number of shaders if we remove the shaders generated by static branching IE 1 shader for including details maps and 1 shader for no detail maps for the same effect.
 
Back
Top