On 10.04.2018 18:26, Cyr, Aric wrote:
That presentation time doesn’t need to come to kernel as such and
actually is fine as-is completely decoupled from adaptive sync. As long
as the video player provides the new target_frame_duration_ns on the
flip, then the driver/HW will target the correct refresh rate to match
the source content. This simply means that more often than not the
video presents will align very close to the monitor’s refresh rate,
resulting in a smooth video experience. For example, if you have 24Hz
content, and an adaptive sync monitor with a range of 40-60Hz, once the
target_frame_duration_ns is provided, driver can configure the monitor
to a fixed refresh rate of 48Hz causing all video presents to be
frame-doubled in hardware without further application intervention.
What about multi-monitor displays, where you want to play an animation
that spans multiple monitors. You really want all monitors to flip at
the same time.
I understand where you're coming from, but the perspective of refusing a
target presentation time is a rather selfish one of "we're the display,
we're the most important, everybody else has to adjust to us" (e.g. to
get perfect sync between video and audio). I admit I'm phrasing it in a
bit of an extreme way, but perhaps this phrasing helps to see why that's
just not a very good attitude to have.
All devices (whether video or audio or whatever) should be able to
receive a target presentation time.
If the application can make your life a bit easier by providing the
targetted refresh rate as additional *hint-only* parameter (like in your
24 Hz --> 48 Hz doubling example), then maybe we should indeed consider
that.
Cheers,
Nicolai
For video games we have a similar situation where a frame is rendered
for a certain world time and in the ideal case we would actually display
the frame at this world time.
That seems like it would be a poorly written game that flips like that,
unless they are explicitly trying to throttle the framerate for some
reason. When a game presents a completed frame, they’d like that to
happen as soon as possible. This is why non-VSYNC modes of flipping
exist and many games leverage this. Adaptive sync gives you the lower
latency of immediate flips without the tearing imposed by using
non-VSYNC flipping.
I mean we have the guys from Valve on this mailing list so I think we
should just get the feedback from them and see what they prefer.
We have thousands of Steam games on other OSes that work great already,
but we’d certainly be interested in any additional feedback. My guess
is they prefer to “do nothing” and let driver/HW manage it, otherwise
you exempt all existing games from supporting adaptive sync without a
rewrite or update.
Regards,
Christian.
-Aric
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
