Some questions around new Optix 8.0 and possible DLSS3 support (and new DLSS3G frame gen (StreamLine))

[Oscar Barenys]

Hi,
seeing new 0.6 release notes, two Optix related questions come to mind before even trying to build:
*I see "Fixes for building with OptiX 7.7" is building with new Optix 8.0 SDK supported?
*support for Optix 8.0 new Ada SER feature.. should provide some speedups on Ada GPUs.. question is if adding SER support would require adding an Anari extension to expose that or not?

also thinking about speedups,
curious what about supporting DLSS3 and new DLSS3 frame generation support on VISRTX?
seems at least DLSS3G (FG) would require Streamline integration..
similar question to SER would require some new ANARI extension to expose..
at least for DLSS3 side would be nice if a crossvendor ext is done so vendors can expose AMD FSR2, DLSS3, Intel XeSS in their respective implementations..

thanks..

[Jefferson Amstutz]

These are great questions! Hopefully I can shine some light on these things:

FWIW, the v0.6.0 release was mostly to sync up with the latest ANARI SDK release and start following it's branching scheme to reduce confusion as to which branches in VisRTX matched up with which branch of the ANARI SDK. Future releases will hopefully bring more exciting things! 😃

VisRTX primary serves the scientific visualization community, where there is intentional compatibility with older releases of CUDA/OptiX -- I just tried building with OptiX 8 and didn't have any issues, so that seems to work fine.

The goal for a while was to use Vis[RTX/GL] as a proving ground for ANARI's API development to make sure that we didn't make obvious mistakes when accelerating ANARI implementations with GPUs. Now that the v1.0 specification is "done" (still in the ratification pipeline), VisRTX can focus more on actual features and performance improvements, where you named a few interesting ideas. SER and DLSS both don't require any special ANARI extensions to be implemented because ANARI doesn't prescribe rendering mechanics (i.e. shader programs) -- SER in particular would be completely transparent to the application using VisRTX because it doesn't have an ANARI API additions, rather it would just be faster on Ada GPUs. I personally haven't spent time on that just yet, but I intend to fairly soon as it's an exciting technology!

As for DLSS, I don't see any particular need to add any ANARI extensions to support it other than perhaps having a parameter on the ANARIRenderer to turn it on/off. Similar to SER, DLSS lets the implementation internally render to smaller buffers than the final display resolution, so I envision it would be implemented as an option on VisRTX's renderers, but not really needing anything else on the user side. This is already how the OptiX denoiser is implemented in VisRTX, so it seems like a natural way to implement DLSS.

All of that said, when would those be available? That is less clear, as VisRTX isn't anyone's full-time attention right now. I would also want to implement DLSS via Streamline, which brings in additional dependencies -- I would probably keep that an optional component in the build as a subset of users (mostly in scivis) would prefer a simpler build/deployment over having bleeding edge features. Time will tell, as the things you mention make a lot of sense, it's just a matter of priority.

Thanks for the questions, I hope this helps! I'll close this for now, but feel free to keep the discussion going in this thread.