Bug 30220 - Change windowExistsErrorHandler to drawableExistsErrorHandler in glxcmds.c ?
Change windowExistsErrorHandler to drawableExistsErrorHandler in glxcmds.c ?
Status: NEW
Product: Mesa
Classification: Unclassified
Component: GLX
unspecified
Other All
: medium normal
Assigned To: mesa-dev
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-16 00:52 UTC by jpsinthemix
Modified: 2010-10-04 21:41 UTC (History)
2 users (show)

See Also:


Attachments
patch to Change windowExistsErrorHandler to drawableExistsErrorHandler in glxcmds.c (1.38 KB, application/octet-stream)
2010-09-16 00:52 UTC, jpsinthemix
Details
Patch to fix GarbageCollectDRIDrawables for Pixmaps w/o a Window (594 bytes, patch)
2010-09-17 02:59 UTC, jpsinthemix
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description jpsinthemix 2010-09-16 00:52:32 UTC
Created attachment 38733 [details]
patch to Change windowExistsErrorHandler to drawableExistsErrorHandler in glxcmds.c 

There currently exists a situation in KDE-4.5.X where at certain moments, a current context does not have a valid associated Window, but does have a valid pixmap drawable. If, at such a moment, a call is made to glXDestroyContext() on another no longer needed non-current context, glXDestroyContext() releases pixmap-associated resources that are in use by the current context, resulting in system hangs.

A possible patch to remedy this changes BadWindow to BadDrawable in
windowExistsErrorHandler of Mesa-7.8.3-rc1.old/src/glx/glxcmds.c (I have also attached the patch; does this make sense?):


--- Mesa-7.8.3-rc1.old/src/glx/glxcmds.c        2010-09-16 03:14:45.074000414 -0400
+++ Mesa-7.8.3-rc1.new/src/glx/glxcmds.c        2010-09-16 03:37:43.932000358 -0400
@@ -68,14 +68,14 @@

 #if defined(GLX_DIRECT_RENDERING) && !defined(GLX_USE_APPLEGL)

-static Bool windowExistsFlag;
+static Bool drawableExistsFlag;
 static int
-windowExistsErrorHandler(Display * dpy, XErrorEvent * xerr)
+drawableExistsErrorHandler(Display * dpy, XErrorEvent * xerr)
 {
    (void) dpy;

-   if (xerr->error_code == BadWindow) {
-      windowExistsFlag = GL_FALSE;
+   if (xerr->error_code == BadDrawable) {
+      drawableExistsFlag = GL_FALSE;
    }
    return 0;
 }
@@ -98,13 +98,13 @@
    /* Set no-op error handler so Xlib doesn't bail out if the windows
     * has alreay been destroyed on the server. */
    XSync(dpy, GL_FALSE);
-   oldXErrorHandler = XSetErrorHandler(windowExistsErrorHandler);
+   oldXErrorHandler = XSetErrorHandler(drawableExistsErrorHandler);

    if (__glxHashFirst(sc->drawHash, &draw, (void *) &pdraw) == 1) {
       do {
-         windowExistsFlag = GL_TRUE;
+         drawableExistsFlag = GL_TRUE;
          XGetWindowAttributes(dpy, draw, &xwa); /* dummy request */
-         if (!windowExistsFlag) {
+         if (!drawableExistsFlag) {
             /* Destroy the local drawable data, if the drawable no
                longer exists in the Xserver */
             (*pdraw->destroyDrawable) (pdraw);
Comment 1 jpsinthemix 2010-09-17 02:59:04 UTC
Created attachment 38759 [details] [review]
Patch to fix GarbageCollectDRIDrawables for Pixmaps w/o a Window
Comment 2 Shane 2010-09-18 02:41:33 UTC
Please do look into this bug as it affects a wide range of hardware and a lot of users as is evidenced in the KDE bug report.

If more information is required to implement or find the proper resolution, I will try to provide what I can.
Comment 3 Christopher James Halse Rogers 2010-09-22 00:42:15 UTC
The code posted applies to mesa 7.8, but has been removed in 7.9.  It would be useful to
a) Test if this bug still applies to mesa 7.9 from git (I've been told it applies to a snapshot from 2010/09/09, but haven't been able to reproduce it myself).

and if it still occurs, then
b) Port the patch to the 7.9 branch & master.
Comment 4 jpsinthemix 2010-09-22 03:44:59 UTC
(In reply to comment #3)
> The code posted applies to mesa 7.8, but has been removed in 7.9.  It would be
> useful to
> a) Test if this bug still applies to mesa 7.9 from git (I've been told it
> applies to a snapshot from 2010/09/09, but haven't been able to reproduce it
> myself).
> 
> and if it still occurs, then
> b) Port the patch to the 7.9 branch & master.

Thanks for looking at this. So, do I understand correctly, that the patch is ok on Mesa-7.8.x ? If this is so, then everyone now using KDE-4.5.x (and presumably Mesa-7.8.x), can use it.

I'd love also to test it out on 7.9 -- but I tried several weeks ago and ran into trouble -- I think with the intel driver (xf86-video-intel-2.12.0). I'll try again and get back to you on this.

Have you or anyone had a chance to look at BUG #30217 ?

thanks again
Comment 5 jpsinthemix 2010-10-04 15:07:48 UTC
I just did a build using Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04) (i915), with xorg-server-1.9.0, xf86-video-2.13.0, libdrm-2.4.22, mesa-7.9-rc2, qt-4.7.0, kde-4.5.1, and linux-2.6.35.7. This is decidedly way downhill (from xorg-server-1.8.2/Mesa-7.8.2) - desktop effects will not even activate anymore. I can force-activate them, but then video is so slow as to be entirely unusable. Perhaps related to a new error message in .xsession-errors:

i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4)

This is the only error (Xorg.0.log looks good).


Summary of some build variations (all using qt-4.7.0, kde-4.5.1., and linux-2.6.35.7):

mesa-7.8.2,  libdrm-2.4.21, xorg-server-1.8.2, xf86-video-2.12.0
  ----> works (with glxcmd.c patch submitted earlier)

mesa-7.8.2,  libdrm-2.4.22, xorg-server-1.8.2, xf86-video-2.13.0 
   ----> works (with glxcmd.c patch submitted earlier)

mesa-7.8.2,  libdrm-2.4.21, xorg-server-1.9.0, xf86-video-2.13.0
   ----> cannot start X -- cannot connect to server

mesa-7.8.2,  libdrm-2.4.22, xorg-server-1.9.0, xf86-video-2.13.0
   ----> cannot start X -- cannot connect to server

mesa-7.9rc2, libdrm-2.4.22, xorg-server-1.8.2, xf86-video-2.13.0
   ----> cannot start X -- cannot connect to server

mesa-7.9rc2, libdrm-2.4.22, xorg-server-1.9.0, xf86-video-2.13.0
   ----> X runs, but no openGL available under kde
         (forcing openGL is SLOW: 5 seconds to move a window, plus various artifacts
   ----> i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4);
         (src/mesa/drivers/dri/i915/i915_program.c)
Comment 6 Rex Dieter 2010-10-04 18:53:08 UTC
Re: comment #3

Testing using Fedora 14 beta, 
kernel-2.6.35.4-28.fc14
libdrm-2.4.21-3.fc14
mesa-7.9-0.8.fc14
xorg-x11-server-1.9.0-9.fc14
xorg-x11-drv-intel-2.12.0-6.fc14

mesa here is a 20100922 git snapshot.  I can confirm the original symptoms remain.
Comment 7 jpsinthemix 2010-10-04 21:41:59 UTC
An update with some good news regarding comment #3:

I did further testing with the following setup:

  Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (i915)
  xorg-server-1.9.0, xf86-video-2.13.0, libdrm-2.4.22, mesa-7.9-rc2, qt-4.7.0
  kde-4.5.1, linux-2.6.35.7

As I stated in comment #5, with this build, desktop (GLX) effects will not activate. There's a kde desktop effect called 'blur' which is activated on first kde-desktop boot on my system, but has never worked on my system. Up to now, I've just left it on as it doesn't appear to cause any problems. However, with this new build, 'blur' is in fact the culprit: if I first manually turn off this effect then GLX effects are activated, and the Pixmap destroy issue does not occur.

Conclusion: Problem exists in Mesa-7.8.2/3rc1, but has been fixed in Mesa-7.9rc2.

The unrelated 'blur' issue, at least for the moment, is kde's problem...

thanks for your time.