Fragment program perfs

[SeskaPeel]

I think this will sound stupid ... but I have to ask.

Running a simple fragment program (4 instructions, 2 TEX, 1 ADD & 1 MAD) renders smoothly.
Running a bit longer prog makes drastically frame rate fall (4 MAD are added).

Does this makes sense ? I intend to render all the scene with the second fragment program, at 1600 * 1200. Of course, lowering resolution to 1024*768 makes it all smooth.

What are the common way to improve this ? Render front to back would make it ?

[davepermen]

could be vsync wich kicks you from 120 to 60 or 60 to 30fps.. dunno.. and it is just at the limit..

what gpu..?

[Humus]

It is perfectly normal for performance to go down significantly when you add instructions. Performance scales very well against instruction count. You doubled the number of instructions, so performance should roughly be halved. Also, on some hardware texture sampling and ALU instructions may work in parallel, so you may even see a larger performance decrease as you're going from 2 ALU instructions to 6.

[SeskaPeel]

video is GeForce FX 5200
Vsync was active, but it was rather goinr from 40 fps down to 20.

What does ALU means ?

[zeckensack]

ALU is a term from the processor world and means "Arithmetic and Logic Unit".
In conjunction with shading hardware, ALU refers to the circuitry carrying out the computations (as opposed to texture samplers). Eg ADD/SUB/MUL/MAD are ALU instructions, TEX is a texture sampling instruction.

[SeskaPeel]

This is frightening ...
I'll have to limit my fragment programs to about 5 instructions in order to run smoothly ?

[AdrianD]

Originally posted by SeskaPeel:
This is frightening ...
I'll have to limit my fragment programs to about 5 instructions in order to run smoothly ?

no! you have just to buy a faster graphics card (ie.ATI9700) )

[CatAtWork]

Well, the jump in resolution to 1600x1200 means many more instructions are executed.

I've never used an FX-class card, but I guess that if you don't have good front-to-back ordering, you're also incurring a pretty heavy penalty for executed-but-not-visible fragment shaders.

I'm not an authority on all of these new Z-buffer optimizations, that discard fragments early. Someone else might have some tips.

[davepermen]

you have the cheapest existing fragment processor supporting card on the world, and ask why it cannot run smooth at a higher resolution than most normal users at home ever will use?

this card is not thought for that huge res. just stick to 1024x768 and be happy if your programs run smooth there!

the 5900 is made for such situations, or the radeon9800 works well at that res, too..

you're essencially processing 2 million fragments per frame at your resolution! what do you expect from that cheap card?

[MZ]

I assume you are using ARB_FP, so all calculations are performed at full precision.

(250 MHz * 2 fp32 pipelines) / (1200 * 1600 * 7 fp32 instructions) == 37 fps.

This is theoretical estimation of maximum you can get, assuming ideal conditions (zero overdraw, 100% efficiency of other parts of GPU, etc.), so in real life, and with vsync on, the 20 fps seems not surprising...

Do you absolutely need full precision in your program? If not, try NV_FP version, and use the "fixed" precision. I estimate (still theoretically) in best case you could get 233% performance increase by this (I'm basing on tests done by thepkrl guy @Beyond3D)