Optimizing HLSL code

How many passes do you typically make with this shader? Multiple passes can really eat up bandwidth, since the result has to be output to the backbuffer and blended. Most modern video cards will respond much better to doing many lights in a single shader pass...usually there's math to spare but bandwidth can get tight very quickly (ESPECIALLY on low and mid-end GPU's).

I would suggest trying things with a single-pass approach (if it's feasible to do so) and see what results you get. You wouldn't need to modify your shader very much...what you can do is you can have techniques for different amounts of lights and send a uniform int to the shaders that controls how many lights to loop through.

Also be careful with branches...you usually don't want to use them too much. I compiled your shader with fxc and it's not using dynamic branching, but you want to make sure that if you use a branch that ends up being compiled as DB that you're aware of it. DB can be tricky to get good performance out of, it relies on large groups (usually 8x8 squares) of pixels taking the same branch.

Oh and if all else fails...consider an early-z pass. At the very least it will make sure you're never wasting time shading invisible pixels.

Thanks for the quick reply!

I usually do one pass, since the eightpass algorithm is usually even slower. Currently I'm trying to get everything I can out of this shader before I try on anything more ambitious.

However, about the branching, I was wondering how I could get around that. Some of the branches are used to distinguish between say the type of light, directional, point, or spot, while others are used to free up unneccessary calculations. I removed those and compiled, but this didn't seem to impact the framerate at all.

I enabled an early Z-pass, and that gave me about five more frames per second, so thanks there.

Alright, well, I hope that answered you questions, and I hope you can give me a few more pointers towards optimizing.

Thank you!

Have you done any rigourous performance measurements? Do you know for sure which aspects of your renderer and rendering are slowing things down? Tools like NVPerfHUD can be exceptionally good at pointing you to the best places for optimization - rather than stab in the dark, use a torch [smile]

hth
Jack

Well what I was trying say before was that branching wasn't currently a problem, I was just recommending that you keep an eye on things if you add more branches. Sorry if I wasn't clear on that. [smile]

And yeah, jollyjeffers is right that to go forward from here you really need to narrow things down a bit. A good first step is figuring out whether you're CPU-bound or GPU-bound...if you're CPU-bound then no amount of shader optimization will help you out. You can do this by running your APP through PIX and recording a sequence of frames. The frame graph will show you whether the CPU is waiting for the GPU, or vice versa. NVPerfHUD goes even further than that, and will show you real-time statistics regarding how many DrawPrimitive calls you're making (an important number to keep track of!), how many tris/batch you're submitting, and how much time is spent in the driver per frame. It can also show you where you're bottlenecked by specific GPU components, like pixel shaders, bandwidth, framebuffer, etc. It's really a fantastic tool, as is PIX.

Alright, I'll try the tools out and see what happens. I'm going to be away from my computer for a while so I can't immediately test things out, unfortunately, but I should get around to it when I get back. Thank you.