Skip to content
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

Match CPU/GPU logic for start tangents #705

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

raphlinus
Copy link
Contributor

When encoding a start tangent for an end cap or closed segment, use logic designed to match the GPU computed tangent for the first segment.

Note: this changes the GPU calculation to write out the lerp calculation explicitly rather than use the mix intrinsic, so we can rely on the rounding behavior. In the presence of fastmath, the rounding behavior is not guaranteed, but it is verified to work on M1.

Fixes #704, unless we get bitten by fastmath.

When encoding a start tangent for an end cap or closed segment, use
logic designed to match the GPU computed tangent for the first segment.

Note: this changes the GPU calculation to write out the lerp calculation
explicitly rather than use the mix intrinsic, so we can rely on the
rounding behavior. In the presence of fastmath, the rounding behavior is
not guaranteed, but it is verified to work on M1.

Fixes #704, unless we get bitten by fastmath.
@raphlinus
Copy link
Contributor Author

The current state of this is "works for me," and I'm feeling a bit uncertain whether it's fully portable. If we do get hit by fastmath issues, which is entirely plausible given the weak guarantees of the language, then I'm inclined to take this in a somewhat different direction: revert the encoding changes so that the final segment writes the unmodified point values, but change the GPU-side tangent calculation so that it's based on the encoded values rather than the cubic points after degree raising.

So I'm uploading this hoping to get more feedback. If it generally works, I think we can go forward.

@DJMcNab DJMcNab added this to the Vello 0.3 release milestone Sep 27, 2024
@DJMcNab
Copy link
Member

DJMcNab commented Oct 1, 2024

As I mentioned on Zulip, I still see some watertightness failures detected by #416 with this PR. Are those out-of-scope for this change?

I would also like to see a snapshot test for the longpathdash test scene added (ideally validated as showing the failure)

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.

Watertightness regression in longpathdash
2 participants