SER crashes, part 2

Gaming and Visualization Technologies Visualization OptiX
1

Sadly it looks like I have to revive this topic.

We are in the situation where SER works most of the time for me on two Blackwell Max-Q GPUs but for my colleague on two RTX 6000 Ada it crashes quite often. So I did a real heavy stress test, letting the scene run while constantly deleting and creating objects on the GPU, playing animations and so on, so that pretty much everything was triggered often.
It took me about half an hour to get the crash but it did happen. We got a similar report from a customer where it worked fine but when rendering out 2000 images it would just crash randomly.

The issue is that with compute-sanitizer it is impossible to debug, When SLI is enabled I will get immediately the ========= Program hit CUDA_ERROR_OUT_OF_MEMORY (error 2) due to “out of memory” on CUDA API call to cuDeviceGetDefaultMemPool.
The call works fine when compute-sanitizer is not enabled.
And without SLI enabled performance is so bad that even after 2 hours I didn´t trigger the crash.

I am also not able to use a debug build of the optix code since it just won´t work at all.

Are there any more options to try to identify where and why the crash happens? I asked pretty much all the AI models out there for an idea and by now they are as clueless as I am.
Is there a less invasive way to maybe trigger an exception within the optix code when something goes wrong.

Kind regards,
Michael

2

Hi @michael.nikelsky,

Sorry to hear this continues, it sounds frustrating. First question - what range of drivers and CUDA toolkits have you tried here?

–
David.

3

For drivers we have tried pretty much everything between the 572.xx and 596.xx drivers, I also tested the 610.xx drivers. But I didn´t explicitly try to crash it on every driver, that is something I explicitly did on the 610.xx and 596.86 driver so far.
Cuda Toolkit is still 12.8.1 and we are compiling to PTX, not optix-ir due to some performance issues with the older toolkit (and updating Cuda is always challenging since we need to be somewhat aligned to what driver our customers can install).

4

Thanks for the version info. Okay so next question is what’s the probability of getting a reproducer? I assume you’re quite certain now that this isn’t caused by uninitialized memory somewhere?

Here’s a couple of things to try with compute-sanitizer:
Try suppressing errors with compute-sanitizer --report-api-errors no ...
Try running past the first error with compute-sanitizer --kill no ...
You might also be able to use --tool memcheck to reduce the perf costs.

To trigger exceptions, you can use OptiX exceptions without enabling validation mode. Try OPTIX_EXCEPTION_FLAG_STACK_OVERFLOW and/or OPTIX_EXCEPTION_FLAG_TRACE_DEPTH.

You can also try adding some generous stack padding via optixPipelineSetStackSize() and see if the outcome changes. Or add sentinel values at either end of your stack frame and check for corruption. Stack overflow could be the problem, and it would appear as corruption when enabling SER.

BTW it might be worth disabling the disk cache, to be safe. You could also try CUDA_LAUNCH_BLOCKING=1 to check for a synchronization issue somewhere.

What does the crash actually look like — CUDA_ERROR_ILLEGAL_ADDRESS, device removed/TDR, hang, or a silent exit?

Does it reproduce on a single RTX 6000 Ada (SLI off) given enough time, or only in the two-GPU configuration?

What launch dimensions are you using when it crashes?

Could you do one diagnostic run with OptiX-IR instead of PTX?

On the debug build “not working at all” — could you say what specifically fails (module creation error, hang, wrong output)?

If you can share the stress-test repro (even a scripted harness rather than your full app), I’ll file it internally so we can reproduce on RTX 6000 Ada in-house. Getting this off your machine and onto ours is probably the fastest path, if it’s possible.

–
David.

5

Hi David,

I will try this out on Monday. I can do an Opitx-IR compile for sanity check to see if that fixes it.

I actually did manage to get a crash while the compute-sanitizer --tool memcheck was attached but the error was not really helpful as it just gave
========= Program hit CUDA_ERROR_UNKNOWN (error 999) due to “unknown error” on CUDA API call to cuStreamSynchronize.
originating from some material update call.

About the reproducer: It won´t be possible to give you a code reproducer as it is so difficult to reproduce but I can try to setup a scene with a script to reproduce the error in the software (this is basically what I am currently doing on my 2 Blackwell system).

Kind regards,
Michael

6

Hi again,

due to changes we had just made it finally fit barely into the 64k continuation stack size limit, whichso I was able to activate the debug options for Optix-IR, was the reason why it didn´t work for us before. This allowed me to debug the issue and hopefully fix it. In a nutshell it was geometry that was shared, one having a displaced material, another one didn´t and this caused the data access in the intersector to access the wrong data. It is a case we don´t really support but don´t prevent, so it could happen.
But so far, at least on my system, it is now stable again as far as I can tell.
So fingers crossed that it will also work on the other system now.

Kind regards,
Michael

7

Ok, sadly it looks like the issue still happens on a customer system. Not sure how we can reproduce this.