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

[Eric Anholt]

Keith Packard <keithp at keithp.com> writes:

> Michel Dänzer <michel at daenzer.net> writes:
>
>> On 08.04.2014 17:13, Keith Packard wrote:
>>> Michel Dänzer <michel at daenzer.net> writes:
>>> 
>>>> Yes, that works fine now in Xephyr. The only remaining obvious problem
>>>> there is the xfwm4 window decoration corruption regression from the
>>>> master branch.
>>> 
>>> Ok, looks like that's caused by glamor re-using FBOs that were too large
>>> for tile pixmaps. Oddly, the texture fetch doesn't work like you'd want
>>> in that case.
>>> 
>>> I've added a patch to keep glamor from ever using over-sized FBOs. We'll
>>> probably want to re-enable that optimization at some point in the future
>>> as it does tend to save a ton of allocation overhead, but we'll need to
>>> be careful to only use it when the object isn't being used as a texture
>>> source.
>>
>> Right, or the texture coordinates need to be calculated according to the
>> texture size as opposed to the pixmap size. Though that still wouldn't
>> work e.g. for Render repeat modes.
>
> I'm hoping we'll be able to simply remove all of the X-server level
> pixmap caching; libdrm already caches stuff below us, and is doing a
> much more polite job of it.

Data today from removing the fbo cache entirely on poppler.trace,
compared to just using exact sizing:

x before
+ after
+--------------------------------------------------------------------------------+
|                                                                               +|
|xx          x x x                                               + +   +        +|
| |_______A__M___|                                                |____M_A______||
+--------------------------------------------------------------------------------+
    N           Min           Max        Median           Avg        Stddev
x   5      2.562944      2.751878      2.712117     2.6680034   0.089980187
+   5      3.334879      3.511184      3.408156     3.4232804   0.083419141
Difference at 95.0% confidence
	0.755277 +/- 0.126537
	28.3087% +/- 4.74276%
	(Student's t, pooled s = 0.0867617)

So, while I don't like having this cache (which sucks memory from the
system and doesn't give the kernel a chance to reclaim it), the
performance delta's big enough to keep it for now.  I see some
low-hanging fruit in Mesa, so let's revisit this if we clean up overhead
in the rest of the stack.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140417/5f567959/attachment.sig>