Damage as a DIX notion

[Michel Dänzer]

On 26/09/16 05:45 AM, Eric Anholt wrote:
> 
> In talking with ajax, I came around to "just compute the bounds up
> front, always."

And it should be relatively easy to get that with the existing damage
code. Since glamor is only interested in the damage region extents, it
can set a DamageReportFunc which drops everything but the extents of the
current operation, something like (based on a function used by the
amdgpu/radeon drivers):

static void
glamor_damage_report(DamagePtr damage, RegionPtr region, void *closure)
{
	/* Only keep track of the extents */
	RegionUninit(&damage->damage);
	damage->damage.data = NULL;
	damage->damage.extents = *RegionExtents(region);
}

Then the glamor rendering functions can just look at the damage region
extents.

Based on my experience with the amdgpu/radeon drivers, the CPU overhead
of this might be acceptable as is. But if it turns out to be too heavy,
we should be able to reduce it by introducing a new damageLevel which
only ever keeps track of the overall extents of the damage region, and
making the damage wrappers of rendering functions only compute the
bounding box if none of the damage records require an accurate region.

(Such a new damageLevel might even be interesting for compositors as well)


-- 
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/ad2ab3c3/attachment.sig>