On 09/08/16 07:44 PM, Christian König wrote: > Am 09.08.2016 um 12:03 schrieb Michel Dänzer: >> On 09/08/16 06:31 PM, Christian König wrote: >>> Am 09.08.2016 um 10:27 schrieb Michel Dänzer: >>>> On 09/08/16 05:12 PM, Christian König wrote: >>>>> Am 09.08.2016 um 04:44 schrieb Michel Dänzer: >>>>> >>>>>> I was basically thinking out loud that doing this via different modes >>>>>> might be quite natural, *if* games allowed choosing a specific mode. >>>>>> But unfortunately they don't. For the video playback case, how do you >>>>>> envision the video player app communicating the refresh rate of the >>>>>> currently playing video to the kernel? >>>>> Again the kernel doesn't need to know the refresh rate. All the kernel >>>>> needs to know is when to do the page flip. >>>>> >>>>> So coming back to my example of a mode with 1920x1080 and 20-100Hz >>>>> refresh rate a classic modeline would then look something like this: >>>>> >>>>> Modeline "1920x1080_dynamic" 302.50 1920 2072 2280 2640 1080 1083 >>>>> 1088 5735 -hsync +vsync >>>>> >>>>> Note the high vertical total scan lines. Those basically reduce the >>>>> refresh rate from 100Hz (which this mode normally would have) down to >>>>> only 20Hz. >>>>> >>>>> Now what userspace does on each page flip is specifying when this flip >>>>> should happen, e.g. when the frame should be started to be scanned >>>>> out. >>>>> We can either specify this as frame counter + vertical line of the >>>>> previous frame or as something like CLOCK_MONOTONIC (I think I would >>>>> prefer CLOCK_MONOTONIC, but that's not a strong opinion). >>>>> >>>>> In other words you put the whole concept upside down. It's no >>>>> longer the >>>>> kernel which tells userspace when a vblank happened, but rather >>>>> userspace tells the kernel when it should happen (together with the >>>>> frame that should be displayed then). >>>> I guess that could work. Do video players set the VDPAU presentation >>>> time accurately enough for this? >>> Yes, of course. We actually get a precise time stamp from the >>> application and need to calculate on which vblank to display it from >>> that. >>> >>>> This would require extensive changes across the stack though, when more >>>> or less the same result could be achieved by just letting the kernel >>>> know what the current refresh rate is supposed to be, e.g. via output >>>> properties. >>> The problem is that you don't have a refresh rate any more. >> Maybe not below the video decoding API level, but the video player app >> certainly knows the refresh rate? > > Sure, but as I said that isn't a constant refresh rate any more. > > E.g. the refresh rate from the video header doesn't need to be a > multiple of the time a vertical line takes to display. > > This results in sightly different display times for each frame. So you > don't have a constant frame rate any more but rather alternate between > two (or maybe more) different display times for each frame. And do you think we'll be able to program flips that accurately? >>> When we add freesync support we just extend vblank_mode with a new enum >>> to enable it optionally for existing applications. >> "Just"... this will only be possible after the first 3 steps above. > > Checking the present extension again we already got PresentOptionAsync > in there as well. > > So the whole thing boils down implementing a new vblank_mode enume which > sets PresentOptionAsync and then doing the right thing on the X side > with those information. PresentOptionAsync isn't for this. It's for not waiting for the vertical blank period before performing a flip, which may result in tearing. This distinction still applies with variable refresh rate, so this option cannot be re-purposed to distinguish between variable and fixed refresh rate. BTW, the only presentation time we can use for the vblank_mode override is "now" / "as soon as possible". So for that case (which is currently the case for basically all games, and will likely continue to be for the vast majority for a long time), the whole exercise doesn't provide any net benefit over using the existing vblank-based presentation infrastructure and just force-enabling variable refresh rate somehow. Note that I'm not questioning the value of time-based presentation for video playback, and thus the need to implement it. I'm only questioning the point of delaying variable refresh rate for games by gating it on the time-based presentation infrastructure. > I'm going to give the UST option a try with VDPAU, let's see how well > that works and if it is implemented correctly or not. It's not implemented at all yet. BTW, it probably doesn't make sense to add support for time-based presentation to the pre-atomic KMS API. So another item to add to the list is adding support for the atomic KMS API to the DDX drivers. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
