This is a cross post of my feature request on AMD’s GitLab. Describe the problem
Due to licensing restrictions, AMD GPUs are currently limited to HDMI 2.0, which has a maximum bandwidth of 18 Gbps. This limits users to lower max resolutions and refresh rates even when the hardware is capable of HDMI 2.1. DisplayPort works at full advertised capacity, but this doesn’t help users like me who are connecting to TVs that only have HDMI. Describe the new feature behavior My idea involves implementing HDMI 2.1 FRL (Fixed Rate Link) support which will allow the GPU to take advantage of the full 48 Gbps bandwidth that HDMI 2.1 supports. My implementation is based on adapting Intel’s implementation of FRL used in the i915 driver in ARC GPUs. Intel ARC GPU drivers previously relied on built-in DP to HDMI PCONs, but these were added at the dedication of the board vendor and not a mandatory part of the chipset. Intel successfully added native HDMI 2.1 FRL support to their open source driver by repurposing the TMDS clock lane for FRL, which enabled the full 48 Gbps bandwidth. This implementation was merged into the mainline kernel in late 2022 and appears to somehow navigated the HDMI Forum licensing restrictions that currently limit AMD’s drivers. Here is the relevant mailing list discussion: https://lists.freedesktop.org/archives/intel-gfx/2022-November/311389.html The expected behavior would result in AMD GPUs with HDMI 2.1 hardware capabilities to be able to negotiate FRL mode with compatible HDMI 2.1 displays. This would give users access to 48 Gbps bandwidth over HDMI, enabling higher max resolution an refresh rates such as 4k@144Hz and 8k@60Hz. This will NOT enable the full 2.1 spec, however it will provide the bandwidth 2.1 allows for (which I believe is the most important benefit). Describe the target user/application The target user is anyone with an AMD GPU connecting to an HDMI TV or monitor. Just for one, Linux gamers would gravely benefit from this as max refresh rates are greatly limited by HDMI. The existing userspace (compositors, DEs, etc.) should be able to remain untouched. The kernel would simply expose higher max resolutions and refresh rates through the standard DRM interface. This is modeled after how the Intel implementation works, so userspace applications wouldn’t need to know what mode they’re using, they just see the available modes exposed by the kernel. I wouldn’t imagine this feature would break any existing userspace applications given that it only expands the available display modes when 2.1 compatible hardware is detected. How do you plan to validate this feature I am NOT a developer and lack the programming knowledge to test and implement this feature myself. I am proposing this concept based on reading on Intel’s successful implementation, hoping that someone with the ability can validate its feasibility on AMD hardware. I’d imagine it could be validated by testing with various HDMI 2.1 displays and verifying that 4k@144Hz works correctly. Backwards compatibility with 2.0 and earlier displays should be tested to confirm they still work without FRL. Although I don’t think it would be an issue, composites should be tested to make sure they work without modification. Display mode switching and hot plugging should also be tested. Business case This feature would eliminate a major limitation for Linux users with AMD GPUs who want to use HDMI. Given the emerging Linux gaming market, this would be a major step forward for devices such as the Steam machine, which are marketed as living-room style gaming consoles. Furthermore, this would bring AMD GPUs on Linux to closer parity with Nvidia, given that HDMI 2.1 is fully supported on Nvidia’s proprietary Linux driver. This would GREATLY help AMD’s competitive position in the Linux gaming market. Draft of the userspace API No new userspace APIs should be needed. As stated earlier, the existing DRM interfaces would expose the higher bandwidth modes when an HDMI 2.1 FRL capable display is detected. Granted, I am fairly new to display drivers, and I have VERY limited understanding, the two main things I am unsure about are 1. Do AMD GPUs with HDMI 2.1 hardware capability support an architecture that would allow repurposing the TMDS clock channel for FRL in a similar way to Intel? 2. Are there non-hardware obstacles in AMD’s display controller architecture that would prevent adapting Intel’s implementation? I, along with a major portion of the Linux gaming community would very much appreciate it if someone can confirm if this is viable.
