Skip to content

Add reflect tests #287

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

Merged
merged 7 commits into from
Jul 22, 2025
Merged

Add reflect tests #287

merged 7 commits into from
Jul 22, 2025

Conversation

bob80905
Copy link
Contributor

@bob80905 bob80905 commented Jul 11, 2025

This PR adds tests for the reflect function. Adds float16 and float32 test files.
Fixes #170

@bob80905 bob80905 changed the title add reflect tests Add reflect tests Jul 11, 2025
Icohedron
Icohedron previously approved these changes Jul 15, 2025
Copy link
Contributor

@Icohedron Icohedron left a comment

Choose a reason for hiding this comment

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

Tests look correct to me

Copy link

@tex3d tex3d left a comment

Choose a reason for hiding this comment

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

This seems too focused on a degenerate edge case, uses more resources than it would seem necessary, and should include literal cases to test constant-folding.

StructuredBuffer<half4> IncidentRay : register(t0);
StructuredBuffer<half4> Wall1 : register(t1);
StructuredBuffer<half4> Wall2 : register(t2);
StructuredBuffer<half4> Wall3 : register(t3);
Copy link

Choose a reason for hiding this comment

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

You're using StructuredBuffers, which means you can define everything you need in one buffer for simplicity, right? Same with the output buffer.

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 think you're right, but I personally find it more readable / maintainable to separate things out.
Won't need to worry as much about padding / alignment this way.

- Name: Wall1
Format: Float16
Stride: 8
Data: [ 0xbc00, 0x0000, 0x0000, 0x0000 ]
Copy link

Choose a reason for hiding this comment

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

Why are most of the components for all of the inputs zeros? Axis aligned edge cases are probably the least interesting. A few random number inputs in a reasonable range should be sufficient to test the math expansion, and would be better than leaving z and w dimensions zeroed for all inputs (in my opinion).

- Name: Wall1
Format: Float32
Stride: 16
Data: [ -1.0, 0.0, 0.0, 0.0 ]
Copy link

Choose a reason for hiding this comment

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

Using 1.0 and so many zero components means this is only testing a degenerate edge case. I really think we should be testing with combinations of numbers in reasonable ranges and using a ULP tolerance at least as high as the potential variance in expansions and operation precisions.

@Icohedron Icohedron dismissed their stale review July 15, 2025 21:37

As tex suggested, this PR could include some more varied tests to exercise the function under more interesting scenarios.

Copy link
Contributor

@Icohedron Icohedron left a comment

Choose a reason for hiding this comment

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

Must be tough to visualize how a 4D incident ray reflects off of a 4D wall

- Name: ExpectedResult4D
Format: Float16
Stride: 8
Data: [ 0x3400, 0xb800, 0x3800, 0xba00, 0x3400, 0xb800, 0x3800, 0xba00 ]
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Can we annotate what the decimal values are for these (and elsewhere)

// 4D case
half4 result4D = reflect(IncidentRay4D[0].xyzw, normalize(Wall4D[0].xyzw));
Result4D[0] = result4D;
half4 result4D_constant = reflect(half4(0.5, -0.25, 0.75, -0.5), half4(0.5, 0.5, 0.5, 0.5));
Copy link
Contributor

Choose a reason for hiding this comment

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

I believe all the values that are used in this test (and all others) are exactly representable in IEE 754. Should we have an extra test that uses values that will be rounded?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

0.70710677 gets rounded to 0.70703125 in the 3D test. Does that resolve your concern?

Copy link
Contributor

Choose a reason for hiding this comment

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

Sure, that works

@bob80905 bob80905 merged commit dd0dce0 into llvm:main Jul 22, 2025
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add test for reflect
4 participants