Initial DRI3000 protocol specs available

[Keith Packard]

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.

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.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20130307/42f115ac/attachment.pgp>