[PATCH] remove damagePostOp() from DamageDamageRegion()

[Aaron Plattner]

On Wed, Aug 27, 2008 at 07:07:40PM +0200, Michel D?nzer wrote:
> 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.

Right for X rendering.  However, the current DamageDamageRegion behavior is
exactly what's needed for direct-rendering clients like OpenGL, which is
what we use it for in the NVIDIA driver.  What I meant was that it
shouldn't be too hard to leave DamageDamageRegion the way it is and migrate
the currently incorrect users of that function to some new thing that
doesn't call damageReportPostOp.

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

Right.  Obviously we need both, plus something new to solve the
asynchronous OpenGL problem that I described in my reply to Adam's message.

-- Aaron