Fence Sync patches

[James Jones]

On Friday 03 December 2010 4:21:48 pm Keith Packard wrote:
> * PGP Signed by an unknown key
> 
> On Fri, 3 Dec 2010 15:42:30 -0800, James Jones <jajones at nvidia.com> wrote:
> > -Our drivers are going to be non-compliant in regard to the implicitly
> > synchronized behavior for the foreseeable future.  It is truly a mountain
> > of work to implement it with reasonable performance in our current
> > architecture.
> 
> In any case, you've got me thinking about the problem now, so I'd like
> to think about using the general X fencing capability. Instead of doing
> 
>     XDamageSubtractAndTrigger (dpy, damage, repair, parts, finshedFence);
> 
> it seem like it would be cleaner to do two separate requests:
> 
>     XDamageSubtract (dpy, damage, repair, parts);
>     XSyncTriggerFence (dpy, finishedFence);
> 
> This eliminates all questions about changing the damage implementation
> and gets us back to a very simple question of what the Damage
> specification should say. Less code too.
> 
> > We're slowly adapting to an architecture where it'd be easier, and we
> > could fix it at that time, but I doubt I'll get time to before then.  I
> > can live with being no compliant.  Apps have grudgingly accepted the
> > quasi-defined behavior of texture-from-pixmap "loose binding" mode for
> > years to get the performance benefits it offers.
> 
> We either change the damage spec to require fencing (which breaks
> existing apps for all drivers), or we find a way to tell apps which
> drivers need explicit fencing. I'd prefer the latter, and it seems like
> this will require only minor changes which could be done post-'freeze'.
> 
> This could be as simple as a root window property that applications can
> look for to see if the driver conforms to the 'normal' synchronized
> behaviour or requires fencing.

Right, and as discussed on IRC, I'll do the minimal work on the xserver patch 
series to extract DamageSubtractAndTrigger from the general X fence sync 
changes over the weekend and have it tested and ready for review on Monday 
morning latest.  We'll work out how to communicate driver behavior and tweak 
spec language soon, but separately.  The damageproto and libXdamage patches 
will be dropped, and the xextproto and libXext patches should be fine as-is, 
but I'll double check before asking Aaron to push them.

Thanks,
-James