CUDA error at or before "cudaMalloc(&blah, 256 * sizeof(uint32_t))": invalid OpenGL or DirectX context (0)
visiicrash.cu:8
Note that GUI stuff with ViSII works correctly before deinitialize()--rendering, interactive stuff, etc. Also note that this issue goes away if ViSII is initialized in headless mode with initialize(true).
It appears there are several issues with deinitialize():
Does not call owlContextDestroy. Note that previous versions of OWL did not correctly clean up OptiX context on destroy--use latest OWL.
May call glfw->destroy_window while CUDA rendering still occurring
Calls glDeleteTextures(1, &OptixData.imageTexID); on different thread from thread doing other OpenGL work
// sleeping here.
// Some strange bug with python where deinitialize immediately before interpreter exit
// on windows causes lockup. The sleep here fixes that lockup, suggesting some race condition...
sleep(.1);
One final note: #70 states "repeatedly calling deinitialize in a program... is an unintended usage pattern.... users should only call initialize / deinitialize once". This is only a feasible constraint if ViSII is at the top level of a program, i.e. the program is a ViSII based visualizer that renders some application-specific stuff. If ViSII is being used as a library or part of a larger program, this constraint typically will not be able to be met. (Of course, there is an argument to be made that most cases of this would run ViSII in headless mode, which at least avoids the CUDA error.)
causes
Note that GUI stuff with ViSII works correctly before
deinitialize()
--rendering, interactive stuff, etc. Also note that this issue goes away if ViSII is initialized in headless mode withinitialize(true)
.It appears there are several issues with
deinitialize()
:owlContextDestroy
. Note that previous versions of OWL did not correctly clean up OptiX context on destroy--use latest OWL.glfw->destroy_window
while CUDA rendering still occurringglDeleteTextures(1, &OptixData.imageTexID);
on different thread from thread doing other OpenGL workOne final note: #70 states "repeatedly calling deinitialize in a program... is an unintended usage pattern.... users should only call initialize / deinitialize once". This is only a feasible constraint if ViSII is at the top level of a program, i.e. the program is a ViSII based visualizer that renders some application-specific stuff. If ViSII is being used as a library or part of a larger program, this constraint typically will not be able to be met. (Of course, there is an argument to be made that most cases of this would run ViSII in headless mode, which at least avoids the CUDA error.)