Fence Sync patches

[Keith Packard]

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.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101203/54655ed6/attachment-0001.pgp>