Description of problem: On my current setup, I am running an AMD E2-1800 processor which is coupled with an Radeon HD7340 graphics chipset. I am currently using the FLGRX proprietary driver since the open source driver does not yet support this chipset. However, Gnome 3.4 still loads in software rendering mode using llvmpipe. Although I'm able to login to gnome 3 and use it, the performance isn't good. Animations are choppy and the interface is laging quite a bit. I would expect gnome-shell should be able to load using hardware rendering to provide a much snappier experience with hardware in question. #lspci -v | grep -i vga 00:01.0 VGA compatible controller: ATI Technologies Inc Device 9808 (prog-if 00 [VGA controller]) # glxinfo | grep -i renderer OpenGL renderer string: AMD Radeon HD 7340 Graphics ]# lsmod | grep fglrx fglrx 3266422 136 amd_iommu_v2 19094 1 fglrx button 13825 1 fglrx Despite these outputs, the graphics section in gnome system settings is still showing VESA: HONDO as the graphics device used. Version-Release number of selected component (if applicable): gnome-shell 3.4.1 fglrx 8.961 How reproducible: The system boots in software rendering mode every time. Steps to Reproduce: 1. 2. 3.
Still valid for Mageia 3 alpha 3. Now the free driver works, but both the free and proprietary driver yield a gnome 3 experience with software rendering only.
Version: 2 => Cauldron
If 'radeon-firmware' is not installed, try to solve your issue by installing it from the non-free repository, then reboot.
CC: (none) => gruescubogdan
radeon-firmware is already installed. For comparison, I have another system, this one a desktop system with a core 2 quad (granted a much faster cpu!) with gnome 3 installed. Gnome shell is butter smooth on that system. I also noticed that on the laptop with the issue in question, the CPU load drastically increases (anywhere between 40 to 60%+) whenever I resize, move or use the overview mode in gnome 3. Somehow the load which should be handled by the gpu is being handled by the CPU just like in software rendering. Using the free driver or the proprietary driver yields virtually the same level of responsiveness and performance. I'm at a lost as to what is wrong.
Well, as a guess maybe 'radeon-firmware' needs un update. It was last built almost 8 months ago, but your graphical chipset (Radeon HD 7340) is less than 7 months old. I've added Thomas to the CC list, hopefully he will update the package. I would just emphasize that I had the same bad performance (software rendering with llvmpipe and also a non-optimal screen resolution) in GNOME immediately after a Cauldron network install, and simply adding 'radeon-firmware' and rebooting did the trick and the desktop experience became pleasant with the free driver (haven't tested the proprietary driver). However, my laptop graphical chipset Radeon HD 6310 (from AMD APU E-350) is about 2 years old.
CC: (none) => tmb
With your chipset, the Radeon HD6310, do you notice spikes in the cpu usage when you're moving windows or switching from desktop to desktop in Gnome? Or is yours now fully utilizing hardware acceleration and relegating those operations to the GPU?
Hmmm I might be out of luck. Everywhere I looked seems to indicate that the current version of radeon-firmware is the latest available. So either AMD included support for the Brazos 2.0 in there already and my performance problem is related to something else, or support for this platform isn't yet available for Linux.
If it's any help. [root@localhost ~]# dmesg | egrep -i 'firmware|microcode' [ 0.194730] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [ 0.667967] pci_root PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-3f] only partially covers this bridge [ 14.740042] microcode: CPU0: patch_level=0x0500010d [ 15.403839] microcode: CPU1: patch_level=0x0500010d [ 15.404899] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba [ 18.738235] [drm] Loading PALM Microcode [ 31.882762] microcode: Microcode Update Driver: v2.00 removed. I don't know if that provides any useful information but I thought i'd post it anyway.
CC: (none) => olavWhiteboard: (none) => 3alpha3
(In reply to comment #5) > With your chipset, the Radeon HD6310, do you notice spikes in the cpu usage > when you're moving windows or switching from desktop to desktop in Gnome? Or is > yours now fully utilizing hardware acceleration and relegating those operations > to the GPU? There is an increase in CPU usage more significant when moving a window than in case of switching between windows (from about 15% to about 50% (on average of both cores, note that these values are with gnome-system-monitor active which is also a power hungry application)), nonetheless I suppose the ranges are expected and also the system is responsive. In <System Settings> - <Details> - <Graphics> it says 'Gallium 0.4 on AMD PALM' and the snippet of dmesg is a little different. [root@localhost bogdan]# dmesg | egrep -i 'firmware|microcode' [ 0.179397] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [ 0.211203] pci_root PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-3f] only partially covers this bridge [ 2.685014] [drm] Loading PALM Microcode [ 11.037719] microcode: CPU0: patch_level=0x05000028 [ 11.355783] microcode: failed to load file amd-ucode/microcode_amd.bin [ 11.355813] microcode: CPU1: patch_level=0x05000028 [ 11.357095] microcode: failed to load file amd-ucode/microcode_amd.bin [ 11.357175] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba [ 20.397489] microcode: Microcode Update Driver: v2.00 removed.
That's interesting Bogdan. It appears we're having the same gnome 3 experience. In your opinion, are we both hitting limitation in performance of the Brazos platform and that the gpu acceleration just isn't that good? Or is there some problem with the drivers not supporting brazos very well and causing little to no performance gains by using the gpu? Based on what I've seen of Gnome 3 running on intel hardware with integrated graphics (GMA 3000 in this case), it runs butter smooth. My system is responsive, but the animations are definitely very choppy (like very low FPS). I just have this nagging feeling that its not running the way it should and that the interface load isn't being offloaded to the GPU like it should. But then again, I might be wrong.
(In reply to comment #9) - comments inserted into the text > ... It appears we're having the same gnome 3 experience. I really doubt about that; if you had had a good desktop experience, you wouldn't have opened this bug report. :) > In your opinion, are we both hitting limitation in performance of the Brazos > platform and that the gpu acceleration just isn't that good? On the contrary, Radeon HD7340 should be powerful enough to work nicely with GNOME shell (it is about 15% faster than mine Radeon HD6310 and on a par or very slightly slower than Intel GMA 3000). Don't expect a good experience with demanding graphical applications, though. > Based on what I've seen of Gnome 3 running on intel hardware with integrated > graphics (GMA 3000 in this case), it runs butter smooth. My system is > responsive, but the animations are definitely very choppy (like very low FPS). > I just have this nagging feeling that its not running the way it should and > that the interface load isn't being offloaded to the GPU like it should. But > then again, I might be wrong. You can't be wrong, the difference in performance / feel is evident and huge, so easily noticeable. From Comment 1, I assume you performed a clean install of Mageia 3 alpha 3 or a recent Cauldron on a real hardware ... What do you see in <System Settings> - <Details> - <Graphics> (Gnome System Settings)? If you see something related to VESA or llvmpipe, then try to change that with XFdrake (Mageia Control Center). For instance, my option for X server in XFdrake (set automatically by the system, and using the free driver) is 'Radeon HD 5000 to HD 6300 (radeon/fglrx)', perhaps for you the next entry 'Radeon HD 6400 and later (radeon/fglrx)' is appropriate. I guess a reboot would be necessary after such a change. In addition, a new proprietary driver (12.11 beta 8) have just been made available in Cauldron, you might want to try it out.
(In reply to comment #10) > On the contrary, Radeon HD7340 should be powerful enough to work nicely with > GNOME shell (it is about 15% faster than mine Radeon HD6310 and on a par or > very slightly slower than Intel GMA 3000). Don't expect a good experience with > demanding graphical applications, though. Yeah I definitely didn't buy this laptop for its blistering gaming performance. But I'm glad to hear that gnome-shell is suppose to run very nicely. So the problem is not one of lack of horse power, but a configuration issue. > You can't be wrong, the difference in performance / feel is evident and huge, > so easily noticeable. > From Comment 1, I assume you performed a clean install of Mageia 3 alpha 3 or a > recent Cauldron on a real hardware ... > What do you see in <System Settings> - <Details> - <Graphics> (Gnome System > Settings)? If you see something related to VESA or llvmpipe, then try to change > that with XFdrake (Mageia Control Center). For instance, my option for X server > in XFdrake (set automatically by the system, and using the free driver) is > 'Radeon HD 5000 to HD 6300 (radeon/fglrx)', perhaps for you the next entry > 'Radeon HD 6400 and later (radeon/fglrx)' is appropriate. I guess a reboot > would be necessary after such a change. I did an upgrade from mageia 2, not a clean install. But I did reconfigure my xserver using XFdrake tool and chose 'Radeon HD 6400 and later'. I tried both the free driver and the closed driver. When using the free driver, the string in system settings shows the same as you, that is 'Gallium 0.4 on AMD PALM'. When I use the closed driver, it is showing 'VESA: HONDO'. However, both drivers yield virtually the same performance on the desktop. I have also installed the latest updates 12.11 beta 8 which unfortunately did not change anything. Looking at the X server configuration, everything looks fine. Is it possible there is something wrong on the gnome side?
Created attachment 3128 [details] X11 config
Well, I've just tried the closed source driver (being curious), went to XFdrake and answered yes, I want to use it. I got the message that it failed to install 'x11-driver-video-fglrx'. However, I picked it up in Software Management and installed it manually (I was asked to choose a package as a dependency, then the installation was successful together with other packages, 19 in total). No errors, reboot ... After reboot, all seemed good. Checked the graphic details in system settings, but it wrote the same 'Gallium 0.4 on AMD PALM'. Tried the AMD Catalyst Control Center, but it failed to initialize, showing an error message. Obviously this AMD driver didn't work as it should or, more likely, it didn't work at all and the free driver was still in use. Then I opened a terminal and fired the command 'aticonfig --initial' without closing the X server, which proved to be a very bad idea, because after reboot I got a black screen ... Reboot again in Safe Mode, switched to Vesa Driver, restored the xorg.conf file, uninstalled all packages added during this test, reboot ... and luckily, my system is fully functional again (with the free driver) as if nothing has been happened. Surely, I won't try the proprietary driver again in the near future. > Looking at the X server configuration, everything looks fine. Is it possible > there is something wrong on the gnome side? A developer or packager could better answer your question, as I am a simple user. In my opinion, I think not, or at least, the exiting issues are not that severe. Your problem seems somehow isolated, but it's difficult to find someone with a very recent AMD APU / GPU willing to test Mageia Cauldron and share the experience. You probably don't want to risk a clean install of Cauldron, as it could be a pointless exercise. There is something else you can try. Download the Live Gnome Desktop of openSUSE 12.3 Milestone1 http://software.opensuse.org/developer/en or even a more recent Gnome CD image of a Factory Snapshot http://download.opensuse.org/factory/iso/ (some of these images might be broken) and boot in the live system to see how snappier it is. You don't need to install anything. Unlike Mageia, it doesn't require any firmware package to be installed afterwards, it should work out of the box with the free driver (theoretically). This way you might find out whether or not your problem is Mageia specific, although it's uncertain this information will be of any real use for you. Don't know about other distributions, perhaps you can test with a snapshot (Live CD) from Fedora as well.
After you mentioned the catalyst control center, I decided to go ahead an install it. There's been mentions all over the place about vertical syncing causing performance issues in gnome 3. I found the relevant setting in the control center, and turned off vertical syncing. The good news is the interface is a bit smoother now. The graphics is still showing as "vesa: hondo" and the cpu load is still very high sometimes reaching 80-90%, but at least the animation are running better. I will definitely try your suggestion of running a recent live distro like openSUSE to see if this is a problem that is specific to mageia, or if it is found in other distros as well.
So I just tried the Gnome live cd of opensuse 12.3 milestone 1. Without any metric to measure performance, its hard to prove the differences between both distros. But subjectively speaking, the interface felt a good deal more responsive with the animations quite smooth even with 6 or 7 windows opened. This live distro boots with the free driver as default. I couldn't figure out how to install the closed driver so I couldn't test that aspect. But the free driver seemed to perform better than in mageia. I wish I could give you guys more quantifiable information as all of this is based on subjective perceptions.
For openSUSE, they have the fglrx driver in a separate repository. http://geeko.ioda.net/mirror/amd-fglrx However, the latest driver version they have failed to build for Factory (openSUSE 12.3). More info here: http://lizards.opensuse.org/2012/10/28/amdati-fglrx-9-002-catalyst-12-10-released/#more-9083 Based on my experience, the openSUSE Factory distribution is more prone to breakage than Mageia Cauldron. For Mageia, as it shows VESA: HONDO in the graphics section, there is a strong reason to believe that it defaults to VESA for some reason, and even when you see 'Gallium 0.4 on AMD PALM', that might not be accurate and you are still stuck with VESA. That explain why you see no difference in performance between the two options and the bad performance. Usually, when VESA is used, also the screen resolution is lower than optimal. Obviously, I believe you hadn't added any parameter to the kernel option (or something similar) shortly after you installed Mageia and forgot to remove that afterwards. I've found the following reference http://wiki.cchtml.com/index.php/Frequently_Asked_Questions (probably you've already tried some commands from there). Hope a solution will be found soon, or someone with appropriate skills and knowledge will help you. Some users are really unlucky, see: https://bugs.mageia.org/show_bug.cgi?id=5426
Found another interesting tidbit about this problem which may, or may not be relevant. I was wondering if there wasn't something in the xorg.conf file generated by mageia that might be non optimal for my setup. So I decided to try the xserver auto detection capability by booting without an xorg.conf file. With this setup, my computer never made it to the login screen. After going through the gfxboot, it just went to a blank screen. So this tells me one of three things is happening. 1) The auto detect feature isn't working (not too likely given the progress done in this department) 2) The auto detect is working but my chipset isn't supported so it cannot figure out how to configure it. 3) The chipset is supported, but there is another bug preventing it from correctly detecting or configuring it.
Quick question Bogdan, what scores do you get when running glxgears? It's not a great benchmark for performance, but it should a least give me an idea if I'm getting the numbers I should be getting. I turned off vertical syncing using the vblank_mode=0 in my /etc/environment. Then I got about 850fps on glxgears.
Apparently I'm not the only one who's experiencing performance well below expectations with AMD's Brazos cpus. See this thread for an interesting discussion. http://phoronix.com/forums/showthread.php?72046-E-450-graphics-performance-issues
(In reply to comment #18) [bogdan@localhost ~]$ export vblank_mode=0 [bogdan@localhost ~]$ glxgears ATTENTION: default value of option vblank_mode overridden by environment. ATTENTION: default value of option vblank_mode overridden by environment. 2909 frames in 5.0 seconds = 581.644 FPS 2916 frames in 5.0 seconds = 583.080 FPS 2923 frames in 5.0 seconds = 584.526 FPS 2877 frames in 5.0 seconds = 575.300 FPS 2977 frames in 5.0 seconds = 595.288 FPS 2857 frames in 5.0 seconds = 571.339 FPS 2919 frames in 5.0 seconds = 583.704 FPS 2833 frames in 5.0 seconds = 566.556 FPS 2890 frames in 5.0 seconds = 577.916 FPS 2949 frames in 5.0 seconds = 589.696 FPS 3029 frames in 5.0 seconds = 605.681 FPS 2918 frames in 5.0 seconds = 583.520 FPS [bogdan@localhost ~]$ glxinfo | grep render ATTENTION: default value of option vblank_mode overridden by environment. ATTENTION: default value of option vblank_mode overridden by environment. direct rendering: Yes OpenGL renderer string: Gallium 0.4 on AMD PALM GL_MESA_window_pos, GL_NV_blend_square, GL_NV_conditional_render,
Well that doesn't help me too much lol. Your scores are 25%-30% lower than mine. I still maintain that something is not right since I get identical score with the open source driver and closed driver. Both average about 850fps. We should see a difference between the two.
Well last week my system got hozed after a grub update. I learned too late that there was a simple solution but I had already reinstalled Mageia 2 which I've been using since. As this is my work machine, I didn't want to risk further disruptions by reupgrading to cauldron. But I've continued my research of this issue. I discovered a little tidbit that seemed to help the animation fluidity (when 2-3 windows are opened at least). By adding "CLUTTER_PAINT=disable-clipped-redraws:disable-culling" to my /etc/environment, many of the animations and window manipulations are much more fluid. Now dragging a window around is quite fluid and switching virtual desktops via CTRL+ALT+UP/DOWN is also much smoother. Moving into overview mode with 4+ windows is starting to lag again, but at least the rest is much improved. I feel like my problem is mostly a combination of the newness of the processor/apu, the limitations of the driver (both closed and free driver), and Gnome 3 (with it's clutter/mutter backend) still being young. I might give KDE a try to see how fluid it is since kwin is now much more mature.
Well I found some interesting tidbits about gnome 3 with amd graphics. Based on a couple of benchmarks see from phoronix, I believe that AMD graphics are simply slower on gnome vs other environment. Given that the catalyst driver works well in other environment (KDE or XFCE for example), there must be something wrong in how the window compositor in gnome works when using amd's binary blob. For certain though, turning of vsync had a big impact on animation smoothness. I'm hopeful that gnome-shell will continue to be optimized as it matures. For now, I consider this bug as resolved.
Using the proprietary driver (which now loads correctly in cauldron), I currently get the best experience in gnome 3. By adding the following to /etc/environment: CLUTTER_VBLANK=none this disables vertical syncing with the proprietary driver in gnome and provides the smoothess animations possible that I've experienced with my system. Of course, this means that tearing will appear when moving windows. But IMHO, tearing + smoother animations > no tearing + choppy animations. For resons I don't understand, enabling vsync taxes the system way more which results in a lost of responsiveness. Hope this helps other folks.
Upon reading the phoronix thread more carefully, I can conclude that the open source driver is totally borked for this chipset. I pulled pu the radeon_pm_info and just like the original poster, my max engine clock is set to 200Mhz, but the current engine clock vascillates between 7Mhz and 15Mhz. If this is the case, that would totally explain why the performance and fluidity of the system is bad. So the final conclusion (I've had so many but I'm using this as a personal log of the research I've done on this issue) is that it appears as if hardware acceleration IS indeed enabled, but the card itself is completely under clocked due to bad power state tables.
This is interesting: https://bugs.freedesktop.org/show_bug.cgi?id=62493 So the reported frequency is incorrect. Alex Deucher has volunteered a patch to fix the reported clock speeds. However, the top speed of 200Mhz is simply a default speed and the actual speed of the APU isn't implemented yet.
Created attachment 3638 [details] Patch to fix how the clock speed is reported for APUs This kernel patch was written by Alex Deucher so I just copied it over to this bug thread. It's suppose to fix the issue that the clock speed is incorrectly read when using the open source ati driver on an APU. I have no idea what to do with this, but I'd thought someone with more experience could apply it and see what happens. This doesn't fix the problem of the max clock being too low however. Just a note.
Keywords: (none) => UPSTREAM
Assigning to tmb Comment 27 posts a patch from amd for setting correct clock speed for amd APUs
CC: (none) => andre999mgaAssignee: bugsquad => tmb
its not setting correct clock speed, it's just fixes reporting correct speed patch merged in upcoming 3.8.7-1
Status: NEW => RESOLVEDResolution: (none) => FIXED