[PATCH 00/20] New glamor core rendering code (v2)

[Keith Packard]

Michel Dänzer <michel at daenzer.net> writes:

> The radeon driver doesn't use the glamor_*_nf() entrypoints, it leaves
> all the rendering and fallback handling to glamor.

Cool. That makes things more similar, unlike uxa which mixes glamor and
legacy rendering code in the same driver.

> E.g. the GtkComboBox test leaves artifacts outside of the gtkperf
> window, or also just scrolling the gtkperf widget containing the test
> results.
>
> I think at least part of the problem is using glCopyPixels for
> overlapping copies. 3D cores just cannot do that; if any versions of the
> OpenGL spec do not explicitly say this produces undefined results,
> that's probably just an oversight in the spec, as Markus pointed out.

Yeah, people keep telling me it's undefined, and yet the spec, as of of
4.3 says that it should work 'just as if ReadPixels were called'
... 'written to the frame buffer just as if DrawPixels'. That seems
pretty unambiguous to me; if you can't make it work like ReadPixels
followed by DrawPixels, you're doing it wrong.

In any case, 4.4 adds weasel words explicitly breaking the contract
above, and so I've switched to a temporary buffer path to the blt code
which should help in your case. Turns out to not be a performance
problem on current intel hardware as the 2D engine used for glCopyPixels
hasn't seen much in the way of improvement for several generations. Of
course, older hardware with a relatively better 2D engine will see a
slow-down because of the extra memory transfers.

Please check out my current glamor-server branch and see if that helps any.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140407/100afdc5/attachment.sig>