The best implementation I can come up with would be the put all my viewpoints in a buffer in the launch parameters and then use the depth parameter in OptixLaunch to tell my raygen program which viewpoint to use and where to write the result in the output buffer.
Yes, you effectively do a 3D launch with the width * height * number_of_viewpoints and render all of them at once.
That is perfectly fine, if the launch size is not exceeding the maximum supported size which is roughly 2^30 launch indices overall.
CUDA native launches can be bigger and are queried with these CUDA device properties.
Depending on the target system you’d also need to be careful to not run kernels for too long. Windows OS since Vista have a 2 second limit for the Timeout Detection and Recovery (TDR) mechanism in WDDM(2). Make sure you’re staying under that threshold per launch on older boards.
This does not affect the NVIDIA TCC driver mode, that is when dedicating boards for compute tasks.
How small are your “low resolutions”?
There is a minimum amount of threads per launch required to saturate different GPUs (depends on what GPU you’re using).
Anything below 256x256 is most likely too small on high-end boards.
OptiX 7 launches are asynchronous. So if you’re above that thread amount you should be able to submit multiple asynchronous launches and get the GPU busy enough.
That requires some careful asynchronous updating of the launch parameters though. I hinted at that in my example programs.
If you’re getting the resulting data back, maybe there is too much device-to-host transfer happening between launches?
To see how the overall application performs, including what is happening between optixLaunch calls, you could profile that application behaviour with Nsight Systems.
For the kernel launches itself you can profile the kernel with Nsight Compute and see what the main bottlenecks are, that’s normally memory accesses. (Compile your input PTX code with line-info.)
More information here: https://developer.nvidia.com/tools-overview