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.
Created attachment 85800 [details] X11/XRender corruption (image/png)
Created attachment 85801 [details] xorg.log
Created attachment 85802 [details] dmesg
~ $ 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:
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 :(
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.
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.
(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.
It goes to 100% with native backend, at least on SI.
The raster backend does all its rendering in an xshm image, so it's likely that the problem is in the ShmPutImage path.
The root of the problem *isn't* glamor: I just tried Glamor with Intel HD4000 and it works flawlessly. The issue is with mesa.
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.
(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.
(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.
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.
Patches (which have been merged mainline in the meantime) didn't help.
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...
I just tried plain Kubuntu 13.10: same issue, desktop is unusable :(
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
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).
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
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
I'm using everything from git.
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.
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....
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).
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.
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.
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?
(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?
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.
(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.
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
Created attachment 89323 [details] dmesg output
Created attachment 89324 [details] Xorg.0.log
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
(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).
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
Bug #68524 sounds related, has a simple testcase.
gtkperf doesn't work at all for me: https://bugs.freedesktop.org/show_bug.cgi?id=71697
"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)
Native backend is still much faster (especially while scrolling), but at least raster is usable now.
(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?
Yes, fortunately the (not so) old, good glamor times are past.
By the way, we still have corruption in KWin without compositor but I guess it's a known long standing issue.
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.