Sign in to follow this  
LTKeene

Exceeding pixel shader instruction limit?

Recommended Posts

Hello everyone, How do I know when I've exceeded my cards pixel shader instruction limit? The reason I ask is because I was doing some experimenting this morning trying to determine what happens when I exceed the max count and to my surprise my fx shader file kept on loading even when I'm pretty sure I was exceeding the limit. My pixel shader 3.0 program is computing the output color based on neighboring texture colors. The size of the neighborhood is usually 5x5 or 7x7, sometimes 11x11. the neighborhood operation is a loop that is actually performed 2 or 3 times in the shader. I checked the device caps and the "MaxPixelShader30InstructionSlots" property is 4096. When I load the effect file I use the following: Effect myEffect = Effect.FromFile(device, filePath, ShaderFlags.None, null, out errors); If I change the neighborhood size to something utterly crazy (that should exceed the instruction count, especially since the loop is performed a few times) like 100x100, the effect file still loads normally and there is nothing in the "errors" string. Does this indicate that it compiled? If so, how can this be? Thanks in advance!

Share this post


Link to post
Share on other sites
Quote:
How do I know when I've exceeded my cards pixel shader instruction limit?

The shader compiler will tell you. Just keep an eye on it.

Share this post


Link to post
Share on other sites
Thanks for the replies so far. The GPU is a GeForce GTS 250. Anyone know if this supports loops? It's not exactly ancient.

Also, my project is built in VS2008 to which I've added my .fx files. I'm learning on the old MDX 9 before I move over to SlimDX. I assume my shaders compiled when they are loaded via "Effect.FromFile"? The only way I've been able to tell if I'm running into trouble is by checking the "errors" string I'm passing to the "FromFile(...)" call. Is there another way to check compiler messages pertaining to my pixel shaders?

Thanks in advance folks, this graphics programming is a hoot!

Share this post


Link to post
Share on other sites
Yes, my card definitely supports branching. I have several conditional branches in my program. But for my experiment I commented everything out other than the two neighborhood loops, and just increased the size of the neighborhoods. I never seemed to hit the 4096 instructions limit, which is puzzling. If the GPU supports loops, does that mean the number of instructions within the loop body only count once and not each time they are executed?

Share this post


Link to post
Share on other sites
Quote:
Original post by LTKeene
Yes, my card definitely supports branching. I have several conditional branches in my program. But for my experiment I commented everything out other than the two neighborhood loops, and just increased the size of the neighborhoods. I never seemed to hit the 4096 instructions limit, which is puzzling. If the GPU supports loops, does that mean the number of instructions within the loop body only count once and not each time they are executed?


That's how it is on regular CPUs. I don't think GPUs are a lot different.
I believe the instruction limit is related to the size of memory available to hold instructions on each of the shading units.

A limit on how often instructions can be executed doesn't make much sense to me...

Also, your observations seem to support my theory.

You could try making a really really long shader program. But make sure all the instructions are useful, because otherwise the compiler may strip them. ;)

Share this post


Link to post
Share on other sites
Quote:
Original post by LTKeene
Yes, my card definitely supports branching. I have several conditional branches in my program.


I'm not an expert (not even close) and I may be wrong, but I think that there are two ways how the card can support branching (well, one of them means the card doesn't support branching in fact, but anyway).
When you try to use the IF - ELSE command with older cards, it will work ok, but the card will always execute all the instructions in both the branches and then lerp the results based on the IF condition. Which means you would not save any instructions or performance. FOR loops were similar - the compiler just "expanded" the instructions inside the FOR like if you typed them one after another - here you could run out of instruction limit easily.

Please correct me if I'm wrong ;)

[Edited by - Tom KQT on February 23, 2010 2:56:46 AM]

Share this post


Link to post
Share on other sites
The above is correct. Incidentally I hit a wall with one of my shaders today when it exceeded 64 instructions (it's an onboard Intel GMA 965 chipset). I was applying a shadowing and multiple lighting effect in the same technique/pass. It was within the instruction limit when it only processed one light, but after applying a loop with three lights, I got an error saying it exceeded the limit and shows exactly how many instructions it has.

It was just a bit over the limit too, as the shader compiled fine by just removing one line that multiplied a specular factor. It also cuts instructions that have no net effect (for example adding a float that has been muliplied by 0).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this