Created attachment 20874 [details] xorg.conf Since updating my drivers from the 2.1.1 stable of xf86-video-i810 to 2.5.1 of the intel drivers, 2D acceleration has become dramatically slower. When opening or restoring windows, the contents of them can be seen clearly being drawn on the screen. Amarok maybe takes 2-3 seconds to draw itself before it becomes responsive. During this, the X process has high cpu usage, similarly it is high when any 2d rendering is being done, for example when Amarok is open the standard visualisation running makes the X process use 10-30% cpu time. I have tried a plethora of xorg.conf settings but none work, including XAA (i think it has been removed in the latest 2.5.X releases but I tried it with 2.4.3)
Created attachment 20875 [details] xorg log
please follow : http://intellinuxgraphics.org/how_to_report_bug.html
Bug description: System environment: -- chipset: 915G -- system architecture: amd64 -- xf86-video-intel: 2.5.1 -- xserver: 1.5.2 -- mesa: 7.2 -- drm:2.4.0 -- kernel:2.6.27 -- Linux distribution:gentoo -- Machine or mobo model: gigabyte GA-8I915G-MF -- Display connector:VGA Reproducing steps:Open amarok, with the blue standard visualisation running. X process cpu jumps to 10-30% when it should be <1%
Created attachment 20914 [details] dmesg output
I suggest that this is a dupe of #18389
i believe my problem is different as when changing to XAA, there is absolutely no difference in the symptoms, let alone good performance. also there is high cpu usage when drawing, not just slow performance? but i am not sure if this means anything
Can you reproduce with kernel 2.6.30, xf86-video 2.7.1 or newer, Mesa 7.4 or newer, and UXA enabled? Your kernel as of this report lacks GEM support, which is critical for performance with the 2D driver these days.
Installed amarok and tested. I don't see any visualization in the list described as "blue" or "standard", but there were a couple of ones that were predominantly blue: bumpscope and corona. Those spent all their time in CPU drawing, and about 10% in uploading the results to the screen, which seemed reasonable for the operations being done. So, given that we've fixed a problem that would have made that software upload much slower than it is now, and the reporter had a non-GEM kernel, I think this bug is fixed.
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.