Initial DRI3000 protocol specs available

[Keith Packard]

Chris Wilson <chris at chris-wilson.co.uk> writes:

> What I don't see here is how the client instructs the server to
> handle a missed swap.

Right, this first pass was just trying to replicate the DRI2 semantics;
figuring out how to improve those seems like a good idea.

From what game developers have told us, a missed swap should just tear
instead of dropping a frame. It might be nice to inform the client that
they're not keeping up with the target frame rate and let them scale
stuff back; I'd suggest the SwapComplete event could contain enough
information to let them know what actually happened.

> For example, with the typical use of
>   swap-interval > 0, divisor = 0, target <= current
> we can choose to either emit this SwapRegion synchronously, or
> asynchronously (to risk tearing but allow the client catch up to its
> target framerate).

I haven't heard anyone asking for us to skip a frame in this case to
avoid tearing.

> Actually, there isn't a mention of whether this
> should be synchronized to the display at all (and how to handle
> synchronisation across multiple scanouts).

Eric suggested we fix the multi screen problem by making the application
figure this out (if they like). I'm thinking we would just add a RandR
CRTC to the request, or let the client set it to None if they don't care.

> What happens for a delayed error?

What kind of errors can happen after the request is validated? I'd hope
that these cases would be truly exceptional. Realistically, we don't
have any place to report these that the DRI library could ever hope to
see them reliably. We could report them in an event, but that would
need to trust on the kindness of the application to send it along to the
library. We could pend the errors and report them in a future SwapRegion
reply, but that would presume that the application is continuously
rendering frames.

>> 	In the reply, swap_hi/swap_lo form a 64-bit swap count value
>> 	when the swap will actually occur (e.g.  the last queued swap
>> 	count + (pending swap count * swap interval)).
>
> I'm not sure exactly what SBC is meant to be. Is it a simple seqno of
> the SwapRegion in this Drawable's swap queue (why then does
> swap_interval matter), or is it meant to correlate with the vblank
> counter (in which case it is merely a predicted value)?

Just like DRI2, it's the planned swap time. Don't be late!

-- 
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/20130220/55be26eb/attachment.pgp>