RFC for a render API to support adaptive sync and VRR

[Nicolai Hähnle]

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
>