Initial commit of piet-next API sketch #589
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Ideas for what an API might look like. We'll use the CPU sparse strip implementation to test those ideas. Currently lots of TODO and very likely things will change, but this should give an idea.
This copies the implementation from the cpu-sparse branch of compute-shader-101, which is currently the most up-to-date version (though there are still rendering flaws). We remove the bytemuck dependency and change colors the color crate (following tip of tree peniko), but otherwise unchanged. Lots of warnings as well, as basically everything is unused. There will be changes. In particular, path_id will be removed, as there will be a separate sort per path.
This is the point where the pieces start coming together. At this point, we should be doing basic coarse rasterization for path fills. Not well validated yet. Printing debug output of wide tiles. Doing checkpoint before starting in on fine raster.
This brings it to the point where it can rasterize a single triangle.
Adapt pico-svg from Vello. It now renders the tiger.
Small changes to the example, and basic stats added, to help with performance measurement. Not by any means a careful performance evaluation framework, but ok for doing experiments by hand.
Neon implementation of the 4 basic fine raster operations, all using f32 as the scratch buffer.
Optimize core render_strips implementation using Neon intrinsics.
Simpler scalar code, not designed for thread parallelism. This renders tiger but is likely to have numerical robustness issues; the robustness logic from Vello has not been ported.
Again, feed the CI beast
Keep feeding the CI beast!
This might not be the last of them.
Also put allow(unused) on use_cpu, as whether that's used will vary by platform.
The logic for choosing whether to use the scalar or simd version of the strip kernel was backwards. This makes a pretty small performance difference; it just isn't a large part of the total time. Also optimize clamping behavior to take advantage of saturation in conversion operations.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ideas for what an API might look like. We'll use the CPU sparse strip implementation to test those ideas.
Currently lots of TODO and very likely things will change, but this should give an idea.