On Fri, 3 Dec 2010 15:42:30 -0800, James Jones <jajo...@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.pack...@intel.com
pgpl5GQ0LaOi0.pgp
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel