Adam Jackson <a...@nwnk.net> writes: > On Mon, 2017-02-13 at 09:42 -0800, Keith Packard wrote: >> Max Staudt <msta...@suse.de> 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? > > 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.
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. I think one of our rendering requirements is that GXcopy and then GXinvert of that line erases it, which means we can't even do this just for GXcopy. If so, the only answer I see is to punt to mi (sadly) until we write the fb rasterization in a fragment shader. Alternative: Could we draw a short line into a little pixmap at startup, and decide if the hardware renders things well enough that our current line code is usable?
signature.asc
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
