DXR 1.1: Using TraceRayInline(...) right after TraceRay(...) crashes shader compilation

[zigguratvertigo]

Using the an almost-latest (https://github.com/microsoft/DirectXShaderCompiler/commit/780506e7149648bd940762b6716aa08e2c498a9b) DXC, running TraceRay(...) followed by a TraceRayInline(...):

TraceRay(...);

RayQuery<RAY_FLAG_ACCEPT_FIRST_HIT_AND_END_SEARCH> q;
q.TraceRayInline(...);
q.Proceed();

Crashes the shader compilation with the following error:

Val->VTy->**ContainedTys** was 0xFFFFFFFFFFFFFFFF.

This was done in an RGS during our transition from DXR 1.0 to DXR 1.1.

[tex3d]

Thanks for the report!

This bug can be worked around if you use a different RayDesc structure instance for your TraceRayInline than you do for TraceRay. You can always assign the new one to the other if it's the same, but that should prevent it from crashing until the bug is fixed.

Workaround Example:

  RayDesc ray2 = ray;
  q.TraceRayInline(..., ray2);

[donguklim]

Thanks for the report!

This bug can be worked around if you use a different RayDesc structure instance for your TraceRayInline than you do for TraceRay. You can always assign the new one to the other if it's the same, but that should prevent it from crashing until the bug is fixed.

Workaround Example:

  RayDesc ray2 = ray;
  q.TraceRayInline(..., ray2);

Thank god I found this page. I am a newbie making some PBR project with DirectX12. I was beginning think that TraceRay is incompatible with TraceRayInline.

The compiler in Windows SDK that optinally comes with Visual Studio 2022, still has this problem. It now give error an message error;llvm::cast<X>() argument of incompatible type!.

The work around of this 2 year old bug still works.