Crash using VK_NV_ray_tracing_motion_blur in 511.79 drivers

Hi,

We’re experiencing a crash in the drivers after updating to the latest 511.79 release driver (working fine using the previous 472.84 release). Aftermath is pointing at the call to traceRayMotionNV in our ray generation shader being the cause. If I replace that with traceRayEXT then it works again (though obviously no motion blur).

Aftermath is also writing some debug output to stdout that looks like:

invalid vector, expected one element of type subrange
!63 = !DICompositeType(tag: DW_TAG_array_type, baseType: !64, size: 2, align: 32, flags: DIFlagVector, elements: !18)
invalid vector, expected one element of type subrange
!55 = !DICompositeType(tag: DW_TAG_array_type, baseType: !53, size: 2, align: 32, flags: DIFlagVector, elements: !18)
invalid vector, expected one element of type subrange
!107 = !DICompositeType(tag: DW_TAG_array_type, baseType: !53, size: 3, align: 32, flags: DIFlagVector, elements: !18)
invalid vector, expected one element of type subrange
!119 = !DICompositeType(tag: DW_TAG_array_type, baseType: !53, size: 4, align: 32, flags: DIFlagVector, elements: !18)
invalid vector, expected one element of type subrange
!193 = !DICompositeType(tag: DW_TAG_array_type, baseType: !46, size: 2, align: 32, flags: DIFlagVector, elements: !18)
invalid vector, expected one element of type subrange
...

Anything we can try on our end to get it working again? This is using a 3060 Ti on Windows 10.

Thanks!

Rich.

I’ve managed to find a workaround for this. Our ray generation shader used to do something like:

... set up ray ...

traceRayMotionNV(...);

if (payload.hit_something)
   add_to_shade_queue(...);
else
   add_to_background_queue();

and would then process the two queues to either shade an intersection or a background pixel in a later set of compute shaders. Changing this so the last line in the ray generation shader is traceRayMotionNV, then doing the add_to_shade_queue in the closest hit shader and the add_to_background_queue in the miss shader seems to fix the crash. Whether there’s still some underlying problem there and I’ve just temporarily hidden it or not, I don’t know.

I do still see the invalid vector ... output from aftermath which I guess might mean there’s still something not quite right?

Anyhow, not a problem for us anymore at the moment.