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
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.
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]
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.
(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.
Also seeing this with Fedora F13, after upgrade to KDE 4.5.3
I'm seeing this error in my xorg log as well: FreeBSD 8.1, KDE 4.5.3, intel driver using DRI1.
Created attachment 53809 [details] Possible fix Does this patch fix the problem?
(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
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
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?
Created attachment 53978 [details] xorg-server patch The xorg-server patch. How should I proceed with it further?
I've submitted a report about this issue to freedesktop bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32095
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.
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
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