Rasterize 'Bresenham' line segments as parallelograms
The previous 'connected diamonds' polygon that was used to rasterize
Bresenham lines suffered from duplicate rasterization of endpoints,
which violates the diamond exit-rule and is disallowed by the Vulkan
(and OpenGL) spec.
This change rasterizes Bresenham lines as a parallelogram, as described
by Vulkan's non-strictLines algorithm.
This satisfied Vulkan's requirements laid out in section 26.10.2
Bresenham Line Segment Rasterization:
"Implementations may use other line segment rasterization algorithms,
subject to the following rules:
- The coordinates of a fragment produced by the algorithm must not
deviate by more than one unit in either x or y framebuffer
coordinates from a corresponding fragment produced by the diamond-
exit rule.
- The total number of fragments produced by the algorithm must not
differ from that produced by the diamond-exit rule by no more than
one.
- For an x-major line, two fragments that lie in the same framebuffer-
coordinate column must not be produced (for a y-major line, two
fragments that lie in the same framebuffer-coordinate row must not be
produced).
- If two line segments share a common endpoint, and both segments are
either x-major (both left-to-right or both right-to-left) or y-mayor
(both bottom-to-top or both top-to-bottom), then rasterizing both
segments must not produce duplicate fragments. Fragments also must
not be omitted so as to interrupt continuity of the connected
segments."
OpenGL ES line rasterization has not been modified as part of this
change, to not require rebasing of golden images, but the parallelogram
algorithm was made available for easy comparison.
Bug: b/80135519
Change-Id: I09e8b90a393d3a08387d79669d9dbe5f83a0811d
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/38049
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by:
Nicolas Capens <nicolascapens@google.com>
Reviewed-by:
Chris Forbes <chrisforbes@google.com>
Reviewed-by:
Alexis Hétu <sugoi@google.com>
Showing
Please
register
or
sign in
to comment