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

--- Comment #1 from Alex Deucher agd5f@yahoo.com 2012-04-16 08:13:28 UTC --- Sounds like display bandwidth/watermark issues. Does booting with radeon.disp_priority=2 on the kernel command line in grub help? Also does disabling tiling help?

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

--- Comment #3 from Alex Deucher agd5f@yahoo.com 2012-04-16 08:43:47 PDT --- (In reply to comment #2)

radeon.disp_priority=2 seems to have no effect. Perhaps it decreased the frequency between screen blackouts, but my sample size is small and randomness of the timings makes me uneasy to claim so yet. Would it make sense for it to have such effect?

Sure. Setting that option sets the display priority in the memory controller to the highest possible level. If the MC is still having problems keeping up, it may be that your system can't handle a monitor that big.

Alternatively, your monitor may not like the set of pll dividers selected by the driver in this case or spread spectrum settings. You might try setting the RADEON_PLL_PREFER_MINM_OVER_MAXP or RADEON_PLL_USE_FRAC_FB_DIV pll flags in atombios_adjust_pll().

What link speed and number of lanes are being used for that mode? Does the monitor support downspread?

Does the proprietary driver work ok with that monitor?

Is testing with tiling disabled relevant given the problem happens also without X running?

That should be equivalent.

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

--- Comment #5 from Alex Deucher agd5f@yahoo.com 2012-04-16 09:10:51 PDT --- (In reply to comment #4)

...

...

Is testing with tiling disabled relevant given the problem happens also without X running?

That should be equivalent.

Not sure I understand what do you mean by this?

fbdev is linear so that should be equivalent to running X with tiling disabled; so need to test with tiling disabled.

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

--- Comment #7 from Tvrtko Ursulin tvrtko.ursulin@onelan.co.uk 2012-04-17 03:20:39 PDT --- (In reply to comment #3)

Does the proprietary driver work ok with that monitor?

It doesn't. In fact it is even worse than the open source driver which works OK in 1920x1200, while fglrx has the same symptoms there (and at any higher resolution) as open source at 2560x1440.

Where does this finding leads us? According to the specifications (http://www.amd.com/us/products/notebook/graphics/amd-radeon-6000m/amd-radeon...) this resolution over DP should work. Is it possible for the motherboard vendor to mess things up in some way?

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

--- Comment #9 from Roland Scheidegger sroland@vmware.com 2012-04-18 14:21:14 PDT --- (In reply to comment #8)

That's the max theoretical mode supported by the chip. Whether or not you can drive a monitor that big probably depends on the type and speed of dram in your system since the GPU (display controllers, 3D engine, etc.) and the CPU have to share dram bandwidth.

I never really understood this problem, not since the days of sdr. Single channel ddr3-1066 provides roughly 8 times the raw bandwidth of what a 2560x1440 resolution (at 32bpp, 60hz) needs so that should be plenty to serve other MC clients as well (with lesser priority). So what's the problem there, too small buffer size for scanout?

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

--- Comment #11 from Alex Deucher agd5f@yahoo.com 2012-04-20 08:19:54 PDT --- (In reply to comment #9)

I never really understood this problem, not since the days of sdr. Single channel ddr3-1066 provides roughly 8 times the raw bandwidth of what a 2560x1440 resolution (at 32bpp, 60hz) needs so that should be plenty to serve other MC clients as well (with lesser priority). So what's the problem there, too small buffer size for scanout?

I'm just speculating. I suspect it's more of a latency/timing thing than bandwidth. If the request is not there when the LB needs it, it'll run dry.

(In reply to comment #10)

Does the driver know it's memory bandwidth so it could remove modes it cannot drive from the list?

It could and does in some cases and there's even code to check it in the watermark setup although it probably needs a bit of tweaking for APUs. Unfortunately the way the drm is structured makes it hard to do a good job since modesetting is per crtc so you only get a partial picture. I'll talk to the display team and see what they have to say.

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

--- Comment #13 from Tvrtko Ursulin tvrtko.ursulin@onelan.co.uk 2012-04-23 00:49:03 PDT --- Created attachment 60472 --> https://bugs.freedesktop.org/attachment.cgi?id=60472 Xorg log running 2560x1440

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

Alex Deucher agd5f@yahoo.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #60472|text/x-log |text/plain mime type| | Attachment #60472|0 |1 is patch| |

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

--- Comment #15 from Andy Pillip andy@madspunky.net --- I do have the same issue on Gnome 3, Wayland, F22 with an Intel Graphics Chip.

On 3840 I see the flashes quite often, and the screen sometimes turns off completely.

On 2560 it's less flashes, and on 1920 they are gone completely.

I tried different DP connections, because I thought it might be the docking station that has not enough bandwidth, but also the internal miniDP had that issue.

I cannot provide a Xorg log, since I'm using Wayland.

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

--- Comment #17 from Andy Pillip andy@madspunky.net --- This is not a cable issue.

I just figured out that for me the issue only occurs on a dual screen setup.

Now I'm running the 3840 resolution on my external screen while switching off the internal one – without any issues.

Tvrtko, do you have a dual or single setup?