Summary: | Kwin chrashed when trying to use direct rendering with fglrx | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Hrvoje Senjan <hrvoje.senjan> |
Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED UPSTREAM | ||
Severity: | crash | CC: | hrvoje.senjan, swcafe |
Priority: | NOR | ||
Version: | CVS | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | KWinrc diff |
Description
Hrvoje Senjan
2011-05-20 07:46:41 UTC
Sorry, this is complete backtrace: Application: KWin (kwin), signal: Segmentation fault [KCrash Handler] #6 0x0000000000000000 in ?? () #7 0x00007f75ef79a98a in KWin::GLShader::load(QByteArray const&, QByteArray const&) () from /usr/lib/libkwineffects.so.1 #8 0x00007f75ef79b121 in KWin::GLShader::loadFromFiles(QString const&, QString const&) () from /usr/lib/libkwineffects.so.1 #9 0x00007f75ef79e567 in KWin::ShaderManager::initShaders() () from /usr/lib/libkwineffects.so.1 #10 0x00007f75ef79ec09 in KWin::ShaderManager::ShaderManager() () from /usr/lib/libkwineffects.so.1 #11 0x00007f75ef79ec47 in KWin::ShaderManager::instance() () from /usr/lib/libkwineffects.so.1 #12 0x00007f75f16d8d75 in ?? () from /usr/lib/libkdeinit4_kwin.so #13 0x00007f75f16c3c97 in ?? () from /usr/lib/libkdeinit4_kwin.so #14 0x00007f75f16c4275 in ?? () from /usr/lib/libkdeinit4_kwin.so #15 0x00007f75f16483ac in ?? () from /usr/lib/libkdeinit4_kwin.so #16 0x00007f75f166005a in ?? () from /usr/lib/libkdeinit4_kwin.so #17 0x00007f75f1661d2b in kdemain () from /usr/lib/libkdeinit4_kwin.so #18 0x00007f75f12c9f6d in __libc_start_main () from /lib/libc.so.6 #19 0x00000000004005f1 in _start () The backtrace is still too incomplete to find out where it crashes. Personally I think this crash is another case of your switching drivers. You have to ensure that nothing of gallium/radeon is left when you use fglrx. For direct rendering with fglrx it is very important to not use kms. In an unrelated note: fglrx does not provide the performance to use direct rendering. I can confirm that there's no KMS/radeon/gallium on my system: LIBGL_DEBUG=verbose glxinfo > /dev/null libGL: XF86DRIGetClientDriverName: 8.85.6 fglrx (screen 0) libGL: OpenDriver: trying /usr/lib/xorg/modules/dri//fglrx_dri.so ukiDynamicMajor: found major device number 252 ukiDynamicMajor: found major device number 252 ukiOpenByBusid: Searching for BusID PCI:1:0:0 ukiOpenDevice: node name is /dev/ati/card0 ukiOpenDevice: open result is 6, (OK) ukiOpenByBusid: ukiOpenMinor returns 6 ukiOpenByBusid: ukiGetBusid reports PCI:1:0:0 cat /var/log/dmesg.log | grep modeset [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz26-ck root=/dev/disk/by-uuid/eee61ccf-766f-4dcc-8287-d6cf3cfa1da2 ro quiet nopat nomodeset acpi_osi=Linux acpi_backlight=vendor [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz26-ck root=/dev/disk/by-uuid/eee61ccf-766f-4dcc-8287-d6cf3cfa1da2 ro quiet nopat nomodeset acpi_osi=Linux acpi_backlight=vendor So, there's no benefits running fglrx with direct rendering? Using Opengl2 shaders "seems" to improve performance... I don't know how to provide better backtrace with fglrx Trying direct rendering with fglrx on Debian_KDE.4.6.2 doesn't crash KWin but performance is terrible :). I must say i'm very pleased and surprised with development KWin's performance with fglrx , considering how much are proprietary drivers 'forward compatible' :) Crashtrace for KWin is incomplete. There is no way to see where it actually crashed - line numbers are missing. Compiled again with debug symbols , hope this is more helpful: Application: KWin (kwin), signal: Segmentation fault [KCrash Handler] #6 0x0000000000000000 in ?? () #7 0x00007ff547e6298a in load (this=0x1d5cb20, vertexSource=..., fragmentSource=...) at /home/src/build/x86_64/kdebase-workspace/src/kdebase-workspace/kwin/libkwineffects/kwinglutils.cpp:799 #8 KWin::GLShader::load (this=0x1d5cb20, vertexSource=..., fragmentSource=...) at /home/src/build/x86_64/kdebase-workspace/src/kdebase-workspace/kwin/libkwineffects/kwinglutils.cpp:790 #9 0x00007ff547e63121 in KWin::GLShader::loadFromFiles (this=0x1d5cb20, vertexFile=..., fragmentFile=...) at /home/src/build/x86_64/kdebase-workspace/src/kdebase-workspace/kwin/libkwineffects/kwinglutils.cpp:746 #10 0x00007ff547e66567 in KWin::ShaderManager::initShaders (this=0x1b65980) at /home/src/build/x86_64/kdebase-workspace/src/kdebase-workspace/kwin/libkwineffects/kwinglutils.cpp:1243 #11 0x00007ff547e66c09 in KWin::ShaderManager::ShaderManager (this=0x1b65980) at /home/src/build/x86_64/kdebase-workspace/src/kdebase-workspace/kwin/libkwineffects/kwinglutils.cpp:1100 #12 0x00007ff547e66c47 in KWin::ShaderManager::instance () at /home/src/build/x86_64/kdebase-workspace/src/kdebase-workspace/kwin/libkwineffects/kwinglutils.cpp:1082 #13 0x00007ff549da0d85 in KWin::SceneOpenGL::SceneOpenGL (this=0x1bd1a00, ws=<value optimized out>) at /home/src/build/x86_64/kdebase-workspace/src/kdebase-workspace/kwin/scene_opengl_glx.cpp:96 #14 0x00007ff549d8bc97 in KWin::Workspace::setupCompositing (this=0x1bfc190) at /home/src/build/x86_64/kdebase-workspace/src/kdebase-workspace/kwin/composite.cpp:128 #15 0x00007ff549d8c275 in KWin::Workspace::setupCompositing (this=<value optimized out>) at /home/src/build/x86_64/kdebase-workspace/src/kdebase-workspace/kwin/composite.cpp:94 #16 0x00007ff549d103ac in KWin::Workspace::Workspace (this=0x1bfc190, restore=false) at /home/src/build/x86_64/kdebase-workspace/src/kdebase-workspace/kwin/workspace.cpp:225 #17 0x00007ff549d2805a in KWin::Application::Application (this=<value optimized out>) at /home/src/build/x86_64/kdebase-workspace/src/kdebase-workspace/kwin/main.cpp:319 #18 0x00007ff549d29d2b in kdemain (argc=<value optimized out>, argv=<value optimized out>) at /home/src/build/x86_64/kdebase-workspace/src/kdebase-workspace/kwin/main.cpp:488 #19 0x00007ff549991f6d in __libc_start_main () from /lib/libc.so.6 #20 0x00000000004005f1 in _start () crashes in glCreateProgram() -> driver bug Created attachment 60504 [details]
KWinrc diff
I got some progress. I atached working (kwinrc) , and crashing kwinrc(kwinrc.bak), but i can't see what would made KWin/fglrx not to crash. Maybe GLMode=TFP? The attachment is a diff and it says: -GLDirect=true +GLDirect=false which would indicate that the driver is crashing if you use LIBGL_ALWAYS_INDIRECT (which is set for fglrx) and try to create a direct context. /me votes for removing the checkbox. Hmm? Even if KWIN_DIRECT_GL=1 is set? Otherwise: to gain what? The user not being able to change the setting in case of conflict? I'd say we need to prioritize settings, ie. KWIN_DIRECT_GL=1 -> LIBGL_ALWAYS_INDIRECT=1 LIBGL_ALWAYS_INDIRECT=0 -> GLDirect=false since anything doesn't make sense anyway, and then have bool SceneOpenGL::initRenderingContext() { bool direct_rendering = options->glDirect; ... invoke compositingprefs (or check the env directly) to not attempt to create a direct context if ruled out by the above, yesno? (Yes: the driver is buggy, it should not crash - but we don't have to provoke it for no reason either, we know that we cannot get a direct context under those setups) On Tuesday 31 May 2011 21:05:25 Thomas Lübking wrote: > https://bugs.kde.org/show_bug.cgi?id=273697 > > > > > > --- Comment #12 from Thomas Lübking <thomas luebking gmail com> 2011-05-31 21:05:24 --- > Hmm? Even if KWIN_DIRECT_GL=1 is set? > > Otherwise: to gain what? > The user not being able to change the setting in case of conflict? > > I'd say we need to prioritize settings, ie. > > KWIN_DIRECT_GL=1 -> LIBGL_ALWAYS_INDIRECT=1 > LIBGL_ALWAYS_INDIRECT=0 -> GLDirect=false > > since anything doesn't make sense anyway, and then have > > bool SceneOpenGL::initRenderingContext() > { > bool direct_rendering = options->glDirect; > ... > > invoke compositingprefs (or check the env directly) to not attempt to create a > direct context if ruled out by the above, yesno? > > (Yes: the driver is buggy, it should not crash - but we don't have to provoke > it for no reason either, we know that we cannot get a direct context under > those setups) Yes that's exactly my thinking which makes the checkbox more or less obsolete. The decision for LIBGL_ALWAYS_INDIRECT is mostly derived from the opengl test program, only overwritten by KWIN_DIRECT_GL. To my knowledge the checkbox makes only sense for NVIDIA blob, as a) we want direct rendering with all mesa drivers due to nasty behavior if not direct (extensions still available even if not supported) b) we never want direct rendering for fglrx as it's too slooooooow c) NVIDIA can handle both. Changing the setting can have negative experience for mesa users (indirect context) and for fglrx users (crash as seen here). So doesn't really make sense to me to have it around. Summary: deriving options->glDirect from the env settings sounds fine. Or just remove the options completely and handle it inside the scene/compositing prefs/whatever. (In reply to comment #11) > which would indicate that the driver is crashing if you use > LIBGL_ALWAYS_INDIRECT (which is set for fglrx) and try to create a direct > context. > > > /me votes for removing the checkbox. Yes, i tried to change GLDirect to false , and then tried with KWIN_DIRECT_GL=1 --> result : crash. It didn't occurred to me that these two are in conflict. But , i must say that the performace with fglrx/direct rendering/KWin 4.6.80 is muuuch better then fglrx/direct rendering/KWin =< 4.6.3 (but not on par with indirect rendering). (In reply to comment #14) > But , i must say that the performace with fglrx/direct rendering/KWin 4.6.80 is > muuuch better then fglrx/direct rendering/KWin =< 4.6.3 (but not on par with > indirect rendering). Is the gap only driven to the lanczos filter ("accurate" scale method) and blur effect which iirc both do not apply on indirect contexts? (In reply to comment #13) > To my knowledge the checkbox makes only sense for NVIDIA blob, as > ... Great, so we've an option that can cause contradicting settings and will allow most users to only shoot their foot? If it is that simple (everything but fglrx (?) should use dri by default) it should certainly go away (and if stay, then control what's currently managed by the environment variables) (In reply to comment #15) > Is the gap only driven to the lanczos filter ("accurate" scale method) and blur > effect which iirc both do not apply on indirect contexts? > The gap is mostly visible while minimazing/maximazing using any scale method. Blur doesn't suffer in performance, at least i can see. I would even say only minimazing/maximizing (but not as before) is affected by direct/indirect rendering. *** Bug 278655 has been marked as a duplicate of this bug. *** |