Mario Kleiner <[email protected]> writes:

> On 02/20/2013 09:27 PM, Keith Packard wrote:
>> Chris Wilson <[email protected]> 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.

-- 
[email protected]

Attachment: pgp50KZpXPpoZ.pgp
Description: PGP signature

_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to