Damage as a DIX notion

[Michel Dänzer]

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.

I'd say it looks quite acceptable for text. Dots take a significant hit,
relatively speaking, but the absolute performance still seems okay.

Still, it might be better to make the bounds tracking and scissoring
opt-in in glamor, so drivers for traditional non-tiled renderers (which
presumably don't gain anything from the scissoring) don't have to incur
the cost for nothing.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160926/e45720a1/attachment.sig>