[PATCH xserver] glamor: Paint first and last pixel of lines

[Eric Anholt]

Keith Packard <keithp at keithp.com> writes:

> [ Unknown signature status ]
> Adam Jackson <ajax at nwnk.net> writes:
>
>> Is there some reason you believe GL's rasterisation rules for lines
>> match fb's zero-width lines? Section 14.5.1 of the 4.5 spec looks quite
>> a bit looser than fb to me.
>
> I think they're 'good enough'; there aren't any rules requiring
> particular rasterization for either, the only thing X requests is that
> 'not last' cap mode not draw the last pixel. afaict, GL suggests 'not
> last' as the only option. It sounds like some drivers are doing both
> 'not last' and 'not first' though?

By "some drivers" we mean i965, it seems.  The problem is that we're not
getting 0-width, specified-under-DirectX lines.  We've got glLineWidth
== 1, so we're getting the garbage "let's turn it into a polygon with
major-axis-aligned ends!" behavior.  Thanks to glamor's +0.5 translation
based on the assumption that we were drawing 0-width lines, we now have
a polygon whose start and end lie on pixel centers (other than float
rounding), for bonus unstable behavior.  If you go into i965 and program
line width to 0, everything's great.

And, if you read the GL spec, it talks a bunch about the diamond exit
rule, which would only make sense if you could actually ask for 0-width
lines.  Thanks, Khronos.

Looking at vc4, it doesn't even have 0-width line behavior, and does
even worse at this testcase.

I'm thinking we need to specify an extension allowing glLineWidth(0) for
diamond exit rule, maybe with a hint to choose between the dx9 and dx10
modes.  Then glamor could check for it and use GL, and fall back to mi
otherwise.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170315/aa005012/attachment-0001.sig>