|
Description
Rolf Leggewie
2009-05-11 10:04:21 UTC
It would be useful to find what fallbacks you are hitting under EXA. Alex, thank you for the quick response. What do you mean by "fallbacks" and how can I collect the information you are looking for? First of all, make sure the DRI is enabled (see bug 21611). If that doesn't help, please attach the full xorg.conf and Xorg.0.log files. I enabled DRI, disabled XAA and xorg is back to its sluggish self. Furthermore, I now only get a single head on my dual-head setup. I attach xorg.conf and Xorg.0.log. Created attachment 25793 [details]
my xorg.conf
Created attachment 25794 [details]
Xorg.0.log
http://dri.freedesktop.org/wiki/DriTroubleshooting $ dmesg | egrep '(agp|drm)' [ 10.438552] Linux agpgart interface v0.103 [ 12.069499] agpgart-intel 0000:00:00.0: Intel 830M Chipset [ 12.085770] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000 [ 59.768684] [drm] Initialized drm 1.1.0 20060810 [ 59.934077] [drm] Initialized radeon 1.29.0 20080528 on minor 0 $ grep -i "Direct rendering" /var/log/Xorg.0.log (WW) RADEON(0): Direct rendering disabled $ grep EE /var/log/Xorg.0.log (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (II) Loading extension MIT-SCREEN-SAVER (EE) RADEON(0): Static buffer allocation failed. Disabling DRI. (EE) RADEON(0): At least 16735 kB of video memory needed at this resolution and depth. (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory) (EE) GLX: could not load software renderer (EE) Generic Keyboard: No device specified. (EE) PreInit returned NULL for "Generic Keyboard" (EE) ioctl EVIOCGBIT failed: Inappropriate ioctl for device (EE) PreInit returned NULL for "Configured Mouse" -> adding Load "glx" to the modules section and retrying. Created attachment 25795 [details]
Xorg.0.log after loading glx
After loading glx, I now get my multi-monitor setup. Xorg is still sluggish. I guess the missing swrast_dri.so probably has a lot to do with it. Installing the libgl1-mesa-dri package and retrying.
Created attachment 25796 [details]
Xorg.0.log after installing libgl1-mesa-dri
multi-monitor seems to be hit and miss. I was back to single-head after installing libgl1-mesa-dri and restarting X. I restarted X once more and now I am back to multi-monitor. Not sure what the next restart will bring ;-)
In any case, X is still sluggish and I get screen update artifacts. Going back to XAA for now.
(In reply to comment #7) > (EE) RADEON(0): Static buffer allocation failed. Disabling DRI. > (EE) RADEON(0): At least 16735 kB of video memory needed at this resolution and > depth. This is likely your problem. Try reducing the max desktop size using a Virtual directive, or running at a lower depth. (In reply to comment #8) > After loading glx, I now get my multi-monitor setup. Output isn't directly related to GLX/DRI or EXA/XAA, so if anything this is a separate issue. > Xorg is still sluggish. I guess the missing swrast_dri.so probably has a lot to > do with it. Probably not, it's only relevant for GLX. This looks increasingly like a duplicate of bug 21611... (In reply to comment #10) > (In reply to comment #7) > > (EE) RADEON(0): Static buffer allocation failed. Disabling DRI. > > (EE) RADEON(0): At least 16735 kB of video memory needed at this resolution and > > depth. > > This is likely your problem. Try reducing the max desktop size using a Virtual > directive, or running at a lower depth. It does not look like this is possible. Even with Modeline reduced to 1024x768 max this does not work. With 16 bit color depth, DRI is still disabled because about 9MB video RAM are required according to Xorg.0.log. And 8 bit is apparently not supported by DRI. What now? Driver default issue. Created attachment 25890 [details] [review] use XAA in low memory situations or when the DRI is disabled Using shadowfb might also be a viable option, maybe even a better option... Created attachment 25892 [details]
Ubuntu Jaunty radeon_driver.c
Thank you Alex, for the patch. Unfortunately, it does not apply cleanly to the source file for Jaunty or I would have prepared a deb for public testing.
If you think the current proposal is likely to be the best solution, can you please adapt your patch for the attached file?
Wenzhuo Zhang just reported in https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/363238/comments/31 that enabling DRI does not fix the problem for him. His xorg.log is attached in LP. (In reply to comment #15) > Wenzhuo Zhang just reported in > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/363238/comments/31 > that enabling DRI does not fix the problem for him. He has too little video RAM for EXA. Alex's patch should make XAA the default for him. (In reply to comment #14) > Created an attachment (id=25892) [details] > Ubuntu Jaunty radeon_driver.c > > Thank you Alex, for the patch. Unfortunately, it does not apply cleanly to the > source file for Jaunty or I would have prepared a deb for public testing. > > If you think the current proposal is likely to be the best solution, can you > please adapt your patch for the attached file? > The file you attached already defaults to XAA in all cases. Are you sure you attached the right file? I suspect you are missing a patch. As Michel said, the patch selects XAA if the DRI is disabled or if there is limited vram. I think i'm experiencing the same issue with my 4850 (rv770). Latest git build of radeon and drm. DRI set to 0666 in xorg.conf, apart from that not much in it. Everything else debian lenny. With a lot of open windows or some sophisticated ones (heavily loaded websites in firefox) everything starts to become sluggish and slow until it sometimes gets unusable, but anyway it is very annoying. Performance either becomes normal immediately after i closed most of the windows or it stays slow until at some misterious point it is fast again. But radeonhd doesn't have performance issues. I can switch the driver, simply restart X and get perfect performance, therefore i do think it is a radeon issue. Option "AccelMethod" "XAA" doesn't work, i think, since xorg log indicates that EXA is loaded anyway: " (**) RADEON(0): Option "AccelMethod" "XAA" (==) RADEON(0): Will attempt to use R6xx/R7xx EXA support if DRI is enabled. (II) Loading sub module "exa" (II) LoadModule: "exa" (II) Loading /usr/lib/xorg/modules//libexa.so (II) Module exa: vendor="X.Org Foundation" compiled for 1.4.2, module version = 2.2.0 ABI class: X.Org Video Driver, version 2.0 (II) EXA(0): Offscreen pixmap area of 116867072 bytes (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (II) UploadToScreen (II) DownloadFromScreen " Another funny thing is that switching to another virtual desktop (KDE) fixes the performance, until i switch to the crowded desktop again. Please tell me how i can help you fixing this severe problem :) (In reply to comment #18) > I think i'm experiencing the same issue with my 4850 (rv770). No, this report is about a performance regression from XAA to EXA on some setups, whereas XAA has never been supported for your card. > But radeonhd doesn't have performance issues. I can switch the driver, simply > restart X and get perfect performance, therefore i do think it is a radeon > issue. Does radeonhd use EXA as well, with the same set of acceleration primitives and a similar amount of EXA offscreen memory? > Another funny thing is that switching to another virtual desktop (KDE) fixes > the performance, until i switch to the crowded desktop again. Sounds like maybe you're suffering from EXA offscreen memory fragmentation. This has been fixed in xserver Git, the fix will be in the 1.7 release. (In reply to comment #13) > Created an attachment (id=25890) [details] > use XAA in low memory situations or when the DRI is disabled I don't think 32MB is too little. At least I think the ideal solution would be to set FBTexPercent to 0 with let's say less than 64MB. I set it with my Mobility 9000 (32MB) and EXA seems pretty fast for me (opposed to what is was before setting FBTexPercent). So if you know how to check it / do it, I'd propose FBTexPercent 0 for <65535 and XAA for <32768 (not <=). I additionally tested setting DepthBits to 16 which halves the memory usage for that buffer, but didn't notice any specific improvement in this case besides Xorg.0.log stating more memory could be used for EXA. It does generate issues in some 3D stuff but eg. compiz works fine. (In reply to comment #20) > (In reply to comment #13) > > Created an attachment (id=25890) [details] [details] > > use XAA in low memory situations or when the DRI is disabled > > I don't think 32MB is too little. At least I think the ideal solution would be > to set FBTexPercent to 0 with let's say less than 64MB. I set it with my > Mobility 9000 (32MB) and EXA seems pretty fast for me (opposed to what is was > before setting FBTexPercent). > > So if you know how to check it / do it, I'd propose FBTexPercent 0 for <65535 > and XAA for <32768 (not <=). This hurts 3d performance pretty bad though afair. We should actually do the opposite, make ddx only use gart (I don't think it really would make much difference to 2d performance), though I don't think this can easily be done. Or just use some same memory management. > > I additionally tested setting DepthBits to 16 which halves the memory usage for > that buffer, but didn't notice any specific improvement in this case besides > Xorg.0.log stating more memory could be used for EXA. It does generate issues > in some 3D stuff but eg. compiz works fine. I don't think compiz uses depth buffer at all and even if it does it would probably be fine with very few depth buffer bits. Again, the real solution is in better memory management. (In reply to comment #20) > At least I think the ideal solution would be to set FBTexPercent to 0 with > let's say less than 64MB. Unfortunately, the Mesa r300 driver traditionally doesn't support this, as it uses the GART memory for vertex data. Though I'm not sure there are any (discrete) cards this would affect, so it might still be feasible. > I additionally tested setting DepthBits to 16 which halves the memory usage for > that buffer, but didn't notice any specific improvement in this case besides > Xorg.0.log stating more memory could be used for EXA. It does generate issues > in some 3D stuff but eg. compiz works fine. I noticed recently that this option can't really work properly, as the 3D driver doesn't get any information about the depth buffer size being different from the colour depth. The option probably needs to be removed again. Anyway, as Roland pointed out, these are really just hacks to fill the gap until there is proper kernel graphics memory management. Created attachment 26475 [details] fully patched radeon_driver.c as used by Ubuntu Jaunty (In reply to comment #17) > The file you attached already defaults to XAA in all cases. Are you sure you > attached the right file? I suspect you are missing a patch. Alex, you are right of course, I attached the file from the unpacked source. It seems like Ubuntu has three patches on top of this file. The pain may be self-inflicted ;-) Here is the fully patched radeon_driver.c as used by Ubuntu. Created attachment 26476 [details] EXA related patch in Ubuntu Jaunty I believe this is the only relevant Ubuntu patch in this case. I know it's a lot to ask, but can you please rebase your patch (attachment 25890 [details] [review]) on the fully patched Ubuntu source (attachment 26475 [details]) or change the 104_use_exa.patch from Ubuntu in such a way that it works as intended even in low-memory situations? Believe me, I would do it myself if I were capable of it. I'd happily provide some updated packages to the Ubuntu crowd for testing and make sure this gets fixed properly in the Jaunty stable release. Created attachment 26479 [details] [review] untested patch Untested patch against ubuntu version of radeon-driver.c Thank you, Alex. I have integrated that into the latest Ubuntu package and announced the deb package for testing in Launchpad. Hello, i didn't know if I should open a new bug, but I decided to post in this as it is very similar. I'm using xorg 1.4.2 with radeon 6.9 (Debian Lenny 5.0). I have serious 2D performance issues with EXA enabled. The following programs have performance issues: GNOME with openbox as window manager, maximizing and minimizing windows makes Xorg use up to 40% cpu, depending on window. Word 2003 with wine 1.1.22 - Xorg uses 100% cpu while typing. When I use XAA the CPU usage with both programs goes down a lot. But 3D performance is much better with EXA - 10-20 fps difference @ 1280X800 in UrbanTerror! I'm going to add the following attachments: -2 screenshots comparing EXA and XAA, maximizing and unmaximizing a window in GNOME/openbox -2 screenshots comparing EXA and XAA, Word 2003 under wine typing performance -2 Xorg.log EXA and XAA -my xorg.conf Created attachment 26530 [details]
GNOME/Openbox cpu usage with EXA
Created attachment 26531 [details]
GNOME/Openbox cpu usage with XAA
Created attachment 26532 [details]
Word under wine EXA cpu usage
Created attachment 26533 [details]
Word under wine XAA cpu usage
Created attachment 26534 [details]
Xorg.log with EXA
Created attachment 26535 [details]
Xorg.log with XAA
Created attachment 26536 [details]
my xorg.conf
(In reply to comment #27) > I'm using xorg 1.4.2 with radeon 6.9 (Debian Lenny 5.0). Those are rather old, there have been a lot of EXA performance improvements since then, especially in xserver. I found out that Option "FBTexPercent" "99" helps with my performance problem. And EXA was not active in radeonhd... Maybe i'll update once testing has a newer xserver. but for now most of my performance problems are solved thanks to the above option. beware though, 100 renders video playback impossible. Unfortunately, the patch from Alex did not fix the issue on Ubuntu. I still get screen artifacts and a high load for Xorg when scrolling or typing text in a browser entry box. Before I go back to XAA in xorg.conf, I will recompile a package completely without that problematic 104*.patch from Ubuntu to make sure the regression is coming from that bug in Ubuntu and that bug alone. (In reply to comment #37) > Unfortunately, the patch from Alex did not fix the issue on Ubuntu. The purpose of Alex's patch is to make the driver use XAA by default on constrained setups like the one in the X log file you attached originally. Is that not happening? *** Bug 22531 has been marked as a duplicate of this bug. *** (In reply to comment #39) > (In reply to comment #37) > > Unfortunately, the patch from Alex did not fix the issue on Ubuntu. > > The purpose of Alex's patch is to make the driver use XAA by default on > constrained setups like the one in the X log file you attached originally. Is > that not happening? No, it wasn't. The reason the patch wasn't working is not that it's faulty, though. It's just that I only installed the xserver-xorg-video-ati package when the driver for my hardware is xserver-xorg-video-radeon (compiled from the same source package). IOW, I hadn't really installed the fixed package. I tried again today and I'm happy to report that the patch from Alex does indeed fix the issue. The faulty 104 patch meant self-inflicted pain in Ubuntu. I wonder if there is anything to do for xorg itself? Will the driver compiled from stock xorg default to XAA in low-memory situations? committed: f564460e94c9d0f1cf3ff4b8535481b2b8b4e9c1 |
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.