Announcement

Collapse
No announcement yet.

Using Six Monitors With AMD's Open-Source Linux Driver

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Using Six Monitors With AMD's Open-Source Linux Driver

    Phoronix: Using Six Monitors With AMD's Open-Source Linux Driver

    Linux graphics drivers have come a long way in recent years for both the open and closed-source solutions from AMD, NVIDIA, and Intel. In this Sunday article, a Phoronix reader has shared his experiences in going from failing to setup two monitors under Linux just a few years ago with NVIDIA to now successfully driving six monitors on a single system using the AMD Linux driver...

    http://www.phoronix.com/vr.php?view=MTM3NTM

  • zlatan
    replied
    Question here

    Do any of you have issues using HDMI? I have a primari DVI monitor and a Plasma TV connected on HDMI and for me the picture on the TV seems like it's flickering a bit?! using it as an extended desktop since my monitor is 1680x1050/60Hz and TV is 1920x1080/60Hz. Using OS driver. Set them up with xrandr.

    Leave a comment:


  • Brane215
    replied
    Originally posted by agd5f View Post
    It looks like they all use the same pixel clock (162 Mhz). Make sure you've selected that mode on all the displays. If you've done that and your kernel is new enough, it should work.

    I've just tried it. I popped out XFX's active single-link DP-DV adapter and plugged in passive two-connectors-and-a-wire one. IT WORKS ! YEAH ! For good measure, I tried several different monitor permutations, and it works with all of them. So, all monitors seem to use same pixel clock and driver takes advantage of that fact.

    Only thing is that now during boot, before radeon module gets loaded and activated, I get text only on two out of three monitors, but that's irrelevant for all practical purposes.

    Thanks!

    Leave a comment:


  • agd5f
    replied
    Originally posted by Brane215 View Post
    Yes, but:

    1. I have 3 practically identical monitors- Samsung Syncmasters. One on the right is 204B, central and left are 204BM. Only practical difference is that 204BM has inbuilt small loudspeaker.
    All three monitors run at the same refresh rate, depth and resolution- 1600x1200 32bp 60Hz. Such setup refuses to run without active DP-something adapter on third monitor.

    But ther might be some subtle timing differences between them. I have just noticed that 204B and 204BM are on DVI ports. I'll try to move other 204BM to DVI, and perhaps eliminate possible timing difference. Who knows, then it might work with passive DP-DVI ?
    What matters is the clock (e.g., 162.0MHz). A passive DP adapter basically changes the port to non-DP port.

    Originally posted by Brane215 View Post
    2. Is there some special option that has to be set either in kernel module or xorg driver or does driver optimize PLL useage whenever it can ?
    As long as your kernel is new enough (IIRC the patches when upstream during 3.7), PLL sharing will be enabled whenever possible.

    Originally posted by Brane215 View Post
    3. I've just did "xrandr --verbose --current | grep -A 2 1600x1200"

    here is output for all 3 monitors:

    Timings seem the same on all 3 monitors. Same pixel clock etc. Shouldn't then this work with passive adapter and two monitors on DVI outputs sharing one PLL ?
    It looks like they all use the same pixel clock (162 Mhz). Make sure you've selected that mode on all the displays. If you've done that and your kernel is new enough, it should work.

    Leave a comment:


  • Brane215
    replied
    Originally posted by agd5f View Post
    You can use the same PLL if multiple modes share the same clock. Things like PLL sharing are complex to validate and confusing to users since users may run two or more monitors at the same mode, and then try and change the mode on one of the monitors only to have the driver report that it's not possible due to PLL limitations. AMD only officially supports two non-DP monitors with eyefinity for that reason.
    Yes, but:

    1. I have 3 practically identical monitors- Samsung Syncmasters. One on the right is 204B, central and left are 204BM. Only practical difference is that 204BM has inbuilt small loudspeaker.
    All three monitors run at the same refresh rate, depth and resolution- 1600x1200 32bp 60Hz. Such setup refuses to run without active DP-something adapter on third monitor.

    But ther might be some subtle timing differences between them. I have just noticed that 204B and 204BM are on DVI ports. I'll try to move other 204BM to DVI, and perhaps eliminate possible timing difference. Who knows, then it might work with passive DP-DVI ?

    2. Is there some special option that has to be set either in kernel module or xorg driver or does driver optimize PLL useage whenever it can ?

    3. I've just did "xrandr --verbose --current | grep -A 2 1600x1200"

    here is output for all 3 monitors:

    DisplayPort-0 connected 1600x1200+0+0 (0x5a) normal (normal left inverted right x axis y axis) 408mm x 306mm
    Identifier: 0x55
    Timestamp: 23867
    --
    1600x1200 (0x5a) 162.0MHz +HSync +VSync *current +preferred
    h: width 1600 start 1664 end 1856 total 2160 skew 0 clock 75.0KHz
    v: height 1200 start 1201 end 1204 total 1250 clock 60.0Hz
    --
    DVI-0 connected 1600x1200+1600+0 (0x5a) normal (normal left inverted right x axis y axis) 408mm x 306mm
    Identifier: 0x57
    Timestamp: 23867
    --
    1600x1200 (0x5a) 162.0MHz +HSync +VSync *current +preferred
    h: width 1600 start 1664 end 1856 total 2160 skew 0 clock 75.0KHz
    v: height 1200 start 1201 end 1204 total 1250 clock 60.0Hz
    --
    DVI-1 connected 1600x1200+3200+0 (0x5a) normal (normal left inverted right x axis y axis) 408mm x 306mm
    Identifier: 0x58
    Timestamp: 23867
    --
    1600x1200 (0x5a) 162.0MHz +HSync +VSync *current +preferred
    h: width 1600 start 1664 end 1856 total 2160 skew 0 clock 75.0KHz
    v: height 1200 start 1201 end 1204 total 1250 clock 60.0Hz
    DisplayPort-0 connected 1600x1200+0+0 (0x5a) normal (normal left inverted right x axis y axis) 408mm x 306mm
    Identifier: 0x55
    Timestamp: 23867
    --
    1600x1200 (0x5a) 162.0MHz +HSync +VSync *current +preferred
    h: width 1600 start 1664 end 1856 total 2160 skew 0 clock 75.0KHz
    v: height 1200 start 1201 end 1204 total 1250 clock 60.0Hz
    --
    DVI-0 connected 1600x1200+1600+0 (0x5a) normal (normal left inverted right x axis y axis) 408mm x 306mm
    Identifier: 0x57
    Timestamp: 23867
    --
    1600x1200 (0x5a) 162.0MHz +HSync +VSync *current +preferred
    h: width 1600 start 1664 end 1856 total 2160 skew 0 clock 75.0KHz
    v: height 1200 start 1201 end 1204 total 1250 clock 60.0Hz
    --
    DVI-1 connected 1600x1200+3200+0 (0x5a) normal (normal left inverted right x axis y axis) 408mm x 306mm
    Identifier: 0x58
    Timestamp: 23867
    --
    1600x1200 (0x5a) 162.0MHz +HSync +VSync *current +preferred
    h: width 1600 start 1664 end 1856 total 2160 skew 0 clock 75.0KHz
    v: height 1200 start 1201 end 1204 total 1250 clock 60.0Hz
    Timings seem the same on all 3 monitors. Same pixel clock etc. Shouldn't then this work with passive adapter and two monitors on DVI outputs sharing one PLL ?

    Leave a comment:


  • agd5f
    replied
    Originally posted by newwen View Post
    What's the state of Crossfire support + multimonitor with opensource drivers?
    There is no crossfire support in the open source drivers at the moment.

    Leave a comment:


  • newwen
    replied
    What's the state of Crossfire support + multimonitor with opensource drivers?

    Leave a comment:


  • max0x7ba
    replied
    Works out of the box with Fedora 18

    Originally posted by Brane215 View Post
    I've got my setup to work with DP-VGA adapter on 14.Sept.2011:

    A similar setup with 3 screens with 90? rotation on Radeon HD 5670 and the open source driver on Fedora 18:

    Leave a comment:


  • agd5f
    replied
    Originally posted by Brane215 View Post
    Could you elaborate on that ? Up untl now I thought the bottleneck is in framing circuits, since each frame is just a packet on Displayport while it has to be framed on other outputs ( X pixels in a row in Y rows with certain bit organisation within pixel and timings so it reaches the "phosphor" at exactly right moment).

    Your post implies that actually good PLL is expensive part wrt to silicon area and that ATI has been skimping on PLLs, not framing circuits.

    If so, it would be nice to know how could one drive M identical monitors at identical framerate and resolution with one PLL.

    Had I known how to do it before, it would spare me from much of the headscratching, endless googling, many failed attempts with passive adapters ( basically just a piece of wire and two connectors), suffering with DP-VGA adapter and using the latest addition XFX DP-DVI active adapter.

    Active adapters are not that cheap and adapters for dual-link DVI are outrageously expensive...
    The DP requirement was a major point of all of the initial eyefinity reviews and I've mentioned it on my blog several times. It also says on the product packaging that more than two displays requires additional displays be DP. Having fewer PLLs saves power and die area and most people don't use more than two monitors at the moment. DP runs at a fixed clock regardless of the mode so you can run multiple streams off the same PLL. Non-DP requires a dedicated clock per stream as the clock varies based on the mode. You can use the same PLL if multiple modes share the same clock. Things like PLL sharing are complex to validate and confusing to users since users may run two or more monitors at the same mode, and then try and change the mode on one of the monitors only to have the driver report that it's not possible due to PLL limitations. AMD only officially supports two non-DP monitors with eyefinity for that reason.
    Last edited by agd5f; 05-20-2013, 10:41 AM.

    Leave a comment:


  • RussianNeuroMancer
    replied
    Originally posted by talvik View Post
    -In the old KDE screen settings there is a button hidden in another button that save the config as default
    It's important to not forget to reset this settings or remove krandr config before upgrade to KScreen-based display configuration.

    Leave a comment:

Working...
X