Bug 256359 - glXBindTexImageEXT-related problems with r600
Summary: glXBindTexImageEXT-related problems with r600
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: unspecified
Platform: FreeBSD Ports FreeBSD
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-08 12:37 UTC by Andriy Gapon
Modified: 2010-12-04 18:01 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.5.5


Attachments
Possible fix (2.01 KB, patch)
2010-11-27 21:50 UTC, Fredrik Höglund
Details
xorg-server patch (1.12 KB, patch)
2010-12-02 16:38 UTC, Andriy Gapon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andriy Gapon 2010-11-08 12:37:52 UTC
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
Comment 1 Wonko 2010-11-08 16:11:51 UTC
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.
Comment 2 Fif59 2010-11-10 18:11:25 UTC
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]
Comment 3 Fredrik Höglund 2010-11-11 19:57:41 UTC
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.
Comment 4 Andriy Gapon 2010-11-12 11:49:46 UTC
(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.
Comment 5 Ole 2010-11-23 13:39:44 UTC
Also seeing this with Fedora F13, after upgrade to KDE 4.5.3
Comment 6 David Blewett 2010-11-26 21:19:47 UTC
I'm seeing this error in my xorg log as well:

FreeBSD 8.1, KDE 4.5.3, intel driver using DRI1.
Comment 7 Fredrik Höglund 2010-11-27 21:50:02 UTC
Created attachment 53809 [details]
Possible fix

Does this patch fix the problem?
Comment 8 Andriy Gapon 2010-12-02 12:36:43 UTC
(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
Comment 9 Andriy Gapon 2010-12-02 13:03:39 UTC
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
Comment 10 Andriy Gapon 2010-12-02 16:31:09 UTC
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?
Comment 11 Andriy Gapon 2010-12-02 16:38:21 UTC
Created attachment 53978 [details]
xorg-server patch

The xorg-server patch.
How should I proceed with it further?
Comment 12 Andriy Gapon 2010-12-04 14:56:29 UTC
I've submitted a report about this issue to freedesktop bugzilla:
https://bugs.freedesktop.org/show_bug.cgi?id=32095
Comment 13 Fredrik Höglund 2010-12-04 17:17:11 UTC
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.
Comment 14 Fredrik Höglund 2010-12-04 17:56:15 UTC
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
Comment 15 Fredrik Höglund 2010-12-04 18:01:15 UTC
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