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 >
