| What | Removed | Added |
|---|---|---|
| Component | Driver/AMDgpu | DRM/AMDgpu |
| Version | 7.7 (2012.06) | unspecified |
| QA Contact | xorg-team@lists.x.org | |
| Product | xorg | DRI |
| Assignee | xorg-driver-ati@lists.x.org | dri-devel@lists.freedesktop.org |
Please attach the corresponding dmesg output and Xorg log file= .
Created attachment =
125006 [details]
X log with 144hz not working
Created attachment 125007<=
/a> [details]
dmesg of 4.6.3 kernel
| What | Removed | Added |
|---|---|---|
| Attachment #125007 mime type | text/x-log | text/plain |
| What | Removed | Added |
|---|---|---|
| Attachment #125006 mime type | text/x-log | text/plain |
Does forcing the clocks to high or low fix the issue? (as root= ): echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level or echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level=
I think the vblank period is too short at 144Hz for the mclk s= witching.
Neither high or low power_dpm_force_performance_level seems to= make any difference. There is a difference between the 143.9 and 144 option. At 144 the whole sc= reen is displayed between the flickers, such that it is possible to make out wha= ts going on. 143.9 hz is never better than attached picture.
Created attachment 125=
011 [details]
143.9hz picture of screen
Whatever way xvidtune -show gathers modelines does not seem re= liable as I am unable to reproduce the 586.00 line on AMDgpu, although it seemed so initia= lly. Testing old fglrx releases I found that 144hz does not work with 14.50.2. The next release I have where 144hz is working is fglrx 15.10.4 and it seem= s to work with every release there after.
I have the same problem with my Hawaii card and my WQHD 144 Hz= monitor. It is not X related and the effect is visible on the framebuffer console, too. 120 Hz setting does flicker like seen in comment 7. 144 Hz setting has a flickering vertical bar a few pixels wide on the left side, a vertical bar in the center of the screen and overall blurred image. The OSD of the monitor shows that the input is 2568 pixels wide, has a 214 = KHz horizontal and 139 Hz vertical refresh rate. When using with Intel GPU (whi= ch works correctly) it shows 2560 px, 222 KHz and 144 Hz. Tried both radeon (linux 4.7.6) and amdgpu (linux 4.8)
Same here with a RX 480. If I set 144Hz the screen start to flicker, but at 120Hz it works fine. I tried Xorg and Wayland and this issue is present in both. I'm using amdgpu with linux 4.8.10
(In reply to Alex Deucher from comment #4) > Does forcing the clocks to high or low fix the i= ssue? (as root): > echo high > /sys/class/drm/card0/device/power_dpm_force_performance= _level > or > echo low > /sys/class/drm/card0/device/power_dpm_force_performance_= level I did this test and I can confirm that if I set power_dpm_force_performance_level to high or log the flickering stops. So at 144Hz with power_dpm_force_performance_level set to auto there is flickering. With power_dpm_force_performance_level set to high or low this bug is not present.
Yeah, forcing high clock rates seem to fix the flickering issu= e. The problem is actually the memory clock. However, today, without my intervention, the memory clock stays at max (1250 MHz) for high refresh rat= es, while the core clock still goes down to 300, as it should. So this god &quo= t;fixed" indeed. I still have the 144 Hz problem with corrupt image, though.
Thank You comment #11<= /a>. So I had the same problem with my RX 480 8GB, screen artifact at 144Hz (1920x1080). Your command as root did the trick. Thx again :) We should post it in some forum / archWiki !
I get the same behaviour here with my XFX R9 390, latest Arch = Linux and amdgpu driver. Forcing "high" power profile makes it work, but it also r= aises the temps (and probably power draw) too much to my liking. If we could only up the vram frequency but not the core, maybe it would be a more acceptable situation of temps/features.
(In reply to Jonas from comment #14) > I get the same behaviour here with my XFX R9 390= , latest Arch Linux and > amdgpu driver. Forcing "high" power profile makes it work, b= ut it also > raises the temps (and probably power draw) too much to my liking. >=20 > If we could only up the vram frequency but not the core, maybe it woul= d be a > more acceptable situation of temps/features. You should be able to do this eg. on my R9 285 echo manual > /sys/class/drm/card0/device/power_dpm_force_performance_le= vel cat /sys/class/drm/card0/device/pp_dpm_mclk=20 0: 150Mhz * 1: 1375Mhz=20 echo 1 > /sys/class/drm/card0/device/pp_dpm_mclk cat /sys/class/drm/card0/device/pp_dpm_mclk=20 0: 150Mhz=20 1: 1375Mhz * Though it will undo if you change modes or go into DPMS.
(In reply to Andy Furniss from comment #15) > You should be able to do this eg. on my R9 285 >=20 > echo manual > /sys/class/drm/card0/device/power_dpm_force_performan= ce_level >=20 > cat /sys/class/drm/card0/device/pp_dpm_mclk=20 > 0: 150Mhz * > 1: 1375Mhz=20 >=20 > echo 1 > /sys/class/drm/card0/device/pp_dpm_mclk >=20 > cat /sys/class/drm/card0/device/pp_dpm_mclk=20 > 0: 150Mhz=20 > 1: 1375Mhz * >=20 > Though it will undo if you change modes or go into DPMS. I can't apply "manual" mode: "invalid argument". I can'= t see pp_dpm_mclk clocks either.
Oh, OK, I don't know whether that's expected or not on an R9 3= 90
Created attachment 131319 <= a href=3D"attachment.cgi?id=3D131319&action=3Dedit" title=3D"possible f= ix 1/4">[details] [review] possible fix 1/4 Does this patch set help?
Created attachment 131320 <= a href=3D"attachment.cgi?id=3D131320&action=3Dedit" title=3D"possible f= ix 2/4">[details] [review] possible fix 2/4
Created attachment 131321 <= a href=3D"attachment.cgi?id=3D131321&action=3Dedit" title=3D"possible f= ix 3/4">[details] [review] possible fix 3/4
Created attachment 131322 <= a href=3D"attachment.cgi?id=3D131322&action=3Dedit" title=3D"possible f= ix 4/4">[details] [review] possible fix 4/4