On 12/17/2014 04:17 AM, Keith Packard wrote:
Mario Kleiner <mario.kleiner...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
