I’m trying to understand the effect of register allocation in OptiX ray-gen code.
My ray-gen code is something like this:
ray-gen(){
while(some condition){
optixTrace(); // uses 32 max registers in payload buffer
process() //very register heavy > 50 required registers
//only 2 state passes on to next optixTrace()
}
}
I’m particularly trying to undertstand this code here : link
My doubt is that would this process()'s register allocation affect GPU occupancy, leading to slower execution time. I was little confused with how OptiX compiles different shaders in SBT.
I’m not able to verify this as I don’t have access to NSight Compute in my cluster(restricted there :\ ). But i was working on identical code implemented with Vulkan where the code was consuming much more time than the one implemented with OptiX. So was curious how OptiX manages it register allocation across different methods in same ray-gen.
It would be great if someone could help me out here. Thank you.
Hi @meetbanthia, I strongly suggest profiling, otherwise the risk is to focus on a non-critical perf factor (it could be the algorithm, the compute:memory access ratio, divergence, and other factors).
Register allocation and occupancy are connected, yes, but not always in an obvious way (e.g. if the kernel is memory-bound then occupancy becomes more important yep, but if it’s compute-bound then less).
In general, a compiler uses heuristics (and these depend on the GPU model), which means there is no obvious solution to the register allocation problem.
I don’t know the internals of how the OptiX compiler allocates registers, and assuming it’s OK for us to share, that’s subject to change.
You could try different values for the register limit, and maybe you find an ‘optimal’ value. But then you will have to maintain that (so if the code changes, you’ll need another ‘optimal’ value), is this acceptable?
My colleagues might add insight, meanwhile have a look: