Initial DRI3000 protocol specs available

[James Jones]

On 03/07/2013 12:49 PM, Keith Packard wrote:
> * PGP Signed by an unknown key
>
> Aaron Plattner <aplattner at nvidia.com> writes:
>
>> If I'm understanding this correctly, this requires the X server to
>> receive a notification from the GPU that the swap is complete so it can
>> send the SwapComplete event.  Is there any chance this could be done
>> with a Fence instead?  The application could specify the fence in the
>> Swap request, and then use that fence to block further rendering on the
>> GPU or wait on the fence from the CPU.
>
>  From what I've heard from application developers, there are two
> different operations here:
>
>   1) Throttle application rendering to avoid racing ahead of the screen
>
>   2) Keeping the screen up-to-date with simple application changes, but
>      not any faster than frame rate.
>
> The SwapComplete event is designed for this second operation. Imagine a
> terminal emulator; it doesn't want to draw any faster than frame rate,
> but any particular frame can be drawn in essentially zero time. This
> application doesn't want to *block* at all, it wants to keep processing
> external events, like getting terminal output and user input events. As
> I understand it, a HW fence would cause the terminal emulator to stall
> down in the driver, blocking processing of all of the events and
> terminal output.

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.

Thanks,
-James

> For simple application throttling, that wouldn't use these SwapComplete
> events, rather it would use whatever existing mechanisms exist for
> blocking rendering to limit the application frame rate.
>
>> We typically try to do the scheduling on the GPU when possible because
>> triggering an interrupt and waking up the X server burns power and
>> adds latency for no good reason.
>
> Right, we definitely don't want a high-performance application to block
> waiting for an X event to arrive before it starts preparing the next
> frame.
>