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

[Emil Velikov]

On 17/12/14 05:20, Mario Kleiner wrote:
> 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?
> 
Adding Mathias and Frank Binns to the Cc list.

So taking into account the discussion so far, including Mathias's input
that the official nvidia driver does the same/similar form of cheating:
 - Should we revert on master until a decision(alternative solution) is
available ?
 - Curious if we can have some form of consensus on what the next steps
would be.



Keith,
Any plans on taking a look at patch 4/5 [1] and 5/5 [2] from rev 3 of
the series ? The former is reviewed by Eric while the latter lacks any
comments :'(


Thanks
Emil

[1] http://lists.freedesktop.org/archives/mesa-dev/2014-December/072078.html
[2] http://lists.freedesktop.org/archives/mesa-dev/2014-December/072079.html