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.
I mean we could of course adjust the frame rate the kernel should
display with each page flip as well, but that certainly isn't how the
hardware is working now.
Mostly the same applies for games as well, e.g. when you render a frame
you usually render it for a certain timestamp.
I can only find the EGL_ANDROID_presentation_time extension providing
exactly this functionality. GLX_NV_present_video looks like it covers
this as well, but it also includes a bunch of other stuff.
I think 0 is a good first approximation of the number of applications
used by an average Linux desktop user which make use of either of those
extensions.
Yeah, I agree that we don't have proper support for this on Linux
desktop at the moment. But this is a chicken and egg problem.
The comment that games render a frame for a certain timestamp was more
on how games usually work internally.
Additional to that are you sure it is such a hassle to implement this? I
mean let us sum up what we need:
1. A representation for the new mode attributes, e.g. minimum and
maximum vertical refresh rate.
This is needed anyway to proper communicate the capabilities of the
display device to userspace.
2. An extension to the page flip IOCTL to specify when exactly a flip
should happen.
As far as I can see that is what your patchset already did. The only
difference is that you wanted to specify a certain vertical blank when
the flip would happen while I would say we should use a monotonic
timestamp (64bit ns since boot) for this.
Right, the patch series you're referring to isn't directly related to this.
3. Expose this new functionality via the X11 Present extension and/or a
corresponding Wayland extension.
I unfortunately haven't pushed on this, but I already noted to Keith on
an earlier version of the present extension that we should use a
timestamps instead of vertical blank counters.
But double checking the present extension, we indeed already have
support for PresentOptionUST in it. So this should already be there.
4. Make use of 3. in the Gallium video state tracker code.
Now we're done for the video playback case, phew!
5. Make use of 3. to implement EGL_ANDROID_presentation_time and/or
GLX_NV_present_video.
6. Make game engines use 5.
(A game engine can know when a frame will be ready for presentation when
it starts rendering it, so I'm not sure this functionality will be very
useful for games)
Also, this doesn't address the case of running (existing) games with
variable refresh rate.
Sure it does. For the current stack without any change a freesync
capable display device just looks like a normal monitor with a high
vertical refresh rate.
You're saying current userspace would just see the maximum vertical
refresh rate as the refresh rate?
I think so. I mean the minimum is usually rather low, e.g. between 20
and 30Hz.
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.
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.
Regards,
Christian.
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
