Bug 48772 - Signal unstable over Display Port on 2560x1440 monitor
Summary: Signal unstable over Display Port on 2560x1440 monitor
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-16 08:09 UTC by Tvrtko Ursulin
Modified: 2015-09-22 14:30 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg log running 2560x1440 (65.21 KB, patch)
2012-04-23 00:49 UTC, Tvrtko Ursulin
no flags Details | Splinter Review
DRM related kernel messages (2.89 KB, patch)
2012-04-23 00:52 UTC, Tvrtko Ursulin
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Tvrtko Ursulin 2012-04-16 08:09:16 UTC
AMD G-T56N (Radeon HD 6310) hardware with kernel 3.4-rc3 with a Xorg DDX from 28.03.2012. plus a tiling patch from bug 47765.

Dell U2711 monitor native resolution is 2560x1440 on which Display Port connection is unstable.

I get periodic very brief flashes of vertical noise areas, full screen width, at various vertical positions, but possible always at least roughly the same height. Then the screen goes black for a second, comes back for a while, flashing, or straight back to black and so on. Timings do not look regular, although I haven't actually timed and analysed them.

Bringing the resolution down to 1920x1200 and it works fine.
Comment 1 Alex Deucher 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?
Comment 2 Tvrtko Ursulin 2012-04-16 08:30:32 UTC
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?
Comment 3 Alex Deucher 2012-04-16 08:43:47 UTC
(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.
Comment 4 Tvrtko Ursulin 2012-04-16 08:49:59 UTC
(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?
Comment 5 Alex Deucher 2012-04-16 09:10:51 UTC
(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.
Comment 6 Alex Deucher 2012-04-16 09:11:15 UTC
(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.
Comment 7 Tvrtko Ursulin 2012-04-17 03:20:39 UTC
(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?
Comment 8 Alex Deucher 2012-04-17 06:18:13 UTC
(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.
Comment 9 Roland Scheidegger 2012-04-18 14:21:14 UTC
(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?
Comment 10 Tvrtko Ursulin 2012-04-20 03:43:13 UTC
Does the driver know it's memory bandwidth so it could remove modes it cannot drive from the list?
Comment 11 Alex Deucher 2012-04-20 08:19:54 UTC
(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.
Comment 12 Alex Deucher 2012-04-20 12:01:54 UTC
Can you attach the xorg log and dmesg output with the DP monitor attached?  What's the modeline for the 2560x1440 mode?
Comment 13 Tvrtko Ursulin 2012-04-23 00:49:03 UTC
Created attachment 60472 [details] [review]
Xorg log running 2560x1440
Comment 14 Tvrtko Ursulin 2012-04-23 00:52:30 UTC
Created attachment 60473 [details] [review]
DRM related kernel messages

Is this what you had in mind or would you like something more?
Comment 15 Andy Pillip 2015-09-22 09:42:22 UTC
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.
Comment 16 Grigori Goronzy 2015-09-22 12:37:27 UTC
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.
Comment 17 Andy Pillip 2015-09-22 14:30:12 UTC
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?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.