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

[Keith Packard]

On Sun, 17 Oct 2010 09:58:50 -0700, Aaron Plattner <aplattner at nvidia.com> wrote:

> This change does not solve the problem it claims to solve because it
> makes two assumptions about the driver that are not always true:
> 
> 1. that it sends rendering requests to the GPU immediately, which can
>    kill performance on some GPUs, and
> 2. that the GPU processes all requests from multiple clients in order,
>    which is false for some GPUs.

When the compositing manager receives the damage event, it must be able
to access content from all applications which resulted in the reported
damage. How else can this ever work?

> All a Damage event tells you is that your next X request will be
> procesed after the damage has landed, not that the damage has already
> landed or even that the rendering commands that cause the damage have
> been submitted to the GPU.

It doesn't require anything about the current state of the GPU, only
that future rendering requests include the results of any rendering
which resulted in the reported damage.

In a multi-queue rendering engine, you clearly need to perform some
cross-queue synchronization so that the rendering performed by the
compositing manager sees the rendering performed by other applications.

The switch to reporting events after performing the rendering operation
ensured that the driver was notified about the event delivery before the
client received the event (through the 'flush' callback). It's easy to
believe that this notification is not what multi-queue hardware wants,
and that perhaps some other mechanism would be preferred.

The switch to post-op damage reporting was teste on hardware which has
only a single queue and for which ensuring that the shuffle of requests
hitting the graphics hardware is synchronized with the shuffle of
requests executed by the X server at appropriate times.

> In addition to the above, this commit also broke the Compiz
> "Wallpaper" plugin.

That's just a bug in the damage code; it would be lovely to see the
sequence of damage events delivered in both cases so we could fix
it. There should be no difference in the generated damage events, only
the sequence within the X server of when those events are generated, and
in the absence of a full output buffer requiring an intermediate flush
operation, there shouldn't even be a change in when those events are
delivered to the application.

I don't see any way to construct correct Damage semantics without
delaying the damage event delivery until after the rendering operation
has been seen by the driver; the old code relied on the damage event
getting stuck in the client output buffer.

-- 
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/20101020/5ff7a3a5/attachment-0001.pgp>