On Sun, 17 Oct 2010 09:58:50 -0700, Aaron Plattner <aplatt...@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.pack...@intel.com
pgpMQQlwAlw5H.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