Keith Packard writes:
> [ Unknown signature status ]
> Adam Jackson 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
On 02/14/2017 12:10 AM, Adam Jackson wrote:
> fb has been the only extant renderer for nearly nine years. Clearly
> there exists code that expects it. I'm not convinced that pushing back
> on that expectation is a good move, technically correct though it may
> be.
I'll second that.
So shall we us
On 02/13/2017 11:53 PM, Keith Packard wrote:
> afaict, GL suggests 'not
> last' as the only option. It sounds like some drivers are doing both
> 'not last' and 'not first' though?
In the case that I reproduced, the 'not first' only happens occasionally, but
reproducibly.
Max
__
On Mon, 2017-02-13 at 14:54 -0800, Keith Packard wrote:
> X doesn't put any hard requirements on 0-width lines though; why do
> we think we can't use whatever GL does for this?
fb has been the only extant renderer for nearly nine years. Clearly
there exists code that expects it. I'm not convinced
Eric Anholt writes:
> Yeah, I basically think that using GL lines ever is a mistake. They're
> simple, fast, and wrong. You wish the hardware did the thing you think
> is sensible, but it doesn't.
X doesn't put any hard requirements on 0-width lines though; why do we
think we can't use whateve
Adam Jackson 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,
Adam Jackson writes:
> On Mon, 2017-02-13 at 09:42 -0800, Keith Packard wrote:
>> Max Staudt writes:
>>
>> > Okay, so do you think we can take the patch for the GXcopy case,
>> > and fall back to mi otherwise?
>>
>> We shouldn't mask driver bugs like this; is there some reason you
>> believe w
On Mon, 2017-02-13 at 09:42 -0800, Keith Packard wrote:
> Max Staudt writes:
>
> > Okay, so do you think we can take the patch for the GXcopy case,
> > and fall back to mi otherwise?
>
> We shouldn't mask driver bugs like this; is there some reason you
> believe we can't actually go get the GL d
Max Staudt writes:
> Okay, so do you think we can take the patch for the GXcopy case, and fall
> back to mi otherwise?
We shouldn't mask driver bugs like this; is there some reason you
believe we can't actually go get the GL drivers to work right?
--
-keith
signature.asc
Description: PGP sig
On 02/08/2017 06:30 PM, Adam Jackson wrote:
> I think, practically speaking, that glamor needs to match fb even along
> the corner cases where the X spec allows driver-dependent behavior. The
> simplest way to do this for this case would be to fall down to the mi
> line code for the case of non-tri
On Wed, 2017-02-08 at 14:44 +0100, Max Staudt wrote:
> On 02/07/2017 09:06 PM, Keith Packard wrote:
> > > > Max Staudt writes:
> >
> > > OpenGL implementations are allowed to be imprecise in drawing line caps.
> > > This patch expands on the original workaround in dc9fa908.
> >
> > Yeah, finding
On 02/07/2017 09:06 PM, Keith Packard wrote:
> Max Staudt writes:
>
>> OpenGL implementations are allowed to be imprecise in drawing line caps.
>> This patch expands on the original workaround in dc9fa908.
>
> Yeah, finding a way to work around GL differences seems like a good
> idea. In this ca
Max Staudt writes:
> OpenGL implementations are allowed to be imprecise in drawing line caps.
> This patch expands on the original workaround in dc9fa908.
Yeah, finding a way to work around GL differences seems like a good
idea. In this case, however, I think you're fixing some drivers and
break
OpenGL implementations are allowed to be imprecise in drawing line caps.
This patch expands on the original workaround in dc9fa908.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99705
Signed-off-by: Max Staudt
---
glamor/glamor_lines.c | 21 +
glamor/glamor_segs.c | 43
14 matches
Mail list logo
