Compile Time Optimizations

I am hoping some gurus here can help me (and others) by sharing some of their knowledge about reducing shader compile time in ReShade.

I have been working on a customizeable crosshair shader for the last few days, but the first time I test it in a new game, the compile time ranges from tens of seconds to a few minutes. I've tried to optimize runtime performance in several places, by adding checks before heavier calculations, but compile time has just been growing. Not even using #pragma reshade skipoptimization helps. By commenting out parts and retesting the compile time, I've figured out that reducing the number of DrawShape calls, regardless of runtime checks to prevent unnecessary work, seem to drastically reduce compile time.

I'm still testing things. and will probably solve it somehow eventually, but I wanted to ask here for some knowledge either general or specific, on optimizing shader compile times. Any of you figure out tricks or observations from your own shaders? Or general advise to reduce/prevent this issue?

I am hoping this can be more general advise, to help more than just myself, but if you want to talk specifics (or poke fun at my mistakes), here's a link to my work-in-progress crosshair shader .

I was able to improve things somewhat. Mostly inlining nested functions, skipping mipmap sampling by using tex2dlod instead of tex2d, and unrolling loops where possible.

First run compile time is still far from desirable, but these changes have cut the time roughly in half without any loss in functionality. Now apps with light weight cpu load first-start in 8-10 seconds. With heavy cpu load apps, things take 1 - 1.5 minutes. This is roughly half the time from testing before optimizations.

Still commenting out half the DrawShape calls drops compile time to ~ 1/3rd of this. It may be more efficient to split the technique into multiple files drawing few shapes. Perhaps a trick abusing texture pooling (shared memory) will let me consolidate most of the techniques as long as their load order is stacked consecutively. However, that might make things difficult or easily misunderstood for users.

Alright, with some advise from a few helpful folks on discord, I was able to make more progress.

Basically, gpus are really good at math, and really bad at flow control. As such, you want to use as little flow control as possible. It's better to have some really complex math than to break things into a bunch of simpler problems with a ton of flow control around each.

As an potential hack, if you're only going to run a technique once and cache the results, you can hide some functionality inside an iterator over an empty array that gets incremented in runtime. This lets you bypass the compiler. Of course this means it will bring the GPU to a crawl when it runs, but if it's only running a single pass, that might be acceptable.