Finally A Discussion Is Back Concerning FreeSync / Adaptive-Sync / VRR DRM Support
While AMD has plumbed in FreeSync variable-rate refresh support with their AMDGPU DC display code stack, it's not yet all happy on the open-source mainline kernel as the missing piece has been over having a unified API for the Direct Rendering Manager drivers that can be used for supporting Free-Sync or the VESA-approved AdaptiveSync or HDMI VRR (Variable Refresh Rate). The discussion over having this common API for DRM drivers is back to being discussed.
Harry Wentland of AMD reignited the discussion over a render API to support Adaptive-Sync/VRR that could be supported by the different drivers rather than just designing an interface that would be exclusive to AMDGPU DRM. (AMDGPU-PRO has offered such a sole driver focused interface.) For those not paying attention to FreeSync / Adaptive-Sync / VRR, the goal is for allowing monitor refresh rates to be dynamically controlled without needing any mode change with a focus on reducing stuttering, tearing, and input lag. While FreeSync is specific to AMD branding, Adaptive-Sync and VRR are the cross-vendor standards.
The original proposal by Harry is to have new API entry points for indicating if a CRTC is compatible with these variable refresh technologies and then a target_frame_duration_ns. That target frame duration interface could be used for user-space to tell the driver to send a new frame to the driver as soon as it's ready or rather if there is a desired frame duration every so many nano-seconds.
An Intel developer was quick to propose having an interface where the minimum and maximum refresh rates would be exposed. This developer, Manasi Navare, already has some experimental patches she is about ready to send out.
Other AMD developers have also chimed in that over the original proposal, they would prefer seeing a time-based presentation interface rather than a fixed number of nanoseconds for targeting each frame. As was also noted on the list, a target presentation time would also be beneficial for multi-monitor setups with Adaptive-Sync/VRR for ensuring all the displays could flip at approximately the same time.
The new discussion is happening in this thread, but as of writing there is still nothing close to a consensus yet over a common DRM interface for supporting Adaptive-Sync/VRR, with there even being some disagreement between AMD developers.
It's too late for this interface to come for Linux 4.17 and would need to be quickly squared away in the next few weeks if it's to land for Linux 4.18, so unless that happens, it's pushing towards Linux 4.19 at least before this API could be supported by the drivers and where open-source users could finally be enjoying FreeSync/Adaptive-Sync/VRR on a fully open and mainline driver stack.
Harry Wentland of AMD reignited the discussion over a render API to support Adaptive-Sync/VRR that could be supported by the different drivers rather than just designing an interface that would be exclusive to AMDGPU DRM. (AMDGPU-PRO has offered such a sole driver focused interface.) For those not paying attention to FreeSync / Adaptive-Sync / VRR, the goal is for allowing monitor refresh rates to be dynamically controlled without needing any mode change with a focus on reducing stuttering, tearing, and input lag. While FreeSync is specific to AMD branding, Adaptive-Sync and VRR are the cross-vendor standards.
The original proposal by Harry is to have new API entry points for indicating if a CRTC is compatible with these variable refresh technologies and then a target_frame_duration_ns. That target frame duration interface could be used for user-space to tell the driver to send a new frame to the driver as soon as it's ready or rather if there is a desired frame duration every so many nano-seconds.
An Intel developer was quick to propose having an interface where the minimum and maximum refresh rates would be exposed. This developer, Manasi Navare, already has some experimental patches she is about ready to send out.
Other AMD developers have also chimed in that over the original proposal, they would prefer seeing a time-based presentation interface rather than a fixed number of nanoseconds for targeting each frame. As was also noted on the list, a target presentation time would also be beneficial for multi-monitor setups with Adaptive-Sync/VRR for ensuring all the displays could flip at approximately the same time.
The new discussion is happening in this thread, but as of writing there is still nothing close to a consensus yet over a common DRM interface for supporting Adaptive-Sync/VRR, with there even being some disagreement between AMD developers.
It's too late for this interface to come for Linux 4.17 and would need to be quickly squared away in the next few weeks if it's to land for Linux 4.18, so unless that happens, it's pushing towards Linux 4.19 at least before this API could be supported by the drivers and where open-source users could finally be enjoying FreeSync/Adaptive-Sync/VRR on a fully open and mainline driver stack.
30 Comments