Revving Up Shader Performance.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * * Other things it can’t really know are control flow, constant waterfalling, cache misses, fetch strides, bandwidth, mip levels, etc. * * * * * * * * * * Thread Size and Branching 54% 20% 26% 43% of pixel threads take the non-lighting path 14% of pixel threads take the lighting path 43% of pixel threads take the soft shadow path Texture Cache Usage Fetches have latency that become a bottleneck Can be a challenge to fetch 6–10 textures per pixel and many MB of texture traffic through a 32 KB cache Age-old recommendations still apply Compare measured texture traffic to ideal traffic Consider a 1280x720x32-bit post-processing pass 1280x720x32 bits = 3.686 MB of ideal texture traffic But measured result may claim 7.0+ MB Triangle rasterization can and will affect texture cache usage In the case above, it’s the only explanation Pixels are processed in an order that’s causing texels to be evicted/re-fetched to the cache Rasterization Test Use an MxN grid instead of a full-screen quad Smaller primitives confine rasterization to better match usage patterns of the texture cache Prevent premature evictions from the texture cache Ideal grid size varies for different conditions Number of textures, texel width, etc. And surely for different hardware, too Write a test that lets you try different grid configurations for each shader For the DepthOfField shader, an 8x1 grid works best For a different shader, 20x13 worked best In all cases, 1x1 seems to be pretty bad Conditional Processing The shader compiler doesn’t know when intermediate results might be zero Diffuse alpha, N·L, specular, bone weight, lightmap contribution, etc. Pixel is in shadow Some constant value is zero (or one) Try making expressions conditional when using these values Experiment to see if even small branches pay off Use a texture mask to mask off areas where expensive calculations can be avoided For PCF, take a few samples to see if you need to do more Multip