[PATCH 00/20] New glamor core rendering code (v2)
Keith Packard
keithp at keithp.com
Thu Apr 17 18:36:03 PDT 2014
Eric Anholt <eric at anholt.net> writes:
> 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.
Thanks for the analysis. I'll see if I can't get some internal
statistics about what the cache is actually being used for; it'd be
great if we could limit the number and size of entries without major
performance impacts.
--
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/20140417/5138bd1a/attachment.sig>
More information about the xorg-devel
mailing list