microsoft / microsoft/DirectXShaderCompiler

DXC possibly emitting spurious [-Wpayload-access-trace] PAQ warnings in SM 6.7

Open
#5,848 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
C++
Stars
3.7k
Forks
900
Avg merge
2d 11h
Merged PRs (30d)
44

Description

Problem
The DXC compiler may be emitting spurious warnings about unqualified reads & writes to payload members annotated with PAQs.

Description of issue and steps to reproduce
Given the following annotated payload structure:

struct [raypayload] AOPayload
{
    Vector4 normalAndDepth : read(caller) : write(closesthit,miss);
    float occlusion        : read(caller) : write(closesthit,miss);
    AuxilliaryRay ddxRay   : read(anyhit) : write(caller);
    AuxilliaryRay ddyRay   : read(anyhit) : write(caller);
};

Members ddxRay & ddyRay are written to in the raygen shader (caller) as follows:

[shader("raygeneration")]
void RaygenShader()
{
    ...

    // Generate a ray for a camera pixel corresponding to an index from the dispatched 2D grid.
    const Ray ray = GenerateCameraRay(launchIndex, cameraPos, invViewProj);
    const Ray ddx = GenerateCameraRay(uint2(launchIndex.x + 1, launchIndex.y), cameraPos, invViewProj);
    const Ray ddy = GenerateCameraRay(uint2(launchIndex.x, launchIndex.y + 1), cameraPos, invViewProj);

    AOPayload payload;
    
    // Here I am WRITING to payload members ddxRay & ddyRay !
    payload.ddxRay = (AuxilliaryRay)ddx;
    payload.ddyRay = (AuxilliaryRay)ddy;

    TraceRadianceRay(ray, payload); // This function performs the TraceRay() call.

The HLSL function body of TraceRadianceRay() is:

// Trace a radiance ray into the scene.
void TraceRadianceRay(in Ray ray, inout AOPayload payload)
{    // We trace only one primary ray per pixel for rtao, so recursion depth does not need to be tracked.
    RaytracingAccelerationStructure Scene = ResourceDescriptorHeap[frameCB.tlasBufferSrvID];

    // Set the ray's extents.
    RayDesc rayDesc;
    rayDesc.Origin = ray.origin;
    rayDesc.Direction = ray.direction;
    rayDesc.TMin = 0;
    rayDesc.TMax = MaxAO_PrimRayLength;

    TraceRay(
        Scene,
        RAY_FLAG_NONE, //RAY_FLAG_CULL_BACK_FACING_TRIANGLES,
        0xFF,
        RayType::Radiance,
        0,
        RayType::Radiance,
        rayDesc,
        payload);
}

When compiling the full shader like so:

dxc RaytracingShaderAO.hlsl -T lib_6_7 -Zi -Vn g_RaytracingShaderAO -Fd Shaders\PDB\RaytracingShaderAO.pdb -Fh Shaders\RaytracingShaderAO.hlsl.h

DXC is returning the following warnings, which claim the 'write' fields are never written in the caller stage:

RaytracingShaderAO.hlsl:125:9: warning: field 'ddxRay' is 'write' for 'caller' stage but field is never written for TraceRay call [-Wpayload-access-trace]
        payload);
        ^
RaytracingShaderAO.hlsl:125:9: warning: field 'ddyRay' is 'write' for 'caller' stage but field is never written for TraceRay call [-Wpayload-access-trace]

Environment

  • DXC version <[(dxcompiler.dll: 1.7 - 1.7.2308.7 (69e54e290); dxil.dll: 1.7(101.7.2308.12))]>
  • Host Operating System <[Edition Windows 11 Home
    Version 22H2
    Installed on ‎4/‎10/‎2022
    OS build 22621.2361
    Experience Windows Feature Experience Pack 1000.22674.1000.0]>

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the warning with the provided AOPayload, TraceRadianceRay, and dxc lib_6_7 command, then trace the payload-access analysis associated with -Wpayload-access-trace. Done means determining whether the caller writes to ddxRay and ddyRay are incorrectly missed and adding or updating coverage so the diagnostic matches the actual access behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.