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