[PATCH] remove damagePostOp() from DamageDamageRegion()

[Michel Dänzer]

On Wed, 2008-08-27 at 09:56 -0700, Aaron Plattner wrote:
> On Tue, Aug 26, 2008 at 11:58:28PM +0200, Maarten Maathuis wrote:
> > This is a patch based on a suggestion by Michael Danzer, because it's
> > non-trivial i'm posting it first. The idea is that PostOp only needs
> > to be called after doing an actual rendering operation. Please voice
> > any concerns you might have.
> >
> > I CC'ed Aaron Plattner because "he" might be the only out of tree user
> > of this symbol.
> >
> > Maarten.
> 
> Thanks for the heads-up, Maarten.  We do indeed use DamageDamageRegion to
> report damage from things like Xv and OpenGL rendering, and rely on it
> actually sending the events.  While we can certainly add calls to
> DamageDamagePostOp where necessary, it seems unfortunate to break existing
> drivers when it would be trivial to add a new function.

The problem is that DamageDamageRegion calling damageReportPostOp isn't
really useful: If DamageDamageRegion is called before a rendering
operation, that breaks damage records interested in damage only after
rendering operations. If it's called afterwards, that breaks damage
records that need pending damage before rendering operations. The EXA
pixmap migration logic happens to match both descriptions.


> Now might be a good time to reopen the discussion about fixing the Damage
> extension for asynchronous hardware.  There are two ways to solve this:
> 
>   1. Add extensions to allow GL client rendering to wait for X rendering
>      associated with a particular Damage event using some sort of sync
>      barrier.
>   2. Defer sending Damage events until the damage has actually occurred.
> 
> While 1 would be ideal, it's probably too complicated to spec and implement
> in a reasonable timeframe so it might be a good idea to think about
> implementing 2.  
> 
> What we need for that is
> 
>   a. reportAfter-like semantics for all damage objects, not just ones that
>      were explicitly marked with DamageSetReportAfterOp.
>   b. Deferring damageReportPostOp to after the rendering has actually
>      occurred, not just after it's been submitted to the hardware.

I understand a. would break things like software cursor which relies on
getting damage reports before rendering operations.

b. would break the EXA pixmap migration logic.

Sorry I don't have time to think about other solutions right now, I just
wanted to point out these issues.


> The NVIDIA driver is not the only one that needs this; it'll be a problem
> for any driver for hardware that processes commands from OpenGL and X
> asynchronously.

Yeah, this has already been observed with compiz with DRI2 direct
rendering.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer