https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #1 from Damien dherault@hotmail.com --- Created attachment 121219 --> https://bugs.freedesktop.org/attachment.cgi?id=121219&action=edit 7950 correct 144Hz.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #3 from Damien dherault@hotmail.com --- Created attachment 121221 --> https://bugs.freedesktop.org/attachment.cgi?id=121221&action=edit 290X Bad 144Hz

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #5 from Damien dherault@hotmail.com --- Created attachment 121223 --> https://bugs.freedesktop.org/attachment.cgi?id=121223&action=edit 290X Grub Glitche

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #7 from Damien dherault@hotmail.com --- Created attachment 121225 --> https://bugs.freedesktop.org/attachment.cgi?id=121225&action=edit 290X Bad 144Hz Kde Line

https://bugs.freedesktop.org/show_bug.cgi?id=93826

Damien dherault@hotmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #121219|0 |1 is obsolete| |

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #8 from Damien dherault@hotmail.com --- Created attachment 121226 --> https://bugs.freedesktop.org/attachment.cgi?id=121226&action=edit Dmesg

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #10 from Damien dherault@hotmail.com --- Created attachment 121228 --> https://bugs.freedesktop.org/attachment.cgi?id=121228&action=edit Xorg.log

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #12 from Damien dherault@hotmail.com --- I've test to make a new mode : xrandr --newmode "2560x1440_144.00" 808.75 2560 2792 3072 3584 1440 1443 1448 1568 -hsync +vsync

But same issue.

Works with FGLRX @144Hz.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #14 from Damien dherault@hotmail.com --- Grub uses the old VGA driver and can not handle the 290x @144hz. It's the same issue with the opensource which works correctly only @60 Hz... I fixed the problem by forcing a resolution with grub.

But impossible to solve the issue with the xf86-video-ati driver. Also tried the git version.

Remember, no issue with windows & linux with Catalyst fglrx driver so I do not trust a hardware issue. There must be a différence in refresh rate management if catalyst wedge to 144Hz immediately after installation while the opensource driver made a bizarre 139Hz with artifacts (see attachments).

Can be an important point to clarify: I use DisplayPort 1.2.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #16 from Alex Deucher alexdeucher@gmail.com --- *** Bug 94315 has been marked as a duplicate of this bug. ***

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #18 from Damien dherault@hotmail.com --- Alex thank you for your return.

Since my monitor works from scratch with a 7950 or fury but not with three 290X tested, is that it is possible to retrieve the values that work ?

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #20 from Damien dherault@hotmail.com --- Hi Alex. I understand better.

Unfortunately I'm not an expert. Can you offer me a PKGBUILD Patch or tell me what value i need change in atombios.crtc.c and what to put there?

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #22 from untoreh bassobassista@gmail.com --- I have a 290, monitor benq xl2411t.

Pushing high resolutions both in grub or xorg file produces glitches. They are very noticeable at 120/144hz less noticeable at 100hz but still present. They appear if I set `video=1920x1080@120` option at boot time, or add a modeline with cvt in a xorg .conf file.

However if I remove the modelines from the conf file and just do a `xrandr -r 100/120/144` I have no glitches at all with any resolution.

Setting a modeline with `cvt -r` also works, of course the only other mode possible is 120 because it requries multiples of 60 but it has 0 glitches and it works even buy setting it in the .conf file

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #24 from Pavel Bordukov pa5hgan@inbox.ru --- Confirm, 120Hz works, but my OSD shows 2560x1440 @ 119Hz. Also as at 144Hz with glitches: 2560x1440 @ 139Hz.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #26 from Jan Niklas Hasse jhasse@gmail.com --- The same for me with a R9 380 and a ASUS MG278Q.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #28 from Yves W. yves.weber@yahoo.de --- bah all got displaced, here again my little benchmark :)

tomb raider v.1.1.1 benchmark: ----------------------------- FPS: min | max | avg. ------------------------------------------------- radeon: 97.4 | 145.4 | 123.4 amdgpu-pro 16.30.3-315407: 50.5 | 94.9 | 79.8

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #29 from Michel Dänzer michel@daenzer.net --- (In reply to Yves W. from comment #27)

