[Mesa-dev] [PATCH 3/3] glx/dri3: Request non-vsynced Present for swapinterval zero.
Mario Kleiner
mario.kleiner.de at gmail.com
Tue Dec 16 21:20:16 PST 2014
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
More information about the mesa-dev
mailing list