Skip to content

[SER] Basic execution tests #7379

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 15 commits into
base: staging-sm6.9
Choose a base branch
from

Conversation

simoll
Copy link
Contributor

@simoll simoll commented Apr 25, 2025

  • All trivial scalar/vector/matrix getters
  • HitObject::FromRayQuery with procedural hit
  • HitObject::GetAttributes with custom attributes and procedural hit

SER implementation tracker: #7214

- All trivial scalar/vector/matrix getters
- HitObject::FromRayQuery with procedural hit
- HitObject::GetAttributes<T> with custom attributes and procedural hit

SER implementation tracker: microsoft#7214
@simoll simoll mentioned this pull request Apr 24, 2025
41 tasks
@tex3d tex3d self-assigned this Apr 25, 2025
@damyanp damyanp moved this to Active in HLSL Support Apr 25, 2025
Copy link
Member

@damyanp damyanp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a lot of code here to review and I've not had a chance to go through it all in detail.

However, I'll note that before this can go into main we'll need to get it updated to follow the LLVM coding standards.

For the short term maybe this should go into the staging branch?

@@ -2078,6 +2095,707 @@ void ExecutionTest::RunRWByteBufferComputeTest(ID3D12Device *pDevice,
WaitForSignal(pCommandQueue, FO);
}

CComPtr<ID3D12Resource> ExecutionTest::RunDXRTest(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason this all has to be in this file?

@github-project-automation github-project-automation bot moved this from New to In progress in HLSL Roadmap Apr 25, 2025
@damyanp damyanp requested review from nadaOuf and clandrew April 25, 2025 20:10
@clandrew
Copy link
Collaborator

Thanks! Taking a look at this now. It might be that we can simply ingest the test code based on this staging branch and it does not necessarily have to be merged.

@simoll
Copy link
Contributor Author

simoll commented Apr 29, 2025

There's a lot of code here to review and I've not had a chance to go through it all in detail.

However, I'll note that before this can go into main we'll need to get it updated to follow the LLVM coding standards.

For the short term maybe this should go into the staging branch?

Should close this PR and re-open against staging-sm6.9?

@simoll simoll changed the base branch from main to staging-sm6.9 April 30, 2025 05:10
@simoll
Copy link
Contributor Author

simoll commented Apr 30, 2025

There are merge conflicts with the sm69 staging branch just because this was originally based on main. Will reopen as a new pR.

@simoll simoll closed this Apr 30, 2025
@github-project-automation github-project-automation bot moved this from Active to Closed in HLSL Support Apr 30, 2025
@github-project-automation github-project-automation bot moved this from In progress to Done in HLSL Roadmap Apr 30, 2025
@simoll simoll reopened this Apr 30, 2025
@simoll simoll changed the base branch from staging-sm6.9 to main April 30, 2025 10:49
@simoll
Copy link
Contributor Author

simoll commented Apr 30, 2025

Decided to reopen and updated to make sure we can keep reviewing this while main gets merged into staging.

  • Reworked variable names to follow LLVM Coding Standards
  • Removed some redundant code with a new CreateDXRDevice function
  • Added another test (Invoke called on a HitObject-from-RQ that has no SBT set)

@simoll simoll changed the base branch from main to staging-sm6.9 April 30, 2025 14:28
simoll added 6 commits April 30, 2025 17:56
- Array of 8 HitObjects, each with different ray flags
- Samples at 'random' positions to block SROA from breaking down the
  array
(procedural)

- Support for procedural geometry and triangles at the same time
- fix: make IS non-optional
- Made payload/attributeCount in RunDXRTest non-defaulting
- Use a circle for procedural geoemtry and make sure it fits into the
  AABB
void anyhit(inout PerRayData payload, in Attrs attrs)
{
payload.visited |= 2U;
AcceptHitAndEndSearch();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a test bug here:

The test attempts to very that threads fall into 3 buckets of work:

  • Threads that hit nothing (payload ends up as 0)
  • Threads that hit the AABB, which doesn't commit the hit, and that's all (payload ends up as 8)
  • Threads that hit the AABB and the triangle (payload ends up as 2 | 8 | 16 = 26)

For that last bucket, there's no requirement on the ordering between the hits of the AABB and the triangle. If the triangle is hit first, then this function call causes the AABB to not be hit, and therefore the 8 is missing from the final payload (value 18). WARP hits this case 100% of the time.

However, even without this, if the triangle is hit first and is in front of the procedural primitive (which it apparently is, half of the time, according to what I'm seeing with WARP), then accepting the triangle will cause the procedural primitive or its any-hit to be skipped.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the test to no longer rely on anyhit/intersections. Instead, we hit or miss the triangle (aabbs ignored by ray flag), then mutate to an aabb hit. Only testing for correct invocation of the miss/closesthit/chAABB shaders

Comment on lines 1559 to 1569
if (relHitPos.y >= 0.0f)
hitKind = 1;
hitKind *= 2;
if (relHitPos.x >= 0.0f)
hitKind += 1;
hitKind *= 2;
if (relHitPos.z >= 0.0f)
hitKind += 1;

CustomAttrs attrs;
attrs.dist = length(relHitPos);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems something in here is too dependent on floating point precision. If I allow FMA fusing in WARP (which literally just was hooked up a few weeks ago) then the test passes, but if I disable it then I get a bucketing which is off-by-one from the test expectations.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made the hitkind more robust by replacing the fp comparison and with launchIndex-based comparisons to generate a meaningful hitKind. Please test on your end, there may still be fp precision issues with the aabb intersection logic itself.

[shader("anyhit")]
void anyhit(inout PerRayData payload, in Attrs attrs)
{
AcceptHitAndEndSearch();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test appears to suffer from the same issue I described for SERShaderTableIndexTest, where the order of triangle vs procedural hits in the acceleration structure determines the overall bucketing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hit order issue should be resolved. Keeping this open until confirmed.

Copy link
Contributor

github-actions bot commented May 8, 2025

✅ With the latest revision this PR passed the C/C++ code formatter.

@damyanp damyanp moved this from Closed to Active in HLSL Support May 9, 2025
@simoll simoll marked this pull request as draft May 9, 2025 17:00
TEST_METHOD(SERInvokeNoSBTTest);
TEST_METHOD(SERMaybeReorderThreadTest)
TEST_METHOD(SERDynamicHitObjectArrayTest);
TEST_METHOD(SERWaveIncoherentHitTest);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am reformatting these test to fit our d3d12 hlk test structures. @simoll since these tests don't need to run as part of dxilconf I am planning to reject this PR. Do you still need it open to push more changes? or these all the tests you are adding?

D3D12_RESOURCE_DESC Desc = CD3DX12_RESOURCE_DESC::Buffer(
TotalSizeInBytes, D3D12_RESOURCE_FLAG_NONE,
std::max(D3D12_RAYTRACING_SHADER_RECORD_BYTE_ALIGNMENT,
D3D12_DEFAULT_RESOURCE_PLACEMENT_ALIGNMENT));
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are we getting max here? those are known values and the default is always going to be bigger.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

6 participants