Initial DRI3000 protocol specs available

[James Jones]

On 03/21/2013 03:41 PM, Keith Packard wrote:
> * PGP Signed by an unknown key
>
> James Jones <jajones at 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