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

[encoding] Fix path_reduced_scan buffer size #551

Merged
merged 1 commit into from
Apr 19, 2024
Merged

Conversation

armansito
Copy link
Collaborator

This is the intermediate TagMonoid buffer that is used by the two-stage scan in the "use_large_path_scan" case. This needs to be the same size as the overall path_reduce output buffer, which gets rounded up to a multiple of the path_reduce workgroup size.

This hasn't been a problem until now because src/wgpu_engine.rs allocates Buffers that are generally larger than the entries returned in the BufferSizes structure, due its quantized size class / pooling strategy. The bindings get their view size assigned based on the whole size of the buffer.

Skia uses a similar allocation strategy but assigns view size to be the precise value from BufferSizes. This causes incorrect behavior as WGSL clamps buffer accesses to the view size.

The now corrected buffer size fixes this issue.

This is the intermediate TagMonoid buffer that is used by the two-stage
scan in the "use_large_path_scan" case. This needs to be the same size
as the overall path_reduce output buffer, which gets rounded up to a
multiple of the path_reduce workgroup size.

This hasn't been a problem until now because src/wgpu_engine.rs
allocates Buffers that are generally larger than the entries returned in
the BufferSizes structure, due its quantized size class / pooling
strategy. The bindings get their view size assigned based on the whole
size of the buffer.

Skia uses a similar allocation strategy but assigns view size to be the
precise value from BufferSizes. This causes incorrect behavior as WGSL
clamps buffer accesses to the view size.

The now corrected buffer size fixes this issue.
Copy link
Contributor

@raphlinus raphlinus left a comment

Choose a reason for hiding this comment

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

Yes, this is definitely a problem in the original - pathtag_scan1 writes in full workgroup increments. I'm assuming the observed problem only manifests with more than 256k pathtags? I did look at the code in the small case and it seems fine, but it's possible I've missed something.

In any case, good catch.

@armansito armansito added this pull request to the merge queue Apr 19, 2024
@armansito
Copy link
Collaborator Author

Yes, this is definitely a problem in the original - pathtag_scan1 writes in full workgroup increments. I'm assuming the observed problem only manifests with more than 256k pathtags? I did look at the code in the small case and it seems fine, but it's possible I've missed something.

In any case, good catch.

Yes, I've only observed this in the large scan case.

Merged via the queue into main with commit b1dc07e Apr 19, 2024
15 checks passed
@armansito armansito deleted the fix-scan-buffer-size branch April 19, 2024 18:17
@waywardmonkeys waywardmonkeys added this to the Vello 0.2 release milestone May 3, 2024
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.

3 participants