[PATCH] Revert "Set DamageSetReportAfterOp to true for the damage extension" (#30260)

[Francisco Jerez]

Keith Packard <keithp at keithp.com> writes:

> On Wed, 20 Oct 2010 15:03:59 -0700, Aaron Plattner <aplattner at nvidia.com> wrote:
>
>> Fine, but will you be willing to move this call to the drivers that need it
>> when we have a real sync extension?
>
> I don't see the point -- it doesn't change anything visible to clients
> or drivers, other than to eliminate the tiny window where some damage
> events might be delivered in a slightly different order, aside from the
> bug present within the Damage code.
>
> Also, there's no way, given the currents server API, to have drivers
> make this call -- they can't know which of the many damage objects
> within the server are created by the damage extension.
>
> I guess I'm curious how these other drivers manage to use the composite
> extension today; are they just forcing cross-queue synchronization at
> every flush call in the X server?
>
Nouveau uses the hardware interchannel synchronization primitives on
demand (it kicks in when two channels have references to the same BO):
the nouveau DRM guarantees that two command buffers rendering to/from
the same BO will get executed in order as seen by the DRM.

So this commit *does* solve the problem for us because the kernel will
see X's command buffers before the damage event gets to the GL client.

In short, the mentioned synchronization primitive (it's called a
"semaphore") stalls channel A until the contents of a given memory
address become equal to X, then we make channel B write X to the memory
address after it's done with the disputed buffer.

> In any case, here's what I think we should ensure that any release on
> either 1.9 or 1.10 branch doesn't contain the compiz bug.
>
> For the 1.9 branch, unless the fix for the Damage code is trivial, I'd
> recommend reverting this patch there.
>
> For the 1.10 master branch, I'd strongly prefer to see the Damage bug
> get fixed before the 1.10 release. It's likely to be causing other
> problems within the server in places which use the post-op path. If no
> such fix is forthcoming before the 1.10 release, we should revert this
> patch as the known bugs it causes are worse than the known bugs it
> fixes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101021/eb4f8c91/attachment.pgp>