Hello,
I extended the optixMeshViewer to include a graph, in the image I show you the minimum graph that generates a crash at the time the context gets destroyed (context->destroy()) when trying to close the application.
context->validate does not generate any error and the actual result on the screen is as expected and correct.
Here the coe
Group root = c->createGroup();
root->setAcceleration(c->createAcceleration("Trbvh"));
root->setChildCount(1);
Geometry geo = c->createGeometry();
geo->setPrimitiveCount(1);
geo->setIntersectionProgram(p["GeoIntersection"]);
geo->setBoundingBoxProgram(p["GeoBound"]);
GeometryGroup GG = c->createGeometryGroup();
GG->setAcceleration(c->createAcceleration("Trbvh"));
GG->setChildCount(1);
GeometryInstance GI = c->createGeometryInstance();
GI->setGeometry(Geo);
GI->setMaterialCount(1);
GI->setMaterial(0, material);
GG->setChild(0, GI);
root->setChild(0, GG);
By not including the GI in the group the application closes without a crash.
Using the complete graph (to the right) with no acceleration also results with the same crash.
Is there something invalid or wrong with the graph? Would it be possible to destroy the root independently before the context as a workaround?
Appreciate your help
In principle that should just work, so some more information would be required.
Please always provide the following system configuration information when asking about OptiX issues:
OS version, installed GPU(s), VRAM amount, display driver version, OptiX (major.minor.micro) version, CUDA toolkit version (major.minor) used to generate the input PTX, host compiler version.
What kind of crash?
What’s the call stack?
Does this happen with any of the OptiX SDK examples? (Esp. these: optixDynamicGeometry, optixGeometryTriangles, optixInstancing, optixMotionBlur, optixPrimitiveIndexOffsets.)
Note that the C++ wrappers in OptiX 1 - 6 do not reference count and manage the lifetime of the underlying OptiX objects. If you want to delete the underlying objects you must call the destroy() function explicitly, which effectively means you either need to query the resp. C++ objects from your hierarchy, or (faster) track all your C++ objects in a shadow graph, or add the ref-counting to the C++ wrappers.
https://forums.developer.nvidia.com/t/geometrytriangles-setvertices-and-setbuffer-vertex-buffer/82925/2
https://forums.developer.nvidia.com/t/optix-garbage-collection/158116/2
If you’re starting new projects with OptiX, it’s recommended to use OptiX 7.x versions (best 7.3), which use a much more modern, explicit, flexible, and faster API than previous OptiX versions.
Thank you.
OS: Win10
GPU: RTX 2070
VRAM: 8192MB
Optix: NVIDIA-OptiX-SDK-6.5.0-win64
CUDA: cuda_10.1.105_418.96_win10
What kind of crash?
Closing application
What’s the calls stack
At the time of the crash, context seems to still contain a refence count value of 1, same as with the original optixMeshViewer sample.
Does it happen with any of the Optix SDK sample
No. This is an independent framework created following the optixMeshViewer sample.
What kind of crash?
Closing application
Yes, you said that. I was looking for more information about the kind of crash, like an access violation or maybe some exception you caught inside the debugger.
If that was an exception what kind of exception was caught? Does it also happen in release mode then?
The call stack looks a little weird, maybe due to the inline defined checkErrorNoGetContext() in optixpp_namespace.h.
So is it actually the context->destroy() call which crashes or the checkErrorNoGetContext() function?
Does it happen with any of the Optix SDK sample
No. This is an independent framework created following the optixMeshViewer sample.
That would be in your court to debug first.
If that was an exception what kind of exception was caught? Does it also happen in release mode then?
Ah sorry, the exception error code is actually RT_ERROR_UNKNOWN (-1), it does behave the same in both release and debug mode
As you have noticed the exception is thrown with the checkErrorNotGetContext function
inline void APIObj::checkErrorNoGetContext( RTresult code ) const
{
if( code != RT_SUCCESS) {
throw Exception::makeException( code, 0u );
}
}
When the context->destroy() is called.
Any tool would you suggest to get more detailed information with the error code?
So you’re saying the context->destroy() actually returned and did not really crash but reported RT_ERROR_UNKNOWN instead.
That could be anything. That’s some kitchen sink error for many CUDA errors as well.
There is not much to be done about that without reproducer project in failing state.
If that didn’t happen with the original optixMeshViewer SDK example sources, then try to isolate which change you did to arrive at the failure.
You didn’t mention which graphics drivers you’re using. If you’re not on R465 drivers, try updating.
Graphics driver: 465.89
That’s some kitchen sink error for many CUDA errors as well.
I see, will keep trying comparing to the optixMeshViewer.
Thank you so much!
`
