[Mesa-stable] [PATCH 3/3] glx/dri3: Request non-vsynced Present for swapinterval zero.

[Mario Kleiner]

On 12/17/2014 05:49 AM, Keith Packard wrote:
> Mario Kleiner <mario.kleiner.de at gmail.com> writes:
>
>> It's just that i need access to both, the old behaviour i described, and
>> the new "drop frame" behaviour, and i need a way to select what i want
>> at runtime via api without the need for easily overwhelmed and confused
>> users to change config files or environment variables. I also always
>> need meaningful and trustworthy feedback, at least for page-flipped
>> presents, about what really happened for a presented frame - was it
>> flipped, copied, exchanged, skipped, or did some error happen?
> Present reports precisely what it did with each frame; flipped, copied,
> or skipped.
>
>> That's why i'd like to have an extension to INTEL_swap_events to also
>> report some new completion type "skipped" and "error" and that one patch
>> 5/5 of mine for mesa reviewed and included, to make sure the swap_events
>> don't fall apart so easily.
> You can use Present events on the target drawable; they're generated to
> whoever requests them, so you don't need to rely on the intel swap
> events alone.

Never thought about that. Could you show me some short example snippet 
of XLib/GLX code how i reliably detect at runtime if Present is present, 
and then enable this? That would probably do for the moment and at the 
same time solve the problem that i don't know how to reliably detect at 
runtime if i'm on DRI2 or DRI3/Present. Making good use of this will 
require separate code-path and a way to select the right one.

It's still important to fix that wraparound handling bug from my patch 
5/5 for INTEL_swap_events.

>> As some kind of stop gap measure one could also think about defining a
>> new vblank_mode to enable the new behaviour instead of the old one.
> I really don't have a good suggestion here, given that we have such a
> limited API available.
>

I thought i just made a suggestion how we could wiggle through it within 
existing api?
And we can define new one for future extensions?

Need to sleep now, thanks
-mario