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

[Mario Kleiner]

On 12/17/2014 04:17 AM, Keith Packard wrote:
> Mario Kleiner <mario.kleiner.de at gmail.com> writes:
>
>> Hmm. For benchmarking i think i'd consider that a mild form of cheating.
>> You get higher fps because you skip processing like the whole gpu blit
>> overhead and host processing overhead for queuing / validating /
>> processing the copy command in the command stream, so the benchmark
>> numbers don't translate very well anymore in how the system would behave
>> in a non-benchmark situation?
> It's still a very useful mode -- imagine wanting the lowest possible
> latency between the user and the display; normally, you process input
> and generate a frame just after vblank, then (if the rendering is really
> quick), end up waiting most of the frame time not doing anything before
> finally updating it at the next vblank.
>
> With vblank_mode=0 and DRI3, you have the ability to try and generate
> another frame before vblank comes; if you manage, then you get that data
> on the screen, rather than the older version.
>
> So, it offers latency closer to the tearing vblank_mode=0 but without
> any tearing.
>
> That's why I did it; the fact that it offers a small performance benefit
> for benchmarks is an unintentional bonus feature.
>

It is a useful mode for some applications, no disagreement here. I can 
think of use cases where i would exactly want to have that, e.g., VR 
stuff with head-tracking -> rendering -> Occulus Rift style display. I 
actually want to tinker with something like that early next year and see 
if i can make use of it.

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?

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.

That's why i think we could (ab)use the swap_control_tear extension to 
implement this behaviour:

swapinterval > 0 - sync to vblank, swap only at most every 
swapinterval'th refresh.
swapinterval = 0 - Don't sync to vblank (PresentOptionAsync), swap 
immediately.

swapinterval < 0 - Do what your current implementation does for 
swapinterval = abs(swapinterval);

The first two would restore consistent behaviour with all other 
implementations.

The last one would implement something at least close to the spirit of 
of swap_control_tear. Although it would be even better to think of some 
extension to the extension so one can select if one really wants 
"tearing if late" as swap_control_tear defines, to squeeze out a few 
more msecs, or rather your tear free "skip old frames" method.

Essentially i'd love to have more control over how this stuff is done, 
and a default behaviour close to what all other implementations do, to 
reduce confusion.

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.

-mario