Optix 7 breaking changes

Hi @bagey2002,

I understand and I’m sorry you feel that way right now. Please let us help you through this. Since the extent of the change is new to you today, I understand the feeling of surprise, and many people have felt the same as you initially. We do understand it’s a big change for you. We did not want to break the API. We would not have done it this way unless we thought it was absolutely the right thing to do going forward.

As far as being respectful, please understand that some of our partners and many people here on the forum were quite unhappy with the limitations of OptiX <= 6, especially in heavier production scenarios and/or multi-frame & real-time update scenarios. It would be equally fair to say that failing to fix the OptiX API the way OptiX 7 does would have been disrespectful to everyone, and eventually would have lead to OptiX becoming obsolete. Instead, I’m pleased to report that 100% of the people we’ve heard from who took the time to port their code to OptiX 7 have expressed no regrets, everyone so far is unanimously happier with the improvements and increased control… after they’ve finished porting. The new API is in many cases making their applications faster, more flexible, and easier to debug, profile, and develop. The new API gives you complete control over your own GPU memory allocation and data transfers - something that is missing in OptiX 6. The new API has completely transparent interop with CUDA and allows far easier control over parallel and asychronous execution.

To help you communicate with your management, here are a few ideas:

  • We’re not forcing anyone to move to OptiX 7. If you don’t need any of the features in OptiX 7, you can continue to use OptiX 6 - it will be supported in the driver for quite some time.
  • If you are combining raster techniques with ray tracing techniques, and you already use DXR or VKR, then consolidating into one of those might be a better choice for you.
  • If you are only using ray tracing, OptiX is reported to be easier to develop with than either DXR or VKR, so ignoring the cost of porting from OptiX 6 to 7, I believe there is some continuous development savings to using OptiX.
  • If you do decide to move to DXR, that will be a considerably larger refactor than porting to OptiX 7. It would make sense if your team has DXR expertise, and in that situation might be easier. I speculate that without DXR or VKR experience, moving to one of those will be much more frustrating and expensive than porting to OptiX 7.
  • If you depend on motion blur or multi-level instancing, then OptiX is the only API choice that exists - no other API currently offers those features.
  • If you use CUDA for any other portion of your compute or render pipeline, or if you want to in the future, it’s easier to combine CUDA with OptiX than with either DXR or VKR. And you get a unified workflow - the OptiX profiling and debugging tools are the CUDA profiling and debugging tools.
  • If you decide to move to OptiX 7, you will have opportunities to improve the performance of your renderer. Many users were able to speed their renderers up by double-digit percentages just by having control over memory allocation and data transfers. You may also be able to reduce memory usage, if that is a guiding concern in your case.
  • In short, we believe the effort to port to OptiX 7 is likely to be a worthwhile investment. If you aren’t convinced yet or would like a deeper analysis, we are happy to discuss the details of your pipeline and OptiX usage here or via the mailing list if it needs to be confidential.

We have prepared some material to help you transition from 6 to 7, for example:
https://developer.nvidia.com/blog/how-to-get-started-with-optix-7/
https://gitlab.com/ingowald/optix7course
https://github.com/NVIDIA/OptiX_Apps

In addition to those, there are several matching code samples in both versions of the OptiX SDK that you can compare side-by-side in order to understand their differences. The optixPathTracer sample, for example, is a good one to study to see how it was migrated from OptiX 6 to OptiX 7.

For what it’s worth, I think we tried pretty hard to communicate that OptiX 7 is a completely backward incompatible API, and exactly why. I mentioned it in the OptiX 7.0 Release announcement. We’ve talked about the technical details of how this complete overhaul improves the API, makes it better, and will keep it more stable into the future at GTC, and Siggraph, and on the forum, and in the OptiX release notes, and in the Programming Guide, and on the dev blog.

While OptiX 6 is still supported for as long as we have people that depend on it, that branch of the API cannot get the same new feature development as the OptiX 7 branch, because they are different APIs. That said, the most stable and long term path into the future is on the OptiX 7 API. I do not believe it is likely to break the same way ever again for many reasons: because OptiX 7 uses CUDA memory natively, because OptiX 7 is much lower level than OptiX 6, and because OptiX 7 is now more structurally similar to DXR and VKR.

I hope that helps, and please let us know how else we can help or if you need more ammunition for your management.


David.

1 Like