| Summary: | Moving windows is extremely slow on r300 with egl_dri2/gles, eglonx and glx, but not gallium(?) gles | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Thomas Pfeiffer <thomas.pfeiffer> |
| Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED WAITINGFORINFO | ||
| Severity: | normal | CC: | t.kijas |
| Priority: | NOR | Flags: | thomas.luebking:
r300g+
|
| Version First Reported In: | 4.10.3 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Thomas Pfeiffer
2013-05-24 18:14:07 UTC
> Strangely, it's quite a bit faster with XRender To a point where it's actually usable (resp. "normally fast") or "just a bit"? > Disabling effects does not improve the situation I assume that does *not* mean "disable compositing" (Shift+Alt+F12) but you tried disabling effects like translucency? Anything else, like high CPU load or memory usage (check "cat /proc/meminfo", resp. "xrestop") - related info in "dmesg"? Has it been faster "before" (and happens since you upgraded mesa or KDE etc.)? Thanks for replying so fast! (In reply to comment #1) > > Strangely, it's quite a bit faster with XRender > To a point where it's actually usable (resp. "normally fast") or "just a > bit"? Considerably faster than with OpenGL, but still considerably slower than without compositing. > > Disabling effects does not improve the situation > I assume that does *not* mean "disable compositing" (Shift+Alt+F12) but you > tried disabling effects like translucency? Oh, sorry for the ambiguity. I meant "disabling specific effects". In fact I unchecked every single effect, but not compositing in general. Pressing Shift+Alt+F12) makes it fast. > Anything else, like high CPU load or memory usage (check "cat > /proc/meminfo", resp. "xrestop") - related info in "dmesg"? This happens independently of CPU or memory load. Anything specific I should look for in xrestop or dmesg? > Has it been faster "before" (and happens since you upgraded mesa or KDE > etc.)? It's been like that for quite some time, since several versions of the graphics stack (and of KWin). (In reply to comment #2) > Considerably faster than with OpenGL, but still considerably slower :-( Does falling down to XGA "fix" it? (xrandr -s 1024x768) > Oh, sorry for the ambiguity. No, actually not. Disabling effects is what one should say, but users often mean "disabling compositing" by it - therefore one better asks ;-) > This happens independently of CPU or memory load. The important part would be "moving windows does not burn my CPU", confirmed? > Anything specific I should look for in xrestop or dmesg? xrestop: general memory usage dmesg: any warning from the radeon driver. > It's been like that for quite some time, since several versions of the > graphics stack (and of KWin). And before it has been "fast as uncomposited" or "fast as xrender" or "compositing didn't work anyway then"? ah, blast. have you tried "kwin_gles --replace&"? Eventually "EGL_DRIVER=egl_dri2 kwin_gles --replace&"? AHA! With "kwin_gles --replace&" it's almost as fast as with compositing disabled! "EGL_DRIVER=egl_dri2 kwin_gles --replace&" made it slow again interesting. One more test please: KWIN_OPENGL_INTERFACE=egl kwin --replace & With that, it's slow again. this seems dri related, was there maybe an update to radeon-dri and/or did anything change in this regard? The problem had existed for a very long time, over various versions of radeon-dri. Anything I can do to test this further? If I'm the only one affected and it is probably due to my specific system setup, you may close the bug because using kwin_gles solved it for me. If it may affect others as well, I'm willing to test further. You are not alone, but I cannot help you anymore as I do not have such a HW now. Btw I reported similar bug about 4 years ago. no you didn't - this bug is about egl, kwin even only has gles support since summer 2011 (in developer versions...) and egl on glx is rather new. @Thomas P: do you still have that hardware and is that still a problem with 5.8? I don't have the hardware anymore and therefore cannot test if it still applies, therefore I'm resolving the bug. |