Version: CVS (using Devel) OS: Linux If i try to use direct rendering with "KWIN_DIRECT_GL=1 kwin --replace &" , kwin chrashes , and says compositing is not possible. Without direct rendering it works great. Reproducible: Always Steps to Reproduce: KWIN_DIRECT_GL=1 kwin --replace & Actual Results: Kwin chrashes Expected Results: Kwin and compositing works I got this messages: OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: ATI Mobility Radeon HD 3650 OpenGL version string: 3.3.10750 Compatibility Profile Context OpenGL shading language version string: 3.30 Driver: Catalyst Driver version: 3.3.10750 GPU class: R600 OpenGL version: 3.3.10750 GLSL version: 3.30 X server version: 1.9.4 Linux kernel version: 2.6.38 Direct rendering: yes Requires strict binding: yes GLSL shaders: yes Texture NPOT support: yes Application::crashHandler() called with signal 11; recent crashes: 1 KCrash: Application 'kwin' crashing... KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit sock_file=/home/test/.kde4/socket-shumarija/kdeinit4__0 kwin(18805): Compositing is not possible With this backtrace: #11 0x00007f2b6d189c47 in KWin::ShaderManager::instance() () from /usr/lib/libkwineffects.so.1 #12 0x00007f2b6f0c3d75 in ?? () from /usr/lib/libkdeinit4_kwin.so #13 0x00007f2b6f0aec97 in ?? () from /usr/lib/libkdeinit4_kwin.so #14 0x00007f2b6f0af275 in ?? () from /usr/lib/libkdeinit4_kwin.so #15 0x00007f2b6f0333ac in ?? () from /usr/lib/libkdeinit4_kwin.so #16 0x00007f2b6f04b05a in ?? () from /usr/lib/libkdeinit4_kwin.so #17 0x00007f2b6f04cd2b in kdemain () from /usr/lib/libkdeinit4_kwin.so #18 0x00007f2b6ecb4f6d in __libc_start_main () from /lib/libc.so.6 #19 0x00000000004005f1 in _start ()
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. ***