Moving and Scrolling windows was extremely slow with radeonhd-1.2.5_20090506-4be5f71-5.5/-3.1 as if there was no hw accellaration at all. A downgrade has resolved this. used xorg-x11-server-7.4-17.4.1, unichrome-20081229-5.1; distro method: opensuse build service
Created attachment 26144 [details] xorg.conf
Please post the Xorg.0.log from a problematic X session.
Besides the current log there are Xorg.1/2/99.log & Xorg.0/1/2/99.log.old files. How to determine which logs apply to the specified radeonhd version?
(In reply to comment #3) > Besides the current log there are Xorg.1/2/99.log & Xorg.0/1/2/99.log.old > files. How to determine which logs apply to the specified radeonhd version? Look for the string RADEONHD in the logs.
Created attachment 26146 [details] [review] Xorg.0.log.old I hope this is the right log file (It should be because I think that I am booting for the first time with the newly downgraded driver.). Nonetheless some of the other Xorg logs may provide supplementary informations on this issue.
Please add Option "DRI" "true" to the appropriate Device section of your xorg.conf. EXA on r6xx requires DRI to be enabled. I think the driver is silently falling back to no acceleration.
Unfortunately adding the DRI option hasn`t changed anything. Moving in general and scrolling at OpenOffice (works for Konqueror&Konsole) are as slow as without HW accelaration.
Created attachment 26168 [details] updated xorg.conf
Created attachment 26169 [details] xorg.log of corresponding session
You do not have the necessary DRM modules installed. DRM for r6xx is available in linux-2.6.30. The driver can't fall back to software 2D acceleration when DRI is specified but not available.
oops, this time I have used an elder kernel because of a bug in the opensuse specific 2.6.30 kernel. Is there anything else I should take care of / additionally test for since always reinstalling/purging the radeonhd driver is a bit long-winded.
With kernel 2.6.30 and the DRI option set it really works better. However moving a window in front of the background bitmap displayed by kdesktop is still significantly slower than before.
Created attachment 26192 [details] Xorg.0.log kernel 2.6.30, DRI option set
Have now switched to AccelMethod ShadowFB. Interestingly moving and scrolling windows work really fine in ShadowFB-mode with current X-servers as soon and as long as I start a second X-server with DRI in exa mode (former X-servers worked always well with ShadowFB). I can avoid bug 22114 by using ShadowFB. xorg-x11-driver-video-radeonhd-1.2.5_20090506_4be5f71-7.19 xorg-x11-server-7.4-59.3 Unfortunately switching between multiple radeon-X-servers can still lead to an unretractable hang while Google Earth initializes or may desire an explicit chvt if Ctrl-Alt-Fx does not work; sometimes it requires a Ctrl-Alt-Fx followed by a Ctrl-Alt. Running games on a separate X-Server makes sense because they require different resolutions and often require clone instead of xinerama mode (see also bug 20628, bug 20888).
resolved with xorg-x11-driver-video-radeonhd-1.2.5_20090506_4be5f71-7.16.
Unfortunately with xorg-x11-driver-video-radeonhd-1.2.5_20091001_be7216f-2.2 I have again no hardware accelaration (xorg even reports this). Might perhaps be a packaging issue. Please have a look at my attachement.
Created attachment 30212 [details] xorg-noaccelaration.tar
X is reporting that everything is fine. Just in case you're talking about: (EE) AIGLX error: dlopen of /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: cannot open shared object file: No such file or directory) (EE) AIGLX: reverting to software rendering This is expected as support for that doesn't exist yet (hence the lack of said .so file), and it's the domain of Mesa in any case.
now tested in three settings: 1. radeon instead of radeonhd driver (xorg-x11-driver-video-7.4-83.3): scrolling is perfectly smooth 2. xorg-x11-driver-video-radeonhd-1.2.5_20090506_4be5f71-2.13.x86_64: quite good results though window stays flurry during move 3. xorg-x11-driver-video-radeonhd-1.2.5_20091001_be7216f-13.1 almost no hardware accelaration: jerking in wide distances
with xorg-x11-driver-video-radeonhd-1.3.0_20091009_8cbff7b-2.1 again as good as with 2.; radeon is still a bit better.
Please have a look at the radeon driver. It implements hardware accellerated scrolling and moving very well. Interestingly it is sufficient to run a second X-server with radeon to leverage a good radeonhd-scroll-speed even at a high cpu load. This does not apply to moving windows with radeonhd.
xorg-x11-driver-video-radeonhd-1.3.0_20091106_619706-2.1.x86_64 xorg-x11-driver-video-7.4-87.88.1.x86_64
Please do also think about those who do not yet have hardware accellaration enabled for their graphics card as the owners of the Radeon HD 2000 - HD 4000 series. Window scroll and move are basic features that should work everywhere. This should not be hard to implement since the only thing I need to do in order to make scroll and move work for screen :0 is to start another X-server with the radeon driver on display :1 (radeon does not have this problem.).
I have no idea what you are going on about anymore. The original cause of the slowdown was already explained to you and was apparently resolved. The relevant acceleration codes have not been touched in a long time, and you claim the latest package by your distro works. Acceleration fallback when lacking appropriate DRM is already in place. If you think this is broken, investigate and file another bug. Resolving as NOTABUG.
No, it definitely does NOT work. I have definitely erred in reporting that things are better. They never were. The only thing that I did not notice first was that running a second radeon-X-server on :1 can also improve things for :0.
Post your Xorg.0.log and output from dmesg.
Do you need an Xorg.0.log where scroll & move work fast because of a second X-server or one where no such server is running and hence scroll & move are very slow.
?
The DRI is required for accel on r6xx+ and it only works with one Xserver, so starting a second xserver will not get acceleration.
Strange, but true. At me the accellaration only works with a second X server. So what kind of log will you need?
Created attachment 32227 [details] /var/log/Xorg.0.log + without and with second radeon-X I hope this is what you expect. At the beginning scroll&move were slow. After starting a second radeon-X they became fast.
(In reply to comment #31) > Created an attachment (id=32227) [details] > /var/log/Xorg.0.log + without and with second radeon-X > (WW) RADEONHD(0): Falling back to ShadowFB acceleration DRIPreInit is failing. DRM initialization messages should precede that line, but they don't, so there's something wrong with your setup. Post the output of dmesg.
Created attachment 32228 [details] dmesg
OK, the verbosity of your dmesg has pushed pushed what's useful in this case out of the buffer. We need to see the sections where the radeon kernel module is being initialized, and also where X is started.
Does this issue occur with the preferred ati driver (xf86-vide-ati)? If so, please move this to the Driver/Radeon component. Development of radeonhd has pretty much halted and development focus is on the ati driver. Please see http://www.x.org/wiki/radeonhd If the issue does not exist in the ati driver (or if there is no response to this message), this bug will be closed as WONTFIX unless someone contributes a patch.
Closing due to lack of response. Please reopen and move to the Driver/Radeon component if this issue persists with xf86-video-ati
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.