Optix7 and game ready driver 440.97

does the new driver 440.97 break optix7 ? the optix functions fail with this driver but work fine if I install back the GR 436.48 drivers. or do I need to care about something else now ?

Could you please add some more information about your system configuration?
Most importantly would be OS version and installed GPU(s), standard or DCH drivers.

Also please describe in more detail what you mean with “the OptiX functions fail.”

Is the OptiX driver found?
Does the OptixFunctionTable initialize correctly?
If yes, which OptiX functions do not work?
What would be the way to reproduce that?

it happens on several different systems…

  1. Windows 10 1903 … 2 x RTX 2080Ti
  2. Windows 10 1903 … Quadro RTX 6000 and GTX 1060
  3. Windows 10 1909 … Titan V and RTX 2060

it happens with the new driver 440.97 only. all previous drivers are running without any issues.

the optix drivers are found, the tables are initialized correctly. it compiles all shaders.
it happens in optixAccelComputeMemoryUsage() during building the bvh for a triangle input.
it logs the following message:

“buildInputs[0].triangleArray”, “transformFormat” is OPTIX_TRANSFORM_FORMAT_NONE, but “preTransform” is not null “const char *”

for that input preTransform is set, but where I have to set “transformFormat” ? and OPTIX_TRANSFORM_FORMAT_NONE is not defined in the current sdk … ?

Thanks, I see. I’ll file a bug report.

Same problem with GTX 1050 driver version 440.31-2 on Linux. But it prints instead:

Invalid value (0x5621) for “buildInputs[0].triangleArray.transformFormat”

Seems to be an uninitialized value which I guessed was the padding for the struct TriangleArray, but instead was transformFormat, which is not a member in the include file. Fixed it by setting with pointer magic this value to 0 with no preTransform, but shouldn’t be a long-term solution.

I use Arch Linux btw.

Yes, there was a bug in R440 drivers and a serious test escape.

This has been fixed in the meantime. The just released Windows driver 441.28 has picked up the fix already.
Unfortunately Linux 440.31 drivers have been cut before the fix. The next 441 Linux drivers should have it.

If you already hacked that integer field to 0 when preTransform is null, the expected value when preTransform is actually containing 3x4 matrices is 0x21E1.

Thanks for the help! I was already thinking about the workaround, but this makes it a lot easier.