Created attachment 64478 [details] log when performance is slow, prints from 3154.543 and on are when I resize the desktop and back Been trying to get to the bottom of this and am now running with xf86-video-ati module from git so should be able to add some debugging if needed to figure this out. Bootup with 3 screens enabled (left-to-right: 1200x1920 + 2560x1600 + 1200x1920) on Radeon 6850 leads to very slow screen updates. However, changing to just 2 monitors and then back to 3 seems to solve the problem most every time for that session.
Modified the xrandr program to always call XRRSetScreenSize() even when display size stays the same. That allows me to call into xserver and xf86-video-ati without actually any of the parameters. drmmode_xf86crtc_resize() in xf86-vide-ati drmmode_display.c again checks for changes on width+height. Commented that out too. With that in place, if I run xrandr with parameters identical to the existing screen setup after first starting the X-server, performance improves. Originally reported that the slow updates appear only with 3 screens. Have now confirmed that the problem exists with 2 screen setup too, it is just less notiecable. Still cannot find where the code paths are different between slow and fast performance. I traced into calls to evergreen_exa.c while performance is slow. From the looks of it acceleration is on as reported in Xorg.0.log also. Where do I look next?
This isn't an issue with multi-head per se. It's more of an issue with software fallbacks. When there is a software fallback the pixmap where fallback has to be handled has to be migrated into CPU accessible memory and the larger the pixmap, the more data has to be migrated. That's why it's more noticeable when you have a larger desktop.
Yes that makes sense. Thanks for pointing that out. Do you know of any obvious points in the code where this might happen? From my log it seems drivers get loaded appropriately. Somehow this clears itself up after a desktop resizing using xrandr.
(In reply to comment #2) > When there is a software fallback the pixmap where fallback has to be handled > has to be migrated into CPU accessible memory and the larger the pixmap, the > more data has to be migrated. That's why it's more noticeable when you have a > larger desktop. That doesn't explain why switching to a smaller (or supposedly even bigger?) desktop and back, or even just re-setting the (supposedly) same size, seems to improve performance. Submitter, can you attach your xorg.conf file? It seems like you're using rotation, maybe that isn't taken into account correctly for the initial front buffer size: (II) RADEON(0): Front buffer size: 40000K That matches 2560x1600 + 2*1920x1080, not + 2*1080x1920.
Created attachment 65015 [details] 2012_07_31 Xorg.0.log that goes with xorg.conf also attached today. Updated xorg.conf with the exact screen setup that I have (portrait 1200x1920 both on left and ride side of 2560x1600 center screen). Problem remains, it is very clear even in the login window now that has a little animation that is verrrry slow.
Created attachment 65016 [details] 2012_07_31 xorg.conf that goes with Xorg.0.log also attached today.
With current xf86-video-ati Git master, does enabling the following options in /etc/X11/xorg.conf help? Option "AccelMethod" "glamor" Option "ShadowPrimary" Option "TearFree"
Running 7850 these days and center monitor is now 4K resolution. Had been running closed-source driver to get that to work. Have now gone back to xf86-video-ati Git master. With the options Michael suggested runs pretty smooth except for some tearing when playing 4K video on the center screen. Without those options the center screen is not usable. It just shows the desktop background. Windows can be dragged there (the space is accounted for) but are not visible.
I get the same problem as the submitter. Try to run a 3 monitors desktop, but unable to get the 3 monitors working at the same time when using my central monitor at his native 4k resolution. Tried a lot of things as adviced in the comment thread. I am currently running : - Xubuntu 15.04 - Xorg edgers PPA - Self compiled master branch radeon driver - Xorg.conf options : Option "AccelMethod" "glamor" / Option "ShadowPrimary" / Option "TearFree" Depending on the driver version used and the xorg-edgers PPA update or not, I can get : - my central monitor working at 4k while the two others displays scratched fixed image - my two side monitor working while the central 4k monitor displays a fixed image Some ressources : - photo of the "scratched images" : http://bit.ly/1SSDPtx - my latest xorg.conf : http://paste.ubuntu.com/12012614/ - my latest Xorg.0.log : http://paste.ubuntu.com/12012625/ - result of dmesg | grep 'radeon\|drm' : http://paste.ubuntu.com/12012626/ - result of xrandr --verbose : http://paste.ubuntu.com/12012645/ - no errors in /var/log/syslog when running xrandr - more detailed explanations of what I tried on askubuntu : http://bit.ly/1SSE4F0 Note that : - it works on windows, - it works sloooowly with amd binary drivers - with xorg edgers ppa and git version of ati driver, I can't get the two side monitors to work even when decreasing the resolution of the central monitor to 2560x1440.
When reverting to my previous setup (ppa purge xorg edgers and 1.7.5.0 version of radeon driver), I was really surprised to see that everything works fine... When writing the bug report, I triple checked the output of my Xorg.0.log to remove as most as I can warning and errors. I realized then that I wrote one of my monitor corrector DVI-O instead of DVI-0... This correction didn't work with the xorg edgers ppa active and the git version of the driver, but worked correctly with stock ubuntu 15.04 version...
(In reply to Mickaël Perrin from comment #10) > When reverting to my previous setup (ppa purge xorg edgers and 1.7.5.0 > version of radeon driver), I was really surprised to see that everything > works fine... Can you bisect?
Seems we are done here. Works out of the box now, also for Mickaël Perrin after he fixed his typo in xorg.conf
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.