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?

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?

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

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

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

I'll have a look.

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

Easy there :), this whole area is very new to me. "Last week" I figured out some things about connector probing, anything on top of that still needs to be learned.

> Does the proprietary driver work ok with that monitor?

I can and will try.

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

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

(In reply to comment #5)

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

so NO need to test with tiling disabled.

(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-6300m/pages/amd-radeon-6300m.aspx#2) this resolution over DP should work. Is it possible for the motherboard vendor to mess things up in some way?

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

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.

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

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

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

Can you attach the xorg log and dmesg output with the DP monitor attached?  What's the modeline for the 2560x1440 mode?

Created attachment 60472 [details] [review]
Xorg log running 2560x1440

Created attachment 60473 [details] [review]
DRM related kernel messages

Is this what you had in mind or would you like something more?

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.

Note that this could also be a cable issue. Bad quality DP cables are prone to cause various display issues. I once had a bad cable that even had trouble driving standard 1080p without dropouts. So maybe just try another cable.

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?

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