On 03/21/2013 03:41 PM, Keith Packard wrote:
* PGP Signed by an unknown key
James Jones <jajo...@nvidia.com> writes:
If you associate an X Fence Sync with your swap operation, the driver
has the option to trigger it directly from the client command stream and
wake up only the applications waiting for that fence. The compositor,
if using GL, could have received the swap notification event and already
programmed the response compositing based on it before the swap even
completes, and just insert a token to make the GPU or kernel wait for
the fence to complete before executing the compositing rendering
commands.
Sorry for the long lag; I've been thinking about this quite a bit.
Sorry for the lag in my response as well.
I
went and read through your earlier proposal as well as reading through
the related GL fence extensions and I think this is what we want in
general terms. There are two distinct times of interest here:
1) When the buffer is free and can be used for another frame.
2) When the buffer contents are visible on the screen. (This
needs some weasel wording so that the system can do things like
severely limit background applications or invisible applications.)
Providing X Fence Sync objects for each of these times seems like it
will give applications what they need.
The second issue is that we must relate these X Fence Sync objects to
direct rendering so that clients using shared objects outside of the X
protocol can synchronize their operations with the X server. For that, I
think we can share a page between application and X server that contains
all of the necessary fence information along with a pthreads semaphore
object that can lock access to the fence and also provide a way to block
until the X Fence Sync object is signaled.
There's some work going on to get something very much like fence sync
objects into the Linux kernel as well, I think starting with something
from the Android kernel trees, and with input from some people working
on fence objects usable to synchronize access to dmabuf objects. It
might make sense to use these primitives rather than shared
memory+pthreads to share the syncs between direct rendering clients and
the X server. At the very least, it would be nice to have an
abstraction where the implementation details of the sync objects weren't
directly exposed by the API.
This eliminates the explicit Swap events and replaces them with Sync
objects.
I'll write this up in the extension description and try to get some code
written in the next couple of weeks.
I like the sound of the overall direction. Looking forward to what you
come up with.
Thanks,
-James
_______________________________________________
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
