Bug 69341 - [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
[radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi
git
Other All
: medium normal
Assigned To: Default DRI bug account
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-14 01:43 UTC by darkbasic
Modified: 2015-01-28 08:54 UTC (History)
4 users (show)

See Also:


Attachments
X11/XRender corruption (70.12 KB, text/plain)
2013-09-14 01:43 UTC, darkbasic
Details
X11/XRender corruption (image/png) (70.12 KB, image/png)
2013-09-14 01:45 UTC, darkbasic
Details
xorg.log (51.56 KB, text/plain)
2013-09-14 01:46 UTC, darkbasic
Details
dmesg (98.12 KB, text/plain)
2013-09-14 01:46 UTC, darkbasic
Details
color-corruption.png (180.58 KB, image/png)
2013-09-23 14:47 UTC, Denis M. (Phr33d0m)
Details
dmesg output (60.63 KB, text/plain)
2013-11-16 16:35 UTC, Vladimir Ysikov
Details
Xorg.0.log (37.88 KB, text/plain)
2013-11-16 16:35 UTC, Vladimir Ysikov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description darkbasic 2013-09-14 01:43:54 UTC
Created attachment 85799 [details]
X11/XRender corruption

Adding/deleting text in Konsole or minimizing a window is a pain in the ass with the Raster backend. X11/XRender backend is fast but has graphical glitches.

Linux 3.12 (drm-next merged on top of 3.11.0) but I also tried 3.11.
xorg-server 1.14.2.902
mesa git
libdrm git
xf86-video-ati git
glamor git but I also tried 0.5
llvm git
clang git
KDE 4.11.1
Gentoo

I attached a screenshot of the X11/XRender corruption.
Comment 1 darkbasic 2013-09-14 01:45:04 UTC
Created attachment 85800 [details]
X11/XRender corruption (image/png)
Comment 2 darkbasic 2013-09-14 01:46:29 UTC
Created attachment 85801 [details]
xorg.log
Comment 3 darkbasic 2013-09-14 01:46:54 UTC
Created attachment 85802 [details]
dmesg
Comment 4 darkbasic 2013-09-14 01:47:54 UTC
~ $ glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD TAHITI
OpenGL version string: 3.0 Mesa 9.3.0-devel (git-ea373f0)
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
Comment 5 darkbasic 2013-09-15 12:33:21 UTC
Card is AMD Radeon HD 7950. The graphical glitches with the X11/XRender backend seems to be a known issue (https://bugs.freedesktop.org/show_bug.cgi?id=64297) so I modified the bug to track just the issues with the Raster backend.

Actually the KDE overall desktop experience is so bad that I had to switch back to the integrated Ivy Bridge graphic :(
Comment 6 Denis M. (Phr33d0m) 2013-09-23 14:47:27 UTC
Created attachment 86376 [details]
color-corruption.png

I also have this color corruption all over the place with Native/OpenGL backend and Glamor. As well as huge slowness/laggyness, glxgears at:

$ ▶ glxgears 
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
237 frames in 5.0 seconds = 47.022 FPS
250 frames in 5.0 seconds = 49.853 FPS
234 frames in 5.0 seconds = 46.726 FPS
253 frames in 5.0 seconds = 50.592 FPS
234 frames in 5.0 seconds = 46.440 FPS
256 frames in 5.0 seconds = 51.165 FPS
236 frames in 5.0 seconds = 46.952 FPS

On Radeon HD7870.
Comment 7 darkbasic 2013-09-23 15:10:34 UTC
Yes that's the same corruption I have with the native backend. I suggest you to have a look at top: native isn't slow, but aftware a few minutes the X process starts eating the CPU ,that's the reason ;)
On the contrary Raster in EXTREMELY slow since the very first moment, but at least there is no corruption.

Regarding your glxgears issue "vblank_mode=0 glxgears" will do the magic.
Comment 8 Denis M. (Phr33d0m) 2013-09-23 20:03:49 UTC
(In reply to comment #7)
> Yes that's the same corruption I have with the native backend. I suggest you
> to have a look at top: native isn't slow, but aftware a few minutes the X
> process starts eating the CPU ,that's the reason ;)

In my case, X doesn't normally use much cpu (~10-15%) (well, really depends on your definition of 'much'), but there are moments (every 2-3 seconds) where it peaks at ~45-60% which causes everything to lag for a moment (for example if I move a window or even with glxgears)...

And btw, thanks for the vblank tip, it helped a little.
Comment 9 darkbasic 2013-09-23 20:14:11 UTC
It goes to 100% with native backend, at least on SI.
Comment 10 Fredrik Höglund 2013-09-27 14:25:25 UTC
The raster backend does all its rendering in an xshm image, so it's likely that the problem is in the ShmPutImage path.
Comment 11 darkbasic 2013-10-02 19:47:15 UTC
The root of the problem *isn't* glamor: I just tried Glamor with Intel HD4000 and it works flawlessly. The issue is with mesa.
Comment 12 darkbasic 2013-10-04 20:29:33 UTC
I noticed something weird: if I start KDE with desktop effects off it is *much* faster and there is corruption in the title bar. On the contrary if I start KDE with desktop effects on and *then* I turn them off nothing changes: it keeps being very slow and there are no signs of corruption in the title bar.

Also I noticed it is much faster when I set resolution to 1920x1200 compared to 2560x1600, at least when starting KDE with desktop effects off.
Comment 13 Michel Dänzer 2013-10-09 10:19:47 UTC
(In reply to comment #12)
> I noticed something weird: if I start KDE with desktop effects off it is
> *much* faster and there is corruption in the title bar.

The corruption indicates it's using the native Qt backend, not Raster.


> Also I noticed it is much faster when I set resolution to 1920x1200 compared
> to 2560x1600, at least when starting KDE with desktop effects off.

2560x1600 is almost twice as many pixels as 1920x1200, so some difference in performance between them is expected.
Comment 14 Michel Dänzer 2013-10-09 10:21:39 UTC
(In reply to comment #11)
> The root of the problem *isn't* glamor: I just tried Glamor with Intel
> HD4000 and it works flawlessly. The issue is with mesa.

Could also be the glamor glue code in xf86-video-ati.
Comment 15 darkbasic 2013-10-09 16:58:58 UTC
Another user with the same distro (Gentoo) and HD7700 (radeonsi) told me he doesn't have this problem:

http://phoronix.com/forums/showthread.php?85135-GLAMOR-ized-Radeon-Driver-Shows-Hope-Over-EXA&p=361630#post361630

http://phoronix.com/forums/showthread.php?85135-GLAMOR-ized-Radeon-Driver-Shows-Hope-Over-EXA&p=361970#post361970

oibaf pointed me to some glamor patches: http://lists.freedesktop.org/archives/glamor/2013-October/date.html

I can't try them right now (I'm in Spain) but I will in a week or two.
Comment 16 darkbasic 2013-10-21 17:05:51 UTC
Patches (which have been merged mainline in the meantime) didn't help.
Comment 17 darkbasic 2013-10-21 17:09:46 UTC
Considering there is an user with a working HD7700 I will try kubuntu 13.10 + oibaf ppa: maybe there is some magic combination which makes it work. Maybe...
Comment 18 darkbasic 2013-10-23 19:09:08 UTC
I just tried plain Kubuntu 13.10: same issue, desktop is unusable :(
Comment 19 langkamp 2013-10-24 21:30:49 UTC
Also have HD 7950 on kde 4.11 (opensuse factory+kernel 3.12 and graphical stack from git via pontostroy repo)

- opengl + raster = very fast, seldom small graphical glitches
- opengl + native = fast, no glitches so far
- xrender + raster = very fast, no glitches so far 
- xrender + native = very fast, permanent huge glitches
Comment 20 darkbasic 2013-10-25 09:30:12 UTC
Interesting... what may be the difference between your 7950 and mine? Is there a dev who has any clue? If you want I can make a video, I don't think you realize how *SLOW* it is, you can't even type something in Konsole without going crazy :)

I just switched to fglrx after 4 years with just FOSS drivers and KDE is quite fast (but not as fast as with my HD4000), anyway even the slow radeon was better than fglrx in Left 4 Dead 2 (framerate is high with fglrx but still the game is unplayable).
Comment 21 langkamp 2013-10-27 12:52:00 UTC
did you tried a recent git version? 
you also could try the oibaf ppa with (k)ubuntus - you wrote you tested only plain kubuntu. 
Maybe you also have to set radeon.dpm=1 in grub. I have not tested without it.

in the end it could also be a opensuse thing (but i don´t believe that) or a hardware fault (I have an gibabyte OC version)

my best guess at the moment is radeon.dpm=1
Comment 22 langkamp 2013-10-27 13:03:53 UTC
ah sorry - I see radeon.dpm=1 enabled in your log.
My next guess would be to use glamor 0.5.99 AND kernel 3.12 and not 3.11+drmnext

I did NOT test with 3.11 or glamor 0.5.1 and had and have it only working since 3.12rc4 and glamor 0.5.99
Comment 23 darkbasic 2013-10-27 14:09:04 UTC
I'm using everything from git.
Comment 24 langkamp 2013-10-27 18:38:58 UTC
Then maybe update your attached xorg.log - it says you are using an updated kernel 3.11 and glamor 0.5.1 
Maybe the devs need this updated log.
I am just a user by the way trying to help :)

I don´t know if glamor 0.5.1 is a stable git branch... I use 0.5.99. Maybe thats the unstable git branch.

I also got the hint to delete everything in my /usr/local/ because I had old self-compiled mesa etc. there and that prevented the use of the up to date versions in /usr
I think /usr/local is used first because its first in the PATH environment variable...
So for me all worked after I deleted the stuff in /usr/local. Before I was stuck at software rendering.
Comment 25 langkamp 2013-10-27 21:00:56 UTC
mmh - after the last zypper up from the pontostroy-repository (containing latest git stuff) I had the content of my windows upside down - the windows itself were normal.

So I reverted from openSUSE factory to openSUSE 13.1 RC1 and also disabled the pontostroy-repos. So I am back to kernel 3.11 and mesa 9.2.2 and glamor/opengl 2.0 on kde-compositing is still blazing fast, while raster is a bit faster than native. There are even NO graphical glitches in both modes. Light games are also working.

glxinfo | grep Open
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD TAHITI
OpenGL version string: 2.1 Mesa 9.2.2
OpenGL shading language version string: 1.30

grep lamor /var/log/Xorg.0.log
[     6.601] (II) LoadModule: "glamoregl"
[     6.608] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
[     6.618] (II) Module glamoregl: vendor="X.Org Foundation"
[     6.638] (II) Loading sub module "glamoregl"
[     6.638] (II) LoadModule: "glamoregl"
[     6.638] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
[     6.638] (II) Module glamoregl: vendor="X.Org Foundation"
[     6.638] (II) glamor: OpenGL accelerated X.org driver based.
[     6.774] (II) glamor: EGL version 1.4 (DRI2):
[     6.823] (II) RADEON(0): glamor detected, initialising EGL layer.


So another thing I have encountered in the past is that leftovers of fglrx conflicted somehow with the system. How did you uninstall it - maybe that is the problem. For instance I still have this leftover and I cannot find the root:

grep fglrx /var/log/Xorg.0.log
[     6.625] (==) Matched fglrx as autoconfigured driver 0
[     6.625] (==) Matched fglrx as autoconfigured driver 2
[     6.625] (II) LoadModule: "fglrx"
[     6.628] (WW) Warning, couldn't open module fglrx
[     6.628] (II) UnloadModule: "fglrx"
[     6.628] (II) Unloading fglrx
[     6.628] (EE) Failed to load module "fglrx" (module does not exist, 0)

this however does not make problems....
Comment 26 Peter Zubaj 2013-11-01 19:16:02 UTC
I had similar problem with Fedora rawhide. Recompiling rawhide kernel from source with default config helped. Looks like problem is with some kind of memory trace enabled in kernel (most of cpu time was spend in slab_alloc and slab_free).
Comment 27 darkbasic 2013-11-01 23:06:08 UTC
I completely removed tracers, changed slab allocator from slub to slab, completely disabled kernel debugging... it didn't help :(
Can you please be more specific? Also, is there any way to check what the hell is happening? You spoke about kernel spending lots of cpu cycles in slab_alloc and slab_free but I have no clue how to debug it and developers seem not willing to help me.
Comment 28 Matthew Dawson 2013-11-05 19:57:21 UTC
I think this may have been solved with the latest ddx for ati.  I was originally using version 7.0 (or earlier) along with the latest mesa (9.2, rc or gold) and glamor (0.5).  With KDE I would get frequent slow downs, with X consuming a full CPU core.  Using perf, I noticed it spent all of its time in a memcpy, and using gdb I found it was copying memory between textures in glamor.

Upgrading to the latest ddx (7.2), all speed issues in KDE (including konsole) mostly disappeared.  X no longer uses cpu like it did before.  For those still seeing speed problems, what version of the ati ddx are you using?  And if you upgrade to 7.2, do your speed problems go away?

I'm using Gentoo with an HD7970.
Comment 29 darkbasic 2013-11-05 22:00:03 UTC
Raster never had an high cpu usage, the backend which had high cpu usage was native. I use DDX from git and it wasn't fixed a few days ago, maybe the commit which fixed it has been committed in the past few days?
Comment 30 Matthew Dawson 2013-11-06 18:58:14 UTC
(In reply to comment #29)
> Raster never had an high cpu usage, the backend which had high cpu usage was
> native. I use DDX from git and it wasn't fixed a few days ago, maybe the
> commit which fixed it has been committed in the past few days?

Huh, then I'm not sure then.  I'm using a released version of the ddx, so if performance dropped off again, then its likely a bad commit got added.  I'm not sure what else to suggest to fix it though.

Maybe if you run perf top while causing the slowdowns, something will bubble to the top?
Comment 31 darkbasic 2013-11-07 13:13:10 UTC
I have some updates. Raster is still broken (it's still slow as hell) but at least Native improved alot. Corruption with native is VERY SPARE compared to a month ago, also with native X doesn't start eating CPU until full load anymore. This means native is in an (almost) usable state.

Please note that switching from raster to native in the Kwin Desktop Effects doesn't make any effect, you have to use kcm-qt-graphicssystem which exports QT_GRAPHICSSYSTEM=native at startup.
Comment 32 Denis M. (Phr33d0m) 2013-11-09 02:02:57 UTC
(In reply to comment #28)
> Using perf, I noticed it spent all of its
> time in a memcpy, and using gdb I found it was copying memory between
> textures in glamor.
With latest kernel 3.12.0, mesa 9.2.2 and ati 7.2 color corruption mostly disappeared with the Native KDE backend and OpenGL 2.0 selected.

Although, every couple of seconds (every ~2-3 sec) my desktop lags for a moment, using `perf top` I see:
 45.08%  [kernel]                 [k] radeon_vm_bo_set_addr 

which stays like that all the time. The desktop is pretty much usable, but watching a HD movie is almost impossible with all that lagging every few seconds.

> I'm using Gentoo with an HD7970.
Gentoo + HD7870 here.
Comment 33 Vladimir Ysikov 2013-11-16 16:30:47 UTC
I have Radeon 7950 video card and use opensorce driver on ArchLinux x86, kernel 3.12 + llvm svn + mesa + git. My DE is KDE with kwin.
And with this configuration some 2D operation(resizing window) very slow. Mplayer opens to full screen for 10 seconds.
Now i rebuild graphical stack llvm 194920, mesa e133c0103d4336c47911e89cc8a17a1c78bfdbb8, xf86-video-ati last git.
And something went wrong, glxgers says Error: couldn't get an RGB, Double-buffered visual, no one 3D apps dont runs.
But 2D now fast as rocket
Comment 34 Vladimir Ysikov 2013-11-16 16:35:12 UTC
Created attachment 89323 [details]
dmesg output
Comment 35 Vladimir Ysikov 2013-11-16 16:35:33 UTC
Created attachment 89324 [details]
Xorg.0.log
Comment 36 darkbasic 2013-11-16 16:40:38 UTC
You need to patch your xorg server with http://cgit.freedesktop.org/xorg/xserver/commit/?id=7ecfab47eb221dbb996ea6c033348b8eceaeb893 (glx: Add support for the new DRI loader entrypoint.)

Now it is fast because it doesn't use your graphic card at all :)

Regarding your issue with mplayer please see this bug: https://bugs.freedesktop.org/show_bug.cgi?id=71448
Comment 37 Vladimir Ysikov 2013-11-16 20:04:50 UTC
(In reply to comment #36)
> You need to patch your xorg server with
> http://cgit.freedesktop.org/xorg/xserver/commit/
> ?id=7ecfab47eb221dbb996ea6c033348b8eceaeb893 (glx: Add support for the new
> DRI loader entrypoint.)
> 
> Now it is fast because it doesn't use your graphic card at all :)

I'll leave it at that for a while. I miss fast 2D :-)

> Regarding your issue with mplayer please see this bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=71448

I read this bug. My mplayer start playing immediately, slow only opens to full screen and back. Not only play video, firefox slow too (F11 key).
Comment 38 darkbasic 2013-11-16 21:24:45 UTC
I know it well, raster really sucks that much with radeonsi :)

Fortunately you can have fast 2D (at the expense of some corruption):
echo "export QT_GRAPHICSSYSTEM=native" >> ~/.kde4/env/qt-graphicssystem.sh
Comment 39 Thue Janus Kristensen 2013-11-16 23:41:44 UTC
Bug #68524 sounds related, has a simple testcase.
Comment 40 darkbasic 2013-11-17 13:40:40 UTC
gtkperf doesn't work at all for me: https://bugs.freedesktop.org/show_bug.cgi?id=71697
Comment 41 darkbasic 2014-01-10 12:09:35 UTC
"Speed up glamor_copy_area for certain use cases" (https://bugs.freedesktop.org/attachment.cgi?id=91380) from bug #71813 (https://bugs.freedesktop.org/show_bug.cgi?id=71813) seems to fix my KDE raster backend issue! hurray!!!

I suggest you to apply also "polylines: Handle diagonal lines" (https://bugs.freedesktop.org/attachment.cgi?id=91802) which fixes the gtk primitives/Calc issues (bug #68524 https://bugs.freedesktop.org/show_bug.cgi?id=68524)
Comment 42 darkbasic 2014-01-10 12:33:57 UTC
Native backend is still much faster (especially while scrolling), but at least raster is usable now.
Comment 43 Michel Dänzer 2015-01-28 07:37:16 UTC
(In reply to darkbasic from comment #42)
> Native backend is still much faster (especially while scrolling), but at
> least raster is usable now.

So can this report be resolved?
Comment 44 darkbasic 2015-01-28 08:52:38 UTC
Yes, fortunately the (not so) old, good glamor times are past.
Comment 45 darkbasic 2015-01-28 08:54:48 UTC
By the way, we still have corruption in KWin without compositor but I guess it's a known long standing issue.