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

Move more to the GPU in Pathfinder 3 when available #119

Closed
pcwalton opened this issue Mar 22, 2019 · 2 comments
Closed

Move more to the GPU in Pathfinder 3 when available #119

pcwalton opened this issue Mar 22, 2019 · 2 comments

Comments

@pcwalton
Copy link
Collaborator

@pcwalton pcwalton commented Mar 22, 2019

This is just a sketch of various ideas for moving CPU passes to the GPU. On certain devices such as Magic Leap 1 we're CPU bottlenecked.

Stroke

Required features: None.

Just replace stroke algorithm with a shader.

Not clear yet how to do miter joins.

Transform

Required features: Transform feedback. GL 3.0; GLES 3.0.

This one is pretty obvious. Obvious hazard is readback from GPU.

Clipping

Required features: Transform feedback, geometry or compute shader. GL 3.2; GLES 3.1.

Will require some experimentation to find best clipbuffer representation.

Tiling

Required features: Compute shader, indirect draw. GL 4.3; GLES 3.1.

Break curves into lines on GPU, assign to tiles via compute (or geometry) shader. During fill stage, accumulate outgoing fill in SSBO or writable image using atomics. Then propagate fills between tiles using a binary flood algorithm in compute shader.

Not clear how to do occlusion culling. Possibly detect solid tiles during outgoing fill tile propagation.

Intra-tile curve-to-line conversion

Required features: Geometry or tessellation shader. GL 3.2; GLES 3.2.

Not sure if this is worth it due to needing to solve cubic equations. Probably not needed if GPU tiling works out.

@nical
Copy link
Contributor

@nical nical commented Apr 17, 2019

Stroke

Not clear yet how to do miter joins.

In case it helps with inspiration, fastuidraw renders strokes in a uber shader. The CPU side mostly sends information about where the joins are and their drawing parameters, while the vertex shader extrudes a conservative bounding geometry along the path and the fragment shader does the job of rendering the joins with the right shapes.

Here's an example of some join-type-specific logic in the vertex shader: https://github.com/intel/fastuidraw/blob/f57d39936eb7c584432091863de4edd5b62c66ab/src/fastuidraw/glsl/shaders/painter/fastuidraw_painter_stroke_compute_offset.vert.glsl.resource_string#L146

@pcwalton
Copy link
Collaborator Author

@pcwalton pcwalton commented Jul 28, 2020

We have a D3D11 backend now that moves most things to GPU. Let's close this in favor of more specific items.

@pcwalton pcwalton closed this Jul 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.