Bug 93826

Created attachment 121219 [details]
7950 correct 144Hz.

Created attachment 121220 [details]
7950 correct 144Hz.

Created attachment 121221 [details]
290X Bad 144Hz

Created attachment 121222 [details]
290X Bad 144Hz text glitches

Created attachment 121223 [details]
290X Grub Glitche

Created attachment 121224 [details]
290X Bad 144Hz Login glitche

Created attachment 121225 [details]
290X Bad 144Hz Kde Line

Created attachment 121226 [details]
Dmesg

Created attachment 121227 [details]
Pacman -q

Created attachment 121228 [details]
Xorg.log

No issues on windows @144Hz.

Ok on linux @60Hz only.

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.

grub doesn't use this driver, so there might be a hardware/VBIOS issue. Maybe the other drivers work around that somehow.

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.

Tested with two another 290X and another Asus MG279Q. Same issue. 

Tested with a Fury X : Issue Fixed.

It's a driver bug. Not hardware related.

*** Bug 94315 has been marked as a duplicate of this bug. ***

The pll divider combination that is getting selected doesn't seem to agree with that monitor.  You can try adjusting the algorithm in radeon_compute_pll_avivo() or the pll flags passed to radeon_compute_pll_avivo() in atombios_adjust_pll().

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 ?

(In reply to Damien from comment #18)
> 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 ?

The same algorithm is used on all of those parts.  The only reason there would be different dividers selected would be if the pll limits in the vbios or the reference clock were different.  However, looking at various vbioses for those different asics indicate that the vbios limits are the same for all of them.  I doubt they would be different on your boards.  As such. that combination of dividers seems to be disagreeable to your monitor on that specific hw.  The underlying hw implementation of the pll varies a bit from asic to asic, so the pll selection probably needs to be tweaked a bit for that hw to be stable at that combination as per comment 17.

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?

Same bug here, everything looks like Damien described. R290X + MG279Q at 144HZ.

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

To make it work with grub I added "video=1920x1080MR@120" to finally get no  tty switching overhead.

Confirm, 120Hz works, but my OSD shows 2560x1440 @ 119Hz. Also as at 144Hz with glitches: 2560x1440 @ 139Hz.

I've got the same problem with a

Sapphire R9 390 Nitro
ASUS MG279Q

With Windows/Linux+fglrx, 2560x1440@144Hz work fine

With Linux+open source stack, it defaults to 2568x1440@139Hz with graphical artifacts due to the 2568 width

With AMDGPU PRO 16.10 only 60Hz was possible, haven't tried AMDGPU PRO 16.20 yet

Using the open source stack and switching to 120Hz with xrandr -r 120 does the trick and it runs at 2560x1440@119Hz without glitches, but it isn't optimal.

The same for me with a R9 380 and a ASUS MG278Q.

Same for me. flickering problems @144hz,120hz and even 100hz when using newer kernel (tested 4.8.0 ubuntu kernel) or amdgpu-pro 16.30.3-315407 driver with any kernel


- 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
-> with the amdgpu-pro 16.30.3-315407 driver from amd site, it's always flickering at 2560x1440 @144hz,120 and 100hz. only 60hz works without flickering



system info:
-----------

lshw -c video
-------------
  *-display               
       Beschreibung: VGA compatible controller
       Produkt: Hawaii PRO [Radeon R9 290]
       Hersteller: Advanced Micro Devices, Inc. [AMD/ATI]
       Physische ID: 0
       Bus-Informationen: pci@0000:03:00.0
       Version: 00
       Breite: 64 bits
       Takt: 33MHz
       Fähigkeiten: pm pciexpress msi vga_controller bus_master cap_list rom
       Konfiguration: driver=radeon latency=0
       Ressourcen: irq:50 memory:e0000000-efffffff memory:f0000000-f07fffff ioport:e000(Größe=256) memory:fbe00000-fbe3ffff memory:fbe40000-fbe5ffff
  *-display
       Beschreibung: VGA compatible controller
       Produkt: Hawaii PRO [Radeon R9 290]
       Hersteller: Advanced Micro Devices, Inc. [AMD/ATI]
       Physische ID: 0
       Bus-Informationen: pci@0000:06:00.0
       Version: 00
       Breite: 64 bits
       Takt: 33MHz
       Fähigkeiten: pm pciexpress msi vga_controller bus_master cap_list rom
       Konfiguration: driver=radeon latency=0
       Ressourcen: irq:51 memory:c0000000-cfffffff memory:d0000000-d07fffff ioport:d000(Größe=256) memory:fbd00000-fbd3ffff memory:fbd40000-fbd5ffff

xrandr
------
Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 16384 x 16384
DisplayPort-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 598mm x 336mm
   2560x1440     59.95 + 143.86*  144.00   119.88    99.90




additional info:
---------------
-using driver from ppa:	deb http://ppa.launchpad.net/oibaf/graphics-drivers/ubuntu xenial main
vs.
amdgpu-pro 16.30.3-315407


dpkg -l | grep '^ii' | grep radeon
----------------------------------
ii  libdrm-radeon1:amd64                         2.4.71+git1610040630.a44c9c~gd~x           amd64        Userspace interface to radeon-specific kernel DRM services -- runtime
ii  libdrm-radeon1:i386                          2.4.71+git1610040630.a44c9c~gd~x           i386         Userspace interface to radeon-specific kernel DRM services -- runtime
ii  radeontool                                   1.6.3-1                                    amd64        utility to control ATI Radeon backlight functions on laptops
ii  xserver-xorg-video-radeon                    1:7.7.99+git1609271931.3fc839~gd~x         amd64        X.Org X server -- AMD/ATI Radeon display driver



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

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

(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?

Does forcing the mclk to high help? As root:
echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

(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.

(In reply to Yves W. from comment #31)
> Second I upgradedm, as I posted, to the ubuntu kernel 4.8.0 from
> ubuntu ppa, which gives errors 

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.


> Furthermore the amd beta driver amdgpu-pro gives in every kernel I tried
> (4.4 and 4.8) flickering problems with refreshrates above 60hz.

This report is about the radeon driver, let's not confuse things here by mixing in amdgpu-pro issues.

> 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".

Checked at vanilla 4.4.24, flickering exists. Gentoo unstable, R9 290X.

Same issue with R9 270X and Ubuntu 14.04 (open source drivers only), 16.04 and 16.10

(In reply to rodhos92 from comment #35)
> Same issue with R9 270X and Ubuntu 14.04 (open source drivers only), 16.04
> and 16.10

My resolution is 1680x1050 60Hz when I change to lower resolution the bug is not present.

> 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.

(In reply to Jan Niklas Hasse from comment #37)
> > 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.

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

btw mint 18 kernel updated to 4.4.0-43-generic
It's still working like charm with 144hz @ 1440p - no flickering .. :)

(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.

Is anyone looking into this or are you expecting us to switch over to -pro with dal/dc asap?

I have the exact same problem with both radeon and amdgpu. I don't know if this problem has always existed, it did since I remember. 144 Hz is unusable, so I always went back to 120 Hz.

It works with the Intel iGPU on the exact same monitor, I also checked edid and modelines. It has always worked on windows.

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?

(In reply to iuno from comment #41)
> comment #0

Sorry, comment #27 of course.

firmware is not involved with DCE.

So, any suggestions?
Looks like this only happens in combination with this specific monitor?! I also have the mentioned ASUS MG279Q. But I already tried ignoring edid and force the Modeline, which didn't work.
Doesn't seem we have a "good" state for bisecting either. 
I have no clue about PLL signalling or display hardware programming.

I can confirm this bug also affects A12-9800E APU when you use the integrated graphic card's port.

Same here with my XFX R9 390, latest Arch Linux and amdgpu driver. Forcing "high" power profile makes it work, but it also raises 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.

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.

I have an Asus MG278Q, which is the TN model, and the issue is not the same as explained in the thread you have linked. Under Archlinux what happens above 60Hz is a crazy flickering of almost all screen, which can be triggered by having many windows open, or simply a terminal compiling a kernel (which refreshes very fast). Under Windows I don't have this problem at all, in fact in linux it is possible to workaround it by setting a "high" power mode, but it is not very convenient because of temperatures and power draw.

My monitor is Samsung SyncMaster 2032BW. It happens after Ubuntu changing the default drivers.

(In reply to Jonas from comment #48)

(In reply to Rodhos from comment #49)

Sorry, I should have specified, that i was only talking about the "Lines on the left" part of this report.

The bug I have experienced at 144hz on Win10 without extra drivers AND Archlinux with opensource drivers could be described as follows:
1. One vertical line of noise on the left of the screen, just a few pixels wide.
2. A vertical offset in the middle of the screen with the same width.
   It looks like the left half of the screen just got pushed to the right by the line on the left.
The same can be seen on the last three screenshots in the description (first two show the line on the left, the last shows the offset in the middle).

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.

It could be fixed by increasing the default display clock: https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=radeon&highlight_names=agd5f;grmat&date=2017-01-03


@Eike: you have a faulty monitor, please don't suggest people here to send theirs back because there certainly *is* a software issue.

@Jonas: Did you try forcing the mclock to high? It doesn't require a higher core dpm state but should fix your problem.

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.

(In reply to Jonas from comment #53)
> 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.

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

(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)

(In reply to iuno from comment #52)
> It could be fixed by increasing the default display clock:
> https://people.freedesktop.org/~cbrill/dri-log/index.
> php?channel=radeon&highlight_names=agd5f;grmat&date=2017-01-03
> 
> 
> @Eike: you have a faulty monitor, please don't suggest people here to send
> theirs back because there certainly *is* a software issue.
> 
> @Jonas: Did you try forcing the mclock to high? It doesn't require a higher
> core dpm state but should fix your problem.

Sorry to correct you, but my monitor has not been faultier than any other MG279Q that was bought before 2017. I already had TWO other MG279Qs before this one, both had the problem I described. The ROG forum thread I have linked shows the SAME artifacts I have described and these have definitely been fixed on multiple platforms by the mentioned firmware update.

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

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.

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 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.

(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.

(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)

Confirming that this fixed the issue! MG279Q, r9 290 with amdgpu. Didn't have to touch the mclk.

(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.

Created attachment 131983 [details] [review]
possible fix

(In reply to Alex Deucher from comment #60)
> Created attachment 131983 [details] [review] [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.

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.

(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.

(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.

(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 [details] [review].  The driver disables dynamic mclk switching for refresh rates above 120 hz to avoid flickering.

(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 know how this works on Windows? Do they increase voltage without raising clocks and could this be an option for amdgpu too?

(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]
> > [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/?id=0a646f331db0eb9efc8d3a95a44872036d441d58
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=58d7e3e427db1bd68f33025519a9468140280a75
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09be4a5219610a6fae3215d4f51f948d6f5d2609
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2275a3a2fe9914ba6d76c8ea490da3c08342bd19

> 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.

(In reply to Alex Deucher from comment #67)
> 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/
> ?id=0a646f331db0eb9efc8d3a95a44872036d441d58
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=58d7e3e427db1bd68f33025519a9468140280a75
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=09be4a5219610a6fae3215d4f51f948d6f5d2609
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=2275a3a2fe9914ba6d76c8ea490da3c08342bd19

Yes, I've experienced that before and just tested it again.

> > 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.

I assumed it is related to any voltage because higher sclk helps too. I'll just call sclk/mclk dpm states "sdpm" and "mdpm"

auto (sdpm 0, mdpm 0 or switching through states): very bad flickering and artifacts
sdpm 1-7, mdpm 0: better (still flickering/artifacts, but only when bigger areas on the screen are updated)
sdpm any, mdpm 1: no flickering and artifacts

(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.

Created attachment 132066 [details]
MG279Q (new firmware) xrandr incl. EDID

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.

Created attachment 132082 [details]
parsed EDID from different MG279q

Thanks for that. The new EDID shows in fact other modes and timings, attached are the parsed values for yours and mine. However, while the panel does "just work" with those new timings, the artefacts are still there and I can not observe any enhancement at all. So the "firmware workaround" should go beyond this.

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?

(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.

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..

(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!

This is fixed (as suggested by iono in comment #55 ) as of kernel v4.12-rc7.
Change: https://github.com/torvalds/linux/commit/52b482b0f4fd6d5267faf29fe91398e203f3c230

I am currently using Arch with kernel 4.12.8-2, which contains the fix and everything is fixed for me.

I've just given this another try and unfortunately it's still happening for me, even with the latest kernel:

uname -a: Linux winters-pc 4.12.13-1-ARCH #1 SMP PREEMPT Fri Sep 15 06:36:43 UTC 2017 x86_64 GNU/Linux

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

Just like Scott Mereau posted before I also run into the problem with a FreeSync monitor @75Hz with the default power_dpm_force_performance_level set to auto.

Manually setting it to high works around the problem, with all the nagative impacts going along like higher temperatures and power consumption.

The monitor in question is a Acer Technologies Acer VG270 connected via HDMI:

HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 
  1920x1080     74.97*+  59.96    60.00    60.00    50.00    59.94    59.93

The AMD card is a Radeon RX 570 Series (POLARIS10, DRM 3.27.0, 4.19.4-300.fc29.x86_64, LLVM 8.0.0) (0x67df)

Running following kernel/xorg/mesa combination:

Kernel: 4.19.4-300.fc29.x86_64
xorg-server: xorg-x11-server-common-1.20.3-1.fc29.x86_64
LLVM: compiler-rt-8.0.0-0.1.r347296.fc29.x86_64
mesa: mesa-dri-drivers-19.0.0-0.65.git3c96a1e.fc29.x86_64

Is there any additional information I could provide which could help to identify and work towards a fix?

-- 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.