Am 09.04.2018 um 23:45 schrieb Manasi Navare:
Thanks for initiating the discussion. Find my comments below:
On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
Adding dri-devel, which I should've included from the start.
On 2018-04-09 03:56 PM, Harry Wentland wrote:
=== What is adaptive sync and VRR? ===
Adaptive sync has been part of the DisplayPort spec for a while now and allows
graphics adapters to drive displays with varying frame timings. VRR (variable
refresh rate) is essentially the same, but defined for HDMI.
=== Why allow variable frame timings? ===
Variable render times don't align with fixed refresh rates, leading to
stuttering, tearing, and/or input lag.
e.g. (rc = render completion, dr = display refresh)
rc B C D E F
dr A B C C D E F
^ ^
frame missed
repeated display
twice refresh
=== Other use cases of adaptive sync ====
Beside the variable render case, adaptive sync also allows adjustment of
refresh rates without a mode change. One such use case would be 24 Hz video.
One of the the advantages here when the render speed is slower than the display
refresh rate, since we are stretching the vertical blanking interval
the display adapters will follow "draw fast and then go idle" approach. This
gives power savings when render rate is lower than the display refresh rate.
=== A DRM render API to support variable refresh rates ===
In order to benefit from adaptive sync and VRR userland needs a way to let us
know whether to vary frame timings or to target a different frame time. These
can be provided as atomic properties on a CRTC:
* bool variable_refresh_compatible
* int target_frame_duration_ns (nanosecond frame duration)
This gives us the following cases:
variable_refresh_compatible = 0, target_frame_duration_ns = 0
* drive monitor at timing's normal refresh rate
variable_refresh_compatible = 1, target_frame_duration_ns = 0
* send new frame to monitor as soon as it's available, if within min/max of
monitor's reported capabilities
variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0
* send new frame to monitor with the specified target_frame_duration_ns
When a target_frame_duration_ns or variable_refresh_compatible cannot be
supported the atomic check will reject the commit.
What I would like is two sets of properties on a CRTC or preferably on a
connector:
KMD properties that UMD can query:
* vrr_capable - This will be an immutable property for exposing hardware's
capability of supporting VRR. This will be set by the kernel after
reading the EDID mode information and monitor range capabilities.
* vrr_vrefresh_max, vrr_vrefresh_min - To expose the min and max refresh rates
supported.
These properties are optional and will be created and attached to the DP/eDP
connector when the connector
is getting intialized.
Mhm, aren't those properties actually per mode and not per CRTC/connector?
Properties that you mentioned above that the UMD can set before kernel can
enable VRR functionality
*bool vrr_enable or vrr_compatible
target_frame_duration_ns
Yeah, that certainly makes sense. But target_frame_duration_ns is a bad
name/semantics.
We should use an absolute timestamp where the frame should be presented,
otherwise you could run into a bunch of trouble with IOCTL restarts or
missed blanks.
Regards,
Christian.
The monitor only specifies the monitor range through EDID. Apart from this
should we also need to scan the modes and check
if there are modes that have the same pixel clock and horizontal timings but
variable vertical totals?
I have RFC patches for all the above mentioned. If we get a concensus/agreement
on the above properties and method to check
monitor's VRR capability, I can submit those patches atleast as RFC.
Regards
Manasi
=== Previous discussions ===
https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html
=== Feedback and moving forward ===
I'm hoping to get some feedback on this or continue the discussion on how
adaptive sync / VRR might look like in the DRM ecosystem. Once there are no
major concerns or objections left we'll probably start creating some patches to
sketch this out a bit better and see how it looks in practice.
Cheers,
Harry
_______________________________________________
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