• with default driver and default kernel (Linux Mint 18 -> 4.4.0-38-generi)

it's working at 2560x1440 @144hz, no flickering issues.

-> tried using the Ubuntu 4.8.0 kernel -> flickering at 2560x1440 @144hz,120 and 100hz. only 60hz works without flickering

Can you bisect, or at least narrow down which version between 4.4.0 and 4.8.0 introduced the problem?

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #31 from Yves W. yves.weber@yahoo.de --- (In reply to Michel Dänzer from comment #29)

(In reply to Yves W. from comment #27)

...

• with default driver and default kernel (Linux Mint 18 -> 4.4.0-38-generi)

it's working at 2560x1440 @144hz, no flickering issues.

-> tried using the Ubuntu 4.8.0 kernel -> flickering at 2560x1440 @144hz,120 and 100hz. only 60hz works without flickering

Can you bisect, or at least narrow down which version between 4.4.0 and 4.8.0 introduced the problem?

as I said, I only tried current linux mint Kernel which is 4.4.0-38-generic right now. With that one AND the default radeon driver module for amd card R9 290 4GB, I have no problems at all. I can do 2560x1440 resolution @ 144hz. Second I upgradedm, as I posted, to the ubuntu kernel 4.8.0 from ubuntu ppa, which gives errors (strong flickering in 2d mode, 3d works at some point but also gives few flickering problems) WITH 2560x1440 resolution, for all hz above 60hz (which means flickering at 100,120 and 144)

Furthermore the amd beta driver amdgpu-pro gives in every kernel I tried (4.4 and 4.8) flickering problems with refreshrates above 60hz. -> but here note: I switched ( with kernel 4.4.0-38-generic + amdgpu-pro 16.30.3-315407) to 1080p resolution and 144,120 and 100hz gave NO errors at all, which means no flickering! Dunno why. maybe an 1440p issue.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #33 from Yves W. yves.weber@yahoo.de ---

But that's still using the radeon driver, right? If so, it's possible to narrow down the exact kernel version where the problem was introduced, or even the exact Git commit using git bisect.

Yes the original module that used by default - so radeon driver. The info with amd-gpu-pro driver was just additional info :) it's still beta.. and fps as much worse than using the radeon driver.

Sorry, but I don't know what you mean by "using bitsect".

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #35 from rodhos92@gmail.com --- Same issue with R9 270X and Ubuntu 14.04 (open source drivers only), 16.04 and 16.10

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #37 from Jan Niklas Hasse jhasse@gmail.com ---

Sorry, but I don't know what you mean by "using bitsect".

Changes to the source code of the driver are controlled via Git as commits. Assuming it once worked 144 Hz it's possible to use Git to find out which commit caused the flickering. This is done by identifying any commit which worked (good, in your case 4.4) and a commit which doesn't work (bad, 4.8). Bisecting will then help you find the first bad commit faster (by sectioning the pool of possible first bad commits in two sections repeatedly).

I'm not sure though that this good commit exists though. Flickering also happens with 4.4 for me.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #39 from Christian König deathsimple@vodafone.de --- (In reply to Yves W. from comment #38)

means i have to try manually each step and recompile kernel? But that will take ages :) I don't have that much time.

No git bisect will do this automatically for you.

Additional to that you don't need to compile every commit in the range. It simply does a binary search, reducing the number of compiles to something close to square root of the number of commits.

That's usually quite handleable.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #41 from iuno@posteo.net --- I just downloaded and tried with a Linux Mint 18 image. Using kernel 4.4.0, the problem definitely DID exist back then, in contrast to what comment #0 suggested. So bisecting from 4.4 would be useless.

Are the DCEs affected by firmware files? Is it possible that the problem was pulled in from there?

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #43 from Alex Deucher alexdeucher@gmail.com --- firmware is not involved with DCE.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #45 from DesiOtaku tej.ashok.shah@gmail.com --- I can confirm this bug also affects A12-9800E APU when you use the integrated graphic card's port.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #47 from Eike e_geba02@wwu.de --- This problem also occurs on certain graphics & monitor driver combinations on Windows and is according to the linked thread a firmware problem of the Asus MG279Q. This almost only happens with GCN2 AMD cards.

There seems to exist a fix for this since a few weeks, which can only be applied by Asus' service centers. So if you have this monitor and experience these problems, try RMAing the monitor. I am currently waiting for my replacement monitor. I will tell you if it worked, when it gets here.

Thread archive: https://rog.asus.com/forum/archive/index.php/t-87817.html The active thread is linked at the top of the archive.

Also, please give feedback to the ASUS display team in the linked thread if RMA did or didn't work out for you.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #49 from Rodhos rodhos92@gmail.com --- My monitor is Samsung SyncMaster 2032BW. It happens after Ubuntu changing the default drivers.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #51 from Eike e_geba02@wwu.de --- I just received my replacement MG279Q, here is what changed and what didn't. The monitor OSD still reports 139Hz instead of 144, BUT all artifacts (vertical lines) are gone.

So to everyone who has these issues ( comment #50 ) with an Asus MG279Q, I recommend RMAing the monitor with a description of your issues. I don't know if the fixes are incorporated into the standard firmware already or if Asus only applies them if you ask for it.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #53 from Jonas jojonintendo@tutanota.com --- Try the patches provided at the end of this thread: https://bugs.freedesktop.org/show_bug.cgi?id=96868

For me it fixed the issue completely.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #55 from iuno@posteo.net --- (In reply to Pavel Bordukov from comment #54)

Doesn't work for me. Linux 4.11.3, R9 290x, Asus MG279Q, 144Hz has flickering and dirty picture. 120Hz works well.

I have a similar setup. Can you try what I posted above?

Make sure to raise the DC clock above the default value, e.g. to 625 MHz (value 62500)

If you use amdgpu: in amdgpu_atombios.c adev->clock.default_dispclk If you use radeon: in atombios_crtc.c rdev->clock.default_dispclk

That should fix the broken image. To fix flickering, set mclk to high (echo 1 > /sys/class/drm/card0/device/power_dpm_force_performance_level)

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #57 from withoutaface mkyahoooo@web.de --- (In reply to iuno from comment #55)

Make sure to raise the DC clock above the default value, e.g. to 625 MHz (value 62500)

If you use amdgpu: in amdgpu_atombios.c adev->clock.default_dispclk If you use radeon: in atombios_crtc.c rdev->clock.default_dispclk

That should fix the broken image. To fix flickering, set mclk to high (echo 1 > /sys/class/drm/card0/device/power_dpm_force_performance_level)

Hello iuno, is there a easy way to achieve setting clock.default_dispclk to 625 Mhz? like setting dpm performance level to high?

I'm using radeon open source driver with Asus R9 390X / MG279Q on Ubuntu 17.04. 120hz is working fine with dpm performace level high. 144hz has blurry image and one faulty line on the left side

Thank you.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #59 from iuno@posteo.net --- (In reply to Eike from comment #56)

Sorry to correct you, but my monitor has not been faultier than any other MG279Q that was bought before 2017.

Mine is bought before 2017 and it ain't broken.

BTW I have tried the mclock increase before RMAing my monitor and it did not work at all.

Because raising the mclk only helps for the other problem with too low voltage resulting in flickering, not the broken image.

Please differentiate between the artifacts I described (left half of the screen is offset to the right, a vertical stripe that should be in the middle is displayed at the left side of the screen) and other artifacts which could in fact be caused by a low mclock or other problems.

I do differentiate but I have to admit that I didn't read the ROG thread and realise others had this problem on Windows. Also, I didn't say your monitor or others might not be broken, I just said that there certainly is a software problem.

I've had the exact same artefacts you had but never(!) on Windows, neither on Windows nor Linux using Intel GPU. So it's easy enough to reduce it to the free drivers. I asked for help and agd5f suggested to raise the display clock (inside the GPU). It solves the problem entirely for me and others (as seen above).

Don't get me wrong, I don't question your experiences and I believe you had the same problem on Windows and a new Monitor fixed it for you. But I don't think suggesting people to send back their hardware when there is a software problem to be fixed is the right way to handle this.

The described artifacts might be fixable by software (e.g. Windows with certain driver combinations does show these artifacts, but does not with others), but ARE CAUSED by the faulty MG279Q firmware.

I have to disagree when doing nothing(!) but raising the clock of the display engine inside the GPU resolves the problem. The clock is too low on default which results in wrong timings, that's all.

Also, yours is running at 139 Hz, which is not a supported mode at all nor is it meant to do that, so you might be bothered about it but you still have a problem. It should run at 144 and mine does on Windows, it does with Intel, it does with the dispclk fix.

I have not found any combination of OS and drivers that caused these problems on the fixed monitor, but found several on multiple "not fixed" MG279Qs in the past.

Now what I find interesting and what we should focus on imho is the question why a new firmware resolves the issue (partly). Maybe they changed the modes/timings resulting in different GPU behaviour.

Could you provide your EDID as I'm really wondering?

----------

@withoutaface: You have to rebuild your kernel. It is not hard to do but if you're not familiar with that, tell us which distribution you are using and someone might help you.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #61 from Pavel Bordukov pa5hgan@inbox.ru --- (In reply to Alex Deucher from comment #60)

Created attachment 131983 [details] [review] possible fix

It works for me (MG279Q, R9 290x, vanilla 4.11.4, echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level), thanks! But temperature of the card has jumped up from 50C to 70C.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #63 from Alex Deucher alexdeucher@gmail.com --- (In reply to iuno from comment #62)

It works for me, too, but I already said that ;-)

However, the problem Pavel describes is another bothersome issue. PowerPlay changes to the higher memory DPM state which results in ~40 Watts (Hawaii; estimated from memory, have to measure and confirm again) more power draw. The higher DPM state is required, otherwise the flickering appears. On Windows, this isn't the case and WQHD at 144 Hz works with the low memory clock. I assume they raise the voltage independently to the clock in that case to maintain stability.

Are you forcing the power state to high? The mclk shouldn't be affected by the display clock.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #65 from Alex Deucher alexdeucher@gmail.com --- (In reply to iuno from comment #64)

(In reply to Alex Deucher from comment #63)

...

Are you forcing the power state to high? The mclk shouldn't be affected by the display clock.

No, setting the refresh rate to 144 results in high mclk, even when I set power_dpm_force_performance_level to low or pp_dpm_mclk to 0. Using 120 Hz, I could echo 0 or 1 to pp_dpm_mclk. I also got the power meter on now:

memory dpm state 0 (150 MHz): 77 watts memory dpm state 1 (1250 MHz): 112 watts

So there is a difference of 35 watts. Using Windows, I'm below the 80 Watts even with 144 Hz.

Yes, that is independent of the patch in attachment 131983. The driver disables dynamic mclk switching for refresh rates above 120 hz to avoid flickering.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #67 from Alex Deucher alexdeucher@gmail.com --- (In reply to iuno from comment #66)

(In reply to Alex Deucher from comment #65)

...

Yes, that is independent of the patch in attachment 131983 [details] [review] [review]. The driver disables dynamic mclk switching for refresh rates above 120 hz to avoid flickering.

Yes, I know it prevents flickering. Comment #62 was a reply and I mentioned this as *another* problem (high power draw), independent from the fixed one.

Do you get flickering at 144Hz without forcing the mclk to high? I.e., without these patches: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...

Do you know how this works on Windows? Do they increase voltage without raising clocks and could this be an option for amdgpu too?

It's not the mclk frequency or voltage, it's the blanking period for the display timing, it's apparently too short on some monitors at very high refresh rates for the mclk to finish switching in time. If part of the mclk switch happens outside of the vblank period, you end up with flickering or other display artifacts.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #69 from withoutaface mkyahoooo@web.de --- (In reply to iuno from comment #59)

@withoutaface: You have to rebuild your kernel. ...

I rebuild my kernel 4.10.0-22 (ubuntu 17.04) and patched radeon driver (atombios_crtc.c) void radeon_atom_disp_eng_pll_init(struct radeon_device *rdev) { /* always set DCPLL */ rdev->clock.default_dispclk = 62500; if (ASIC_IS_DCE6(rdev)) ...

144Hz is working fine with this patch. (Forcing dpm state high = perfect image / low or auto = bad flickering) But Great improvement so far! Thank you.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #71 from Eike e_geba02@wwu.de --- Sorry, I didn't want to get defensive. I guess you are right about the drivers, it was just funny to me that I had the same issue on Windows 10 with the AMD drivers provided by Windows Update on install. There seems to be a problem with the drivers that does not affect all 144hz monitors and can (in the case of the Asus MG279Q) be worked around by monitor firmware. I don't know how the firmware might change the gpu's dc clock though.

I attached my verbose xrandr output including EDID.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #73 from Eike e_geba02@wwu.de --- (In reply to iuno from comment #72)

Another, slightly off-topic, question: the VertRefresh value shows the FreeSync range for my display (35-90), your values are 50-144, does that mean you can actually use FreeSync inside that range?

I've never tried using FreeSync on Linux, and I only very rarely do so on Windows. With standard drivers on Win10, the range still is 35-90hz. The range can be moved and extended (up to 60-144) using CRU or modded drivers on Windows though. I don't know if Asus actually wants/wanted to extend the range and someone who knows FreeSync better might get this to work. You could ask in the ROG forums, there are other people using the new firmware.

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #75 from Emma Stott emmastott@gmail.com --- (In reply to kees.aarts1 from comment #74)

I have come here since my first git bisect learned me that commit 09be4a5219610a6fae3215d4f51f948d6f5d2609 causes problems on my system. I have a RX 460 and LG 38UC99-W and 3840x1600 @ 60hz gives no problem

Running at 75hz (freesync) worked fine on 4.12-rc2 (I used 4.12 since at 4.11 or lower I could not use the displayport at all and was limited to 30hz via hdmi). But rc3 and up gave me flickering at the lowest +-7cm of the screen if something changes on the screen. A git bisect brought me to the commit mentioned above.

echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level fixes the problem on 4.12-rc6 echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level also fixes the problem (did not expect that) echo auto > /sys/class/drm/card0/device/power_dpm_force_performance_level gives flickering..

I'm having exactly the same problem as described by kees.aarts1.

- CPU: AMD Ryzen 7 1700X - GPU: ASUS RX 470 (4 GB) - Monitor: Acer XR341CK monitor, 3440x1440 @ 75 Hz, with support for Adaptive Sync/FreeSync - uname -a: Linux winters-pc 4.11.9-1-ARCH #1 SMP PREEMPT Wed Jul 5 18:23:08 CEST 2017 x86_64 GNU/Linux

When I set the display to 75 Hz I start to experience flicker primarily in the bottom third of the display. The issue goes away if I set the refresh rate to 60 or lower.

This issue first occured with with kernel 4.11.4. I'm now on 4.11.9 and it's still happening.

Running the command kees.aarts1 suggested resolves the issue until the next reboot:

echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

I'm a bit of a Linux newbie so I apologise if I've missed anything that might be helpful. Please let me know what commands/logs/etc. you'd like me to gather and I'll be happy to do so.

Thanks!

https://bugs.freedesktop.org/show_bug.cgi?id=93826

Emma Stott emmastott@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|RESOLVED |REOPENED

https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #78 from Scott Moreau oreaus@gmail.com --- This also happens to me exactly as described in comment #75 when running a freesync monitor @75Hz. The problem is fixed with high or low dpm setting as in the comment, auto setting has the problem. This is with kernel Linux desktop 4.20.0-rc1 #1 SMP Wed Nov 7 00:30:18 MST 2018 x86_64 x86_64 x86_64 GNU/Linux

https://bugs.freedesktop.org/show_bug.cgi?id=93826

Martin Peres martin.peres@free.fr changed:

What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |MOVED Status|REOPENED |RESOLVED

--- Comment #80 from Martin Peres martin.peres@free.fr --- -- 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/683.