256359 2010-11-08 12:37:52 +0000 glXBindTexImageEXT-related problems with r600 2010-12-04 18:01:15 +0000 1 1 4 Plasma kwin compositing unspecified FreeBSD Ports FreeBSD RESOLVED FIXED NOR normal --- 1 avg kwin-bugs-null david fredrik ont pdezac-linux rakuco wonko 4.5.5 0 oldest_to_newest 1041704 0 avg 2010-11-08 12:37:52 +0000 Version: unspecified (using KDE 4.5.3) OS: FreeBSD Using KDE 4.5.3 on FreeBSD I get the following message endlessly repeated in Xorg.log file: __glXDRIbindTexImage: Failed to register texture offset override Once Xorg server even crashed with the following stack trace: #0 0x00000008022eb93c in kill () from /lib/libc.so.7 #1 0x00000008022ea6ab in abort () from /lib/libc.so.7 #2 0x00000008022d3db5 in __assert () from /lib/libc.so.7 #3 0x00000008171b6bc7 in radeon_store_teximage () from /usr/local/lib/dri/r600_dri.so #4 0x00000008171b7347 in radeon_teximage () from /usr/local/lib/dri/r600_dri.so #5 0x00000008171b77f5 in radeonTexImage2D () from /usr/local/lib/dri/r600_dri.so #6 0x0000000817223870 in _mesa_TexImage2D () from /usr/local/lib/dri/r600_dri.so #7 0x00000008030831c9 in __glXDRIbindTexImage (baseContext=0x829eb0b40, buffer=8414, glxPixmap=0x8303e9280) at glxdri.c:526 #8 0x000000080306ddef in __glXDisp_BindTexImageEXT (cl=0x829e8c8e0, pc=0x802a3ba0c "So�\001� ") at glxcmds.c:1579 #9 0x000000080306f72d in __glXDisp_VendorPrivate (cl=0x829e8c8e0, pc=0x802a3ba00 "\231\020\006") at glxcmds.c:2290 #10 0x00000008030756ef in __glXDispatch (client=0x80281f800) at glxext.c:578 #11 0x000000000044f590 in Dispatch () at dispatch.c:439 #12 0x0000000000421857 in main (argc=8, argv=0x7fffffffe8c0, envp=0x7fffffffe908) at main.c:285 I didn't have this problem with KDE 4.5.2. I have verified that the problem goes away if I back out r1189359 and r1189360. I haven't tried yet to see what happens when I backout each one of those revisions individually. Please note that FreeBSD doesn't support yet many recent APIs that Linux supports (DRI2, GEM, KMS), so direct rendering drivers in Mesa and X server might be taking different code paths. Perhaps, newer KDE just exposes a bug in X or Mesa. But perhaps it depends on a certain way of things to work. Or maybe there is some genuine X resource leak that is less visible on Linux. Reproducible: Always 1041774 1 wonko 2010-11-08 16:11:51 +0000 I also get these messages in Xorg.log since I upgraded to 4.5.3. But I'm not a FreeBSD user, I run Gentoo Linux: wonko@weird ~ $ uname -a Linux weird 2.6.36-tuxonice #1 SMP PREEMPT Sat Oct 30 01:07:54 CEST 2010 x86_64 AMD Athlon(tm) Dual Core Processor 4850e AuthenticAMD GNU/Linux wonko@weird ~ $ lspci | grep VGA 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3200 Graphics BTW, Andriy has exactly the same Radeon hardware. 1042789 2 pdezac-linux 2010-11-10 18:11:25 +0000 Hi, I am a Mandriva 2010.1 user and also get this king of messages since kde 4.5.3 upgrade. This may be the cause of my X reboot. xsession-errors extraction : http://pastebin.mandriva.com/21191 Xorg.0.log.old : http://pastebin.mandriva.com/21192 uname -a : Linux PC_Master 2.6.33.7-desktop-2mnb lspcidrake | grep VGA Card:ATI Radeon HD 2000 and later (radeon/fglrx): ATI Technologies Inc|RV670PRO [Radeon HD 3850] [DISPLAY_VGA] 1043193 3 fredrik 2010-11-11 19:57:41 +0000 I am guessing none of you are using kernel mode setting since the function that prints that error message is a DRI1 function? I need to know which of those two commits caused the regression to be able to work around this. 1043447 4 avg 2010-11-12 11:49:46 +0000 (In reply to comment #3) > I am guessing none of you are using kernel mode setting since the function that > prints that error message is a DRI1 function? Definitely no KMS here on FreeBSD. > I need to know which of those two commits caused the regression to be able to > work around this. r1189359 alone causes the symptom to appear for me. 1048416 5 ont 2010-11-23 13:39:44 +0000 Also seeing this with Fedora F13, after upgrade to KDE 4.5.3 1049876 6 david 2010-11-26 21:19:47 +0000 I'm seeing this error in my xorg log as well: FreeBSD 8.1, KDE 4.5.3, intel driver using DRI1. 1050279 7 53809 fredrik 2010-11-27 21:50:02 +0000 Created attachment 53809 Possible fix Does this patch fix the problem? 1052307 8 avg 2010-12-02 12:36:43 +0000 (In reply to comment #7) > Created an attachment (id=53809) [details] > Possible fix > > Does this patch fix the problem? Unfortunately it doesn't, still the same issue: __glXDRIbindTexImage: Failed to register texture offset override BTW, just in case, here's how kwin reports OpenGL properties in my case: kwin(99925) KWin::CompositingPrefs::detectDriverAndVersion: GL vendor is "Advanced Micro Devices, Inc." kwin(99925) KWin::CompositingPrefs::detectDriverAndVersion: GL renderer is "Mesa DRI R600 (RS780 9610) 20090101 TCL" kwin(99925) KWin::CompositingPrefs::detectDriverAndVersion: GL version is "1.4 (2.0 Mesa 7.8.2)" kwin(99925) KWin::CompositingPrefs::detectDriverAndVersion: Detected driver "radeon" , version "20090101" kwin(99925): ""fsrestore1" - conversion of "0,0,0,0" to QRect failed" kwin(99925): ""fsrestore2" - conversion of "0,0,0,0" to QRect failed" kwin(99925): ""restore3" - conversion of "0,0,0,0" to QRect failed" kwin(99925): ""fsrestore3" - conversion of "0,0,0,0" to QRect failed" kwin(99925): ""restore4" - conversion of "0,0,0,0" to QRect failed" kwin(99925): ""fsrestore4" - conversion of "0,0,0,0" to QRect failed" kwin(99925): DB: true , TFP: true , SHM: false , Direct: false kwin(99925) KWin::EffectsHandlerImpl::loadEffect: EffectsHandler::loadEffect : Effect "kwin4_effect_blur" is not supported 1052322 9 avg 2010-12-02 13:03:39 +0000 BTW, I also see the following messages here: WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug! WARNING: Application calling GLX 1.3 function "glXQueryDrawable" when GLX 1.3 is not supported! This is an application bug! WARNING: Application calling GLX 1.3 function "glXDestroyPixmap" when GLX 1.3 is not supported! This is an application bug! glxinfo output: name of display: :2.0 IRQ's not enabled, falling back to busy waits: 2 0 display: :2 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: Mesa DRI R600 (RS780 9610) 20090101 TCL OpenGL version string: 2.0 Mesa 7.8.2 OpenGL shading language version string: 1.10 1052434 10 avg 2010-12-02 16:31:09 +0000 I think that I've found a workaround or a fix for this issue. But no in KDE! Here's what I did. I looked at the code in X server that produces the error message. The code is in glx/glxdri.c. The message is produced when all sixteen slots are filled. 16 is some magic value not connected to any other parameter or value. So I simply changed 16 to 64 and everything seems to be fine now without any changes to KDE code. So I guess that KDE may genuinely use more than 16 "somethings" and simply hits a hardcoded limitation in the X server. I guess that without the recent optimization kwin would not have more than 16 "somethings" concurrently, but now that it caches them, the number gets larger. What do you think? 1052436 11 53978 avg 2010-12-02 16:38:21 +0000 Created attachment 53978 xorg-server patch The xorg-server patch. How should I proceed with it further? 1053360 12 avg 2010-12-04 14:56:29 +0000 I've submitted a report about this issue to freedesktop bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32095 1053474 13 fredrik 2010-12-04 17:17:11 +0000 I just realized that I misread the revision number, and the patch I attached would only have fixed the problem if it was the other commit that had introduced the regression. In order to render a window using OpenGL kwin has to bind the window pixmap to a texture, and what r1189359 does is change the way kwin does that so that it doesn't release the pixmap immediately after rendering the texture. But from your findings it would seem that with indirect rendering, there is a limit to how many pixmaps can be bound to textures simultaneously, which is what is causing the problem. The limit could be increased in the server, or even made dynamic, but I'm going to revert this change since kwin needs to work with the current version of the X server. It's probably not be a good idea to keep more than 16 pixmaps bound to textures simultaneously anyway, since it uses up video memory. The other commit (r1189360) is also the important one since it alone is sufficient to fix the problem these commits were intended to address. 1053498 14 fredrik 2010-12-04 17:56:15 +0000 SVN commit 1203578 by fredrik: Revert to always calling glXBindTexImageEXT() before rendering. The GLX implementation in the X server appears to have a hardcoded limit to how many pixmaps can be bound to textures simultaneously when using indirect rendering, which we can end up exceeding with the changes introduced in r1182198. BUG: 256359 FIXED-IN: 4.5.5 M +9 -10 scene_opengl.cpp M +0 -1 scene_opengl.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1203578 1053502 15 fredrik 2010-12-04 18:01:15 +0000 SVN commit 1203579 by fredrik: Backport r1203578: Revert to always calling glXBindTexImageEXT() before rendering. The GLX implementation in the X server appears to have a hardcoded limit to how many pixmaps can be bound to textures simultaneously when using indirect rendering, which we can end up exceeding with the changes introduced in r1182198. CCBUG: 256359 M +9 -10 scene_opengl.cpp M +0 -1 scene_opengl.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1203579 53809 2010-11-27 21:50:02 +0000 2010-11-27 21:50:02 +0000 Possible fix kwin.patch text/plain 2061 fredrik SW5kZXg6IHNjZW5lX29wZW5nbC5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2NlbmVfb3BlbmdsLmNwcAko cmV2aXNpb24gMTE5NzA5MikKKysrIHNjZW5lX29wZW5nbC5jcHAJKHdvcmtpbmcgY29weSkKQEAg LTExMjksMTggKzExMjksMjQgQEAKICAgICAgICAgICAgICAgICBHTFhfTUlQTUFQX1RFWFRVUkVf RVhULCBmYmNkcmF3YWJsZWluZm9bIGRlcHRoIF0ubWlwbWFwLAogICAgICAgICAgICAgICAgIE5v bmUsIE5vbmUsIE5vbmUKICAgICAgICAgICAgICAgICB9OwotICAgICAgICAgICAgaWYgKCAoIGZi Y2RyYXdhYmxlaW5mb1sgZGVwdGggXS50ZXh0dXJlX3RhcmdldHMgJiBHTFhfVEVYVFVSRV8yRF9C SVRfRVhUICkgJiYKLSAgICAgICAgICAgICAgICAgKCBHTFRleHR1cmU6Ok5QT1RUZXh0dXJlU3Vw cG9ydGVkKCkgfHwKLSAgICAgICAgICAgICAgICAgICAoIGlzUG93ZXJPZlR3byhzaXplLndpZHRo KCkpICYmIGlzUG93ZXJPZlR3byhzaXplLmhlaWdodCgpKSApKSkKKyAgICAgICAgICAgIC8vIGds WEJpbmRUZXhJbWFnZUVYVCgpIGlnbm9yZXMgdGhlIHRleHR1cmUgdGFyZ2V0IHdpdGggRFJJMSwg c28gb25seQorICAgICAgICAgICAgLy8gc3BlY2lmeSB0aGUgdGV4dHVyZSB0YXJnZXQgZXhwbGlj dGx5IHdoZW4gd2UncmUgdXNpbmcgRFJJMi4KKyAgICAgICAgICAgIC8vIChXZSB3b24ndCBiZSB1 c2luZyBkaXJlY3QgcmVuZGVyaW5nIHdpdGggRFJJMSkKKyAgICAgICAgICAgIGlmICggZ2xYSXNE aXJlY3QoIGRpc3BsYXkoKSwgY3R4YnVmZmVyICkgKQogICAgICAgICAgICAgICAgIHsKLSAgICAg ICAgICAgICAgICBhdHRyc1sgNCBdID0gR0xYX1RFWFRVUkVfVEFSR0VUX0VYVDsKLSAgICAgICAg ICAgICAgICBhdHRyc1sgNSBdID0gR0xYX1RFWFRVUkVfMkRfRVhUOworICAgICAgICAgICAgICAg IGlmICggKCBmYmNkcmF3YWJsZWluZm9bIGRlcHRoIF0udGV4dHVyZV90YXJnZXRzICYgR0xYX1RF WFRVUkVfMkRfQklUX0VYVCApICYmCisgICAgICAgICAgICAgICAgICAgICAoIEdMVGV4dHVyZTo6 TlBPVFRleHR1cmVTdXBwb3J0ZWQoKSB8fAorICAgICAgICAgICAgICAgICAgICAgICAoIGlzUG93 ZXJPZlR3byhzaXplLndpZHRoKCkpICYmIGlzUG93ZXJPZlR3byhzaXplLmhlaWdodCgpKSApKSkK KyAgICAgICAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAgICAgICBhdHRyc1sgNCBdID0g R0xYX1RFWFRVUkVfVEFSR0VUX0VYVDsKKyAgICAgICAgICAgICAgICAgICAgYXR0cnNbIDUgXSA9 IEdMWF9URVhUVVJFXzJEX0VYVDsKKyAgICAgICAgICAgICAgICAgICAgfQorICAgICAgICAgICAg ICAgIGVsc2UgaWYgKCBmYmNkcmF3YWJsZWluZm9bIGRlcHRoIF0udGV4dHVyZV90YXJnZXRzICYg R0xYX1RFWFRVUkVfUkVDVEFOR0xFX0JJVF9FWFQgKQorICAgICAgICAgICAgICAgICAgICB7Cisg ICAgICAgICAgICAgICAgICAgIGF0dHJzWyA0IF0gPSBHTFhfVEVYVFVSRV9UQVJHRVRfRVhUOwor ICAgICAgICAgICAgICAgICAgICBhdHRyc1sgNSBdID0gR0xYX1RFWFRVUkVfUkVDVEFOR0xFX0VY VDsKKyAgICAgICAgICAgICAgICAgICAgfQogICAgICAgICAgICAgICAgIH0KLSAgICAgICAgICAg IGVsc2UgaWYgKCBmYmNkcmF3YWJsZWluZm9bIGRlcHRoIF0udGV4dHVyZV90YXJnZXRzICYgR0xY X1RFWFRVUkVfUkVDVEFOR0xFX0JJVF9FWFQgKQotICAgICAgICAgICAgICAgIHsKLSAgICAgICAg ICAgICAgICBhdHRyc1sgNCBdID0gR0xYX1RFWFRVUkVfVEFSR0VUX0VYVDsKLSAgICAgICAgICAg ICAgICBhdHRyc1sgNSBdID0gR0xYX1RFWFRVUkVfUkVDVEFOR0xFX0VYVDsKLSAgICAgICAgICAg ICAgICB9CiAgICAgICAgICAgICBnbHhwaXhtYXAgPSBnbFhDcmVhdGVQaXhtYXAoIGRpc3BsYXko KSwgZmJjZHJhd2FibGVpbmZvWyBkZXB0aCBdLmZiY29uZmlnLCBwaXgsIGF0dHJzICk7CiAjaWZk ZWYgQ0hFQ0tfR0xfRVJST1IKICAgICAgICAgICAgIGNoZWNrR0xFcnJvciggIlRleHR1cmVMb2Fk VEZQMSIgKTsK 53978 2010-12-02 16:38:21 +0000 2010-12-02 16:38:21 +0000 xorg-server patch xorg-server-glxdri.diff text/plain 1151 avg LS0tIGdseC9nbHhkcmkuYy5vcmlnCTIwMTAtMTItMDIgMTc6MzI6NDguNjkxMzU2NDczICswMjAw CisrKyBnbHgvZ2x4ZHJpLmMJMjAxMC0xMi0wMiAxNzozNDowNi4yNjMzNjIyMzcgKzAyMDAKQEAg LTgzLDcgKzgzLDggQEAKICAgICBjb25zdCBfX0RSSXRleE9mZnNldEV4dGVuc2lvbiAqdGV4T2Zm c2V0OwogICAgIERSSVRleE9mZnNldFN0YXJ0UHJvY1B0ciB0ZXhPZmZzZXRTdGFydDsKICAgICBE UklUZXhPZmZzZXRGaW5pc2hQcm9jUHRyIHRleE9mZnNldEZpbmlzaDsKLSAgICBfX0dMWERSSWRy YXdhYmxlICp0ZXhPZmZzZXRPdmVycmlkZVsxNl07CisjZGVmaW5lIE5VTV9URVhfT0ZGU0VUX09W RVJSSURFUwk2NAorICAgIF9fR0xYRFJJZHJhd2FibGUgKnRleE9mZnNldE92ZXJyaWRlW05VTV9U RVhfT0ZGU0VUX09WRVJSSURFU107CiAgICAgR0x1aW50IGxhc3RUZXhPZmZzZXRPdmVycmlkZTsK ICNlbmRpZgogCkBAIC00MTgsMTcgKzQxOSwxNyBAQAogCiAgICAgaWYgKHRlc3RUZXhPZmZzZXQo c2NyZWVuLCBwaXhtYXApKSB7CiAJX19HTFhEUklkcmF3YWJsZSAqKnRleE9mZnNldE92ZXJyaWRl ID0gc2NyZWVuLT50ZXhPZmZzZXRPdmVycmlkZTsKLQlpbnQgaSwgZmlyc3RFbXB0eSA9IDE2Owor CWludCBpLCBmaXJzdEVtcHR5ID0gTlVNX1RFWF9PRkZTRVRfT1ZFUlJJREVTOwogCi0JZm9yIChp ID0gMDsgaSA8IDE2OyBpKyspIHsKKwlmb3IgKGkgPSAwOyBpIDwgTlVNX1RFWF9PRkZTRVRfT1ZF UlJJREVTOyBpKyspIHsKIAkgICAgaWYgKHRleE9mZnNldE92ZXJyaWRlW2ldID09IGRyaURyYXcp CiAJCWdvdG8gYWxyZWFkeWluOyAKIAotCSAgICBpZiAoZmlyc3RFbXB0eSA9PSAxNiAmJiAhdGV4 T2Zmc2V0T3ZlcnJpZGVbaV0pCisJICAgIGlmIChmaXJzdEVtcHR5ID09IE5VTV9URVhfT0ZGU0VU X09WRVJSSURFUyAmJiAhdGV4T2Zmc2V0T3ZlcnJpZGVbaV0pCiAJCWZpcnN0RW1wdHkgPSBpOwog CX0KIAotCWlmIChmaXJzdEVtcHR5ID09IDE2KSB7CisJaWYgKGZpcnN0RW1wdHkgPT0gTlVNX1RF WF9PRkZTRVRfT1ZFUlJJREVTKSB7CiAJICAgIEVycm9yRigiJXM6IEZhaWxlZCB0byByZWdpc3Rl ciB0ZXh0dXJlIG9mZnNldCBvdmVycmlkZVxuIiwgX19mdW5jX18pOwogCSAgICBnb3RvIG5vb3Zl cnJpZGU7CiAJfQo=