Checking for invalidated Optix context after driver crash


I am trying to integrate Optix into the Ogre3D rendering API. Context creation, loading PTX files, creating render buffer using GLBO, validate & compile etc all works, but I get a video driver crash during launch. But that is a topic for another thread on the Ogre3D forums.

My problem is during shutdown. During Optix init, the application performs a test render, catches the exception and starts to shutdown. Of course that includes destroying the Optix context that was created.

However, destroying the context causes an access violation. I am guessing the driver crash is invalidating the Optix context.

Before calling destroy() on the Context, I am calling validate() which does not throw any errors. Yet destroy() causes access violation in optixpp_namespace.h on line 1593.

Is there a way to check that the context is actually still valid? If possible I’d rather not have to use some ugly hack where a render fail skips destroying the Optix context during shutdown.


While I’m at it, if anyone knows how to debug mysterious errors like this:

Unknown error (Details: Function “_rtContextLaunch2D” caught exception: Encountered a CUDA error: Kernel launch returned (999): Unknown, [6619200])

I’d appreciate any clues people have about these kinds of errors. CUDA error logging is so thoroughly informative, it sure doesn’t give me a headache or anything.

After the driver crash the application can only (try to) shut down gracefully. Unfortunately the error message above does not give information on the cause of the problem.
A trace would be helpful analyzing the error in context destroy. For capturing a trace the environment variable OPTIX_API_CAPTURE has to be set to 1 before running your application. If you send us the trace we can have a look at the problem.


The trace can be found here.

Actually I realized I was trying to render into a PBO but the programming guide indicates can only read from a PBO but not write to it. So I can fix that up by using a VBO. But still, would be nice to figure out a way to have a clean shutdown after a failed launch.

Thanks for providing the trace. Unfortunately the trace does not help finding the cause of the access violation since some data have already been destroyed. It would be necessary looking into your complete application. If you want us doing a closer examination we could describe where to upload the data. Do you know the reason for the driver crash? Which type of data are you rendering?