My OptiX8-based raytracer generally works on device driver 537.42 using my older GTX 1050 (Pascal GPU).
Yesterday I was trying to update to the current driver 565.90, but then some (but not all) module compilings report error 7299 (internal compiler error).
The Release Notes of OptiX 8.0.0 say Maxwell is the minimum compute compatibility.
Did that change inbetween? Or is a newer CUDA version required for that driver?
Rebuilding all PTX files when the new driver was installed, made no difference; same error message. Those PTX files then also again work now, when I was going back to driver 537.42
I can live with using the older driver, since the machine in which it is, will not being updated with Windows11 anyway;
But it would be good to know, whether there is anything I may have to change in the code to be able to use the latest driver for that Pascal device on Windows10.
Thank you.
My System:
OptiX 8.0.0 SDK
CUDA 12.2
GTX 1050 2GB
Win10PRO 64bit (version 22H2; build 19045.2846)
8GB RAM
device driver: 537.42 (my raytracer is working correctly)
VS2022 v17.7.6 (toolkit v142) MDL SDK 2020.1.2
Windows SDK 10.0.19041.0
Original Version of my Raytracer was based on the architecture of the OptiXApps samples from 2018 and newer (with many updates)
I’m not aware of any reasons Pascal would cause issues, the min compute capability is still Maxwell. Our regression tests are passing on a Pascal GPU with a 565 driver. Did you check if the OptiXApps “advanced” samples or the SDK samples still compile & run on the Pascal with the 565 driver?
If our repos compile & run for you but yours doesn’t, then you might be triggering some bug case that we’re not testing. In that case, are you able to provide a minimal complete reproducer? If the OptiX repos also have the same error, then I’d suspect a setup issue of some kind, maybe stale driver or CTK components or something in your path selecting a different version of something in the toolchain than you’re expecting.
What’s a PM in this context? I might be forgetting something obvious. :P
Actually, another good test is to use the SDK sample optixCompileWithTasks and run it on your PTX or OPTIXIR file. If that gives you the internal compile error, then that constitutes a complete and minimal reproducer, and you’re welcome to email it to us or DM me, and I can file a bug report against it.
I do get a compile error when using optixCompileWithTasks, hopefully it is the same repro you have. The error I see internally is an unhandled instruction, and it might be related to use of double precision. I have to admit that double precision code has been an intermittent source of missing instructions for us since we avoid using doubles for OptiX samples, but I know first-hand they’re super useful for debugging. Bug report has been filed. I’ll report back when more is known. In the mean time, it might be worth playing in the source code just a little to see if a workaround is easy to find. If it’s double precision related, check for anything clever with double handling. It might be moving data, type conversion, or pointer access, I’m not sure. It doesn’t appear to be the math itself, but something else. Of course it might be easy to validate if I’m telling the truth by eliding the double precision, or switching it to fp32 temporarily if it’s not something you can disable with a flag.
The device functions, which are actually used for materials in that file, use no double precision. But the include header files contain some structs and helper functions which contain double precision.
Another PTX file, which uses exact the same include header files, but has different functions (also no double precision usage in the functions), proves your point, that moving data may help here.
I’ll send that succeeding PTX file in the DM also for comparison.
Just a quick update before I forget. This was indeed a compiler bug. It has been fixed internally, and the fix is making it’s way through the QA process. I believe the fix will be released in the next driver release in a couple of weeks from now, whatever the next 565.xx or 566.xx driver is in November.