We are developing a simulation using Optix which we would like to make as fast as possible. We understand that, up to now, using Optix with Nsight was not really possible. Using Optix 5.x, I was able to profile at the megakernel level, but not more fine grain than that. I’d really like to be able to profile individual kernels, since they can be relatively complex.
I recently installed Optix 6.0 and immediately realized a 6-8x performance improvement (really great!). But I was disappointed to see that support for Nsight profiling seems to not have been included in this release. I was particularly interested since this talk was given at SIGGRAPH last year:
I was excited to see this talk since it gave me hope that we could more effectively profile and debug our simulation using Nsight. Unfortunately, the speaker skips the most important part of the process: how to create the report.
Is there a currently available method to create a profiling report? Perhaps a compiler option? When I try to use Nsight Compute I get an error that says “FailedReadingMagicNumber”. I am able to profile pure CUDA code without any issues.
Have you tried creating the report using the Nsight Compute app? You should be able to launch your process from inside the app in order to generate the report file, using the (perhaps unintuitive) “Connect” button. You can also use the command line app nv-nsight-cu-cli to profile and export a report that can be opened in the nsight app. https://docs.nvidia.com/nsight-compute/NsightCompute/index.html
Thank you for the reply. I had been attempting to use the Nsight Compute app. After some experimentation, I was able to get profiling to work with the Optix 5.1 SDK example, though I’m limited to being able to see the “megakernel”, as expected.
When I try to connect to an Optix 6.0 application, it launches without issue, though profiling does not start. When I close the application it shows a dialog box that says:
“failed to load report:
Reason: FailedReadingMagicNumber”
This occurs for my Optix application, as well as the Optix 6.0 SDK examples.
I spent some time this morning experimenting with the Nsight CLI, and I seem to get similar results. When trying to profile an Optix 6.0 application (my own, or the SDK examples), I get the following message: “==PROF== No kernels were profiled”
Does the current version of Nsight support Optix 6.0?
I’ve been told that Nsight compute isn’t quite ready for OptiX 6, unfortunately. It is being worked on. I apologize for making it sound like it should work, I didn’t realize this because it works internally, so I can at least confirm the solution is coming fairly soon.
Thanks for the update! This is pretty much what I expected, and I’m glad to hear it’s being worked on. I look forward to using the next version when it’s released.
I saw that there was a new version of Nsight Compute released with CUDA 10.1. However, it still seems to not work with Optix. Can you please confirm that this is still the case?
Sorry to bump this subject up, but I ran in the same issue Michael has, and I wished to know if the current version of Nsight Compute is ready for OptiX 6 now? I can’t make it work and I don’t know if that comes from my configuration of not.
Currently I’m using:
Windows w/ Geforce 2080Ti or 1080
Nsight Compute 2019.3.1 (build 26317742)
Drivers version 430.86
The last release note at the time of writing refer to windows driver version 431.02, which are only available for Quadros. Is profiling an OptiX program with Nsight possible at all with Geforce hardware by the way?
Profiling support for OptiX hasn’t been released yet. It’s almost here, and the team is aware of how much it is needed. While there are some driver releases that are Quadro only, profiling will be possible on Geforce.
In the mean time, we are here to help you work through specific issues if you have questions about how you should architect your OptiX code, or if you’re seeing performance that is slower than you expect.
Regarding specific OptiX issues, I already have one of my team members that exchanges regularly with Detlef, so we’re good on this front. But thanks for asking :)