So this is regarding AMDGPU DAL as it currently exists in https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.7, which from my understanding contains the most up-to-date public-facing iteration of the DAL patch. So I have an HDMI 2.0 4K 60 Hz monitor (Vizio D40u-D1) as my main display connected to an XFX RX 480. I'm using a kernel compiled from the branch listed above. Now the issue I'm having is that I'm stuck at 30 Hz. The RX 480 is capable of driving this monitor at 60 Hz @ 4K, which works under Windows. Trying to switch to 60 Hz either results in no signal, or just 30 Hz again. I had the same issue in the past with the proprietary Linux Nvidia drivers on a 960 GTX I used to own, and after several months, the devs there were able to figure out what the issue is, describe it in a forum post, and get a fix in. See here: https://devtalk.nvidia.com/default/topic/939971/linux/4k-60hz-works-in-windows-not-in-linux/ So what I'm hoping is that a similar fix would work in DAL. I can provide logs on request (not sure to log right now). Thanks!
Is the issue that a 60 hz mode is not available or that a 60 hz mode does not work? Please attach your xorg log, dmesg output and xrandr output. You may need this drm patch: https://lists.freedesktop.org/archives/dri-devel/2016-May/107463.html
I don't have the same monitor but I don't have any problem lighting up with HDMI 2.0 4k 60Hz with Alex's amd-staging-4.7 and the commit from a week ago: commit 4fa58023f62a95e93f82a25cdceb87b19b69b27f Author: Christian König <christian.koenig@amd.com> Date: Mon Oct 17 15:34:07 2016 +0200 reservation: revert "wait only with non-zero timeout specified (v3)" This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9. Otherwise signaling might never be activated on the fences. This can result in infinite waiting with hardware which has unreliable interrupts. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> If you still see this issue please attach xorg log, dmesg and xrandr output, as Alex suggested.
Created attachment 127712 [details] xrandr, dmesg, and xorg logs
Thanks for responding to my ticket! Sorry, I didn't have time to record down all the relevant information until recently. Anyway, the 60 Hz mode is missing completely. I attached the relevant logs to the ticket. I tried updating my clone of the kernel repo up to the commit at the end of this post, but the issue persists. I will try the suggested patch and respond as to whether or not it makes a difference for me. Thanks again! commit 019b84cce0585498430215503a50633d2d6a7fc8 Author: Alex Deucher <alexander.deucher@amd.com> Date: Wed Oct 26 16:41:39 2016 -0400 drm/amdgpu: add support for new smc firmware on tonga Newer tonga parts require new smc firmware. Reviewed-by: Eric Huang <JinHuiEric.Huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Just tried the patch. That added a 60 Hz mode back in, but when I try to switch to it, I get no signal. I can post logs if relevant. Here is my output now from xrandr: Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 16384 x 16384 DisplayPort-0 disconnected (normal left inverted right x axis y axis) DisplayPort-1 disconnected (normal left inverted right x axis y axis) DisplayPort-2 disconnected (normal left inverted right x axis y axis) HDMI-A-0 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 878mm x 485mm 3840x2160 30.00*+ 59.94 59.88 24.00 29.97 23.98 29.94 23.95 4096x2160 59.94 59.88 24.00 29.97 23.98 29.94 23.95 1920x1200 30.00 1920x1080 120.04 120.00 119.88 60.00 59.94 24.00 23.98 1600x1200 30.00 1680x1050 30.00 1280x1024 30.00 1440x900 30.00 1280x800 30.00 1280x720 60.00 59.94 1024x768 30.00 800x600 30.00 720x480 60.00 59.94 640x480 60.00 59.94
I was reminded today that this TV is a bit strange in that 4K @ 60 Hz only works with 4:2:0 chroma, while the common expectation would perhaps be 4:4:4. Perhaps that can help lead to a solution?
The NVidia ticket suggests this might be an EDID issue, with the display saying that it supports 4:2:2 at 4K/60 Hz when in fact it only supports 4:2:0. Or could have been an NVidia driver bug that caused problems when modes for both 4:2:2 and 4:2:0 were available, hard to say. Anyways, seems like if we can get the driver to try 4:2:0 (possibly ignoring the monitor to do so) then it should work at 60 Hz.
Created attachment 128745 [details] dmesg log
Hey i got the exact same issue with a Samsung HU7505 4k60 television using amdgpu on xubuntu 16.04.1/16.10, amdgpu-pro-16.50-362463 drivers work in 4k60 until the display is turned off and then it gives "mode not supported" both the bios and the edid from the display while on crimson 16.12 https://f001.backblazeb2.com/file/nwgat-cdn/misc/xfx-rx460-Baffin-bios.rom https://f001.backblazeb2.com/file/nwgat-cdn/misc/samsung_uhd_colour_YCbCr444-4k60_edid.bin amd-staging-4.7 kernel, made no difference (git pull today) ubuntu 4.10 from kernel.ubuntu.com/~kernel-ppa/mainline/v4.10-rc2/ might also be related to black screen on 4k60 issue i have on windows https://www.reddit.com/r/Amd/comments/5fyy7c/december_tech_support_megathread/dbwa536/?context=3 System Configuration: Motherboard: FM2A88X-ITX+ AMD A88X CPU: AMD A10-7800 Memory: 16GB DDR3 GPU: XFX RX 460 2GB (RX-460P2SFG5) GPU-Z Report: https://www.techpowerup.com/gpuz/details/4qq9n VBIOS: 015.050.000.000.000000 Driver: amdgpu OS: xubuntu 16.04.1 LTS AMD64 or 16.10 AMD64 Display: Samsung UE55HU7505 55" UltraHD (in UHD Colour Mode) Display Cable: Startech Pro Series Metal High Speed HDMI Cable 2M (HDPSMM2M) from samsung manual http://downloadcenter.samsung.com/content/UM/201411/20141127124859330/[ENG]NUDVBEUH-1.111-1015.pdf CEA-861 3840x2160 50Hz 112.500 50.000 594.000 +/+ 3840x2160 60Hz 135.000 60.000 594.000 +/+ 4096x2160 50Hz 112.500 50.000 594.000 +/+ 4096x2160 60Hz 135.000 60.000 594.000 +/+
Created attachment 128746 [details] xorg log
Created attachment 128747 [details] xrandr
Created attachment 128748 [details] amdgpu-pro-dmesg
Created attachment 128749 [details] amdgpu-pro-xorg.log
Created attachment 128750 [details] amdgpu-pro-xrandr.log
(In reply to wiak from comment #9) > Hey i got the exact same issue with a Samsung HU7505 4k60 television using > amdgpu on xubuntu 16.04.1/16.10, amdgpu-pro-16.50-362463 drivers work in > 4k60 until the display is turned off and then it gives "mode not supported" > On pro it might be just DPMS on/off issue or some monitors (this is actually TV where DPMS is usually off by default) or specific issues/customizations like: "Samsung offers a new user-accessible control called [HDMI UHD Color] on its 2014 range of UHDTVs. Instead of expanding the TV’s gamut to fulfil Rec.2020 colour space (we wished), it serves to provide support for up to 4:4:4 chroma resolution with 4K@60p/50p sources, indicating that the 55HU7500′s onboard HDMI 2.0 chip is a full-bandwidth, Level A version. [HDMI UHD Color] has to be enabled manually for each HDMI port where 4K res with 4:2:2 or 4:4:4 reproduction is required, because the chroma information is not auto-detected by the chip Samsung is using." http://www.hdtvtest.co.uk/news/ue55hu7500-201405083761.htm
I am experiencing the same 4K @ 30Hz limit with my RX460 and LG 27UD88-W monitor via a Highspeed HDMI cable. I have enabled HDMI DeepColour on the monitor, needed for the monitor to advertise 4K @ 60Hz. Kernel is stock 4.9.11 on ElementaryOS (Ubuntu 16.04) with the HWE stack.
Created attachment 129853 [details] xrandr + Xorg.0.log + dmesg
If the modes are only in the CEA extension block then this is a core drm issue. The core EDID parser does not handles all of the CEA 4K modes yet. Patches were proposed by several people, but I don't think any of them have gone upstream yet due to various objections and bikeshedding. See: https://lists.freedesktop.org/archives/dri-devel/2016-May/107463.html https://lists.freedesktop.org/archives/dri-devel/2016-October/121434.html https://lists.freedesktop.org/archives/dri-devel/2016-November/122631.html
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/109.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.