Dear Optix developers;
I have just picked up what a big change Optix 7 is over 6.
Firstly this amount of change is disrepectful to users of Optix and expensive to companies who have to maintain products . Are you going to be devolping in parallel Optix 6 and 7 or is the old API now dead. I dont understand why you have not supplied any bridge between the two APIs. If we have to make changes to move to Optix 7, how can suggest to my management we should not use another library / interface like DirectX which is likley to be more stable.
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.
Yes I was a bit over colourful with my language I am sorry about.
Thanks for long reply.
I need to understand changes better.
I like the idea of control over buffers and am sure I can first off recreate a context like object that can mimic in cuda the current create routines.
I didn’t understand the SBT table stuff.
The original optix was a simple but powerful library.
I did think that optix prime was going to be the vehicle for more control. And the two could coexist and you could migrate if you needed more control.
All this said it will still cause some stir at my group that a major rewrite is going to be needed in the medium term.
Thanks again.
Make sure to take a good look at the optixRaycasting sample in the OptiX 7 SDK. It’s the closest replacement we have to OptiX Prime. This approach might simplify things compared to the idea of trying to use OptiX 6 and OptiX Prime together, and as a bonus (unlike with OptiX Prime) you get all the RTX hardware acceleration and no limits on what you can do: if you want to compute some derived attributes rather than storing your hit position, you can. If you want to do some kind of shading, you can. If you wanted to trace a buffer of indirect rays starting from the camera, you can do that without needing to trace the primary rays in a separate pass.
The Shader Binding Table can be a little confusing at first. At a high level, the concept is simply an array of shaders that OptiX uses to know which shader to call. For example, when a surface is intersected, which closest hit shader gets called? The SBT is a lookup table that matches shaders to the geometry. The trick is just understanding how the indexing works, so that the right shader gets called.
The SBT exists inside of OptiX 6 as well, it has just been exposed in OptiX 7. One big reason for that is because OptiX 6 can’t always know how it needs to update the SBT when you make changes to the scene, so often it has to update the whole thing. But you know exactly what needs updating, so in OptiX 7, you can make better decisions - you can much more easily pinpoint a small memory block to transfer instead of the entire table, or you can organize your SBT in advance so that it doesn’t even need updates.
Here are a couple of extra things that might help:
I completely forgot to mention Ingo Wald’s wrapper library, it’s intended to make porting OptiX 6 code over to OptiX 7 a little easier… this will handle some of the SBT work for you, if that’s what you want: https://github.com/owl-project/owl
Here’s an external blog post that compares shader binding tables in OptiX 7 to DXR and VKR: https://www.willusher.io/graphics/2019/11/20/the-sbt-three-ways
–
David.