Damage as a DIX notion

[Eric Anholt]

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

> On 26/09/16 11:23 AM, Keith Packard wrote:
>> Eric Anholt <eric at anholt.net> writes:
>> 
>>> In talking with ajax, I came around to "just compute the bounds up
>>> front, always."
>> 
>> That's certainly simpler. It would be useful to go and measure how much
>> of firefox's (and maybe other applications?) rendering is aimed at
>> pixmaps without damage tracking enabled.
>> 
>>> All glamor ops will want the damage for scissoring (we're already
>>> setting scissors all the time, so now we just intersect the new incoming
>>> box with the scissor we were going to set).  All window ops want the
>>> damage for compositing.  Software cursor wants it for screen.  Basically
>>> what get from the kinda complicated lazy damage API is avoiding damage
>>> computation for pixmap-only rendering.
>> 
>> The question is whether damage-less rendering happens enough to be worth
>> this effort. That includes both pixmap rendering and non-composited
>> desktops.
>> 
>> Text is probably the most interesting operation for which server
>> request overhead is significant (the other being dots).
>> 
>>> I think the approach outlined here would also work.  I'm just not
>>> convinced it's necessary.
>> 
>> A data-driven approach would be awesome here. Do we have a reasonable
>> performance metric? I'm no fan of gratuitous complexity, but text
>> performance is pretty important to me.
>
> Here are some data points with the radeon driver using glamor on
> radeonsi. This is comparing the default configuration with Option
> "TearFree" (which uses extents based damage tracking as described in
> my other post):
>
> 1: /tmp/baseline.txt
> 2: /tmp/tearfree.txt
>
>        1                 2                 Operation
> ------------   -------------------------   -------------------------
>  194000000.0    148000000.0 (     0.763)   Dot 
>    9660000.0      9150000.0 (     0.947)   Char in 80-char aa line (Charter 10) 
>
> These might be useful as worst-case estimates of the overhead, since
> TearFree copies the damaged contents of the screen pixmap to a dedicated
> scanout pixmap for each vertical refresh, which incurs overhead of its
> own.

You're also going to be doing extra rendering as a result of tearfree,
right?  (I assume this is double or triple buffering and back-copying
damage).  If that's the hit for dots just from damage computation, then
I think we need to go the keithp proposed API route (or do the quick
hack of "hey, look, 100000 dots on my 100x100 window, I'll just say the
whole thing is damaged).

I'm really hesitant to rely on the current damage reports for bounds of
my rendering.  It feels very fragile for situations where you have an
operation decompose into multiple operations in one of your layers (like
Trapezoids, which have a fill then addtraps then a composite).  We
certainly fought with this in EXA, and it's why I'd like to have an
explicit damage computation available for the args given in an op.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160926/9044fd61/attachment.sig>