Damage as a DIX notion

[Michel Dänzer]

On 27/09/16 12:40 AM, Eric Anholt wrote:
> 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).

Yes, I wrote that at the end of what you quoted from my post? :)

It looks like the majority of the overhead is for the damage processing
though, but per Peter's post and my other posts, we can probably cut
that down as well. E.g. using a tweaked version of
DamageReportBoundingBox which only records the damage extents, I can
push the dot overhead down below 22%.

Also, will anyone really care if they only get 150 million dots per
second instead of 200 million? :) Especially since this will have to be
opt-in anyway, and for drivers which opt in to using it, the cost should
be offset by savings elsewhere.


> If that's the hit for dots just from damage computation, then
> I think we need to go the keithp proposed API route

I'm not sure how that would help though — calculating the bounds of an
operation should be about the same cost either way, shouldn't it?


> 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).

Why does it feel fragile? The damage layer has to calculate accurate
bounds of an operation anyway, otherwise it cannot serve its existing
purpose.


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