Fence Sync patches
keithp at keithp.com
Fri Dec 3 16:21:48 PST 2010
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
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
Size: 189 bytes
Desc: not available
More information about the xorg-devel