Initial DRI3000 protocol specs available

[Keith Packard]

Mario Kleiner <mario.kleiner.de at gmail.com> writes:

> On 02/20/2013 09:27 PM, Keith Packard wrote:
>> 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.
>
> Please make this configurable. Tearing makes sense for a game, but for 
> the kind of scientific apps i do, we don't want it to tear ever, or bad 
> things would happen for us. We need it to just flip the frame delayed 
> but vsync'ed and then the app can figure out via the INTEL_swap_events 
> or glXWaitForSbcOML() that a deadline was missed and what to do to
> catch up.


> There's 
> http://www.opengl.org/registry/specs/EXT/glx_swap_control_tear.txt that 
> allows apps to define if they want to tear or vsync on a missed swap 
> deadline.

Oh, that's ugly -- uses negative values for the interval. We could cook
up some suitable 'missed frame' mode parameter to make it match that
extension, and then create a similar EGL extension.

> SBC in DRI2 is the running count of completed swaps for a drawable, ie., 
> current swap count + pending swap count, not the planned swap time. 
> Essentially a reference to a just queued swap via sbc = 
> glXSwapBuffersMscOML(...), so you can use sbc as a unique id for that 
> swap in glXWaitForSBCOML() or to match it up with the sbc in a returned 
> INTEL_swap_event. Very useful, so i guess this should stay 
> backwards-compatible.

That's definitely the plan -- we need whatever parameters are necessary
to implement the relevant GL specs. If we can't do that, it's not useful
to anyone.

-- 
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/5d176750/attachment.pgp>