[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: X11, ATI and GDI Error
From:       Chris Ahrendt <celticht32 () aol ! com>
Date:       2008-07-31 3:59:05
Message-ID: 48913889.40209 () aol ! com
[Download RAW message or body]

celticht32@aol.com wrote:
> While looking at bug 13335 ( 
> http://bugs.winehq.org/show_bug.cgi?id=13335) which is An ATI and wine bug.
> I noticed something in one of the updates :
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462715
> 
> 
> 
> Now this set me to searching  as I really didn't like the idea of wrapping the \
> libGL calls with 'winmemory' allocations 
> (To many areas of corruption possibilities and just isn't an ellegant solution). \
> The Debian post above points out something 
> very interesting :
> 
> 
> 
> " After more investigation, I was able to trace this to a bug in my OpenGL  
> 
> initialization logic.
> 
> 
> 
> The following (psuedocode) sequence, forces fglrx to revert to indirect  
> 
> rendering:
> 
> dpy = XOpenDisplay()
> 
> visual = glXChooseVisual(dpy)
> 
> XCloseDisplay(dpy)
> 
> ..
> 
> dpy2 = XOpenDisplay()
> 
> ctx = glXCreateContext(dpy2, visual) <-- fglrx reverts to indirect  
> 
> rendering
> 
> ..
> 
> 
> 
> Changing the code to use the same display connection for glXChooseVisual  
> 
> and glXCreateContext solves this problem."
> 
> 
> 
> So looking at that I began to Grep the latest git tree  to find out where 
> 
> XOpenDisplay
> 
> glxChooseVisual
> 
> glxCreateContext
> 
> XCloseDisplay
> 
> 
> 
> are used.  There are only 2 places (and yes I know they are critical places) where \
> they are used. 
> opengl.c and x11drv_attach.c both in the winex11.drv directory. So I went through \
> and started looking 
> at how they were called and discovered that  the display variable (dpy and dpy2 in \
> the above pseudocode) is not  
> reused at all. It is allocated off the local stack of the subroutine it is in. \
> later on gdi_display which is the global 
> variable gets assigned display which calls the XOpenDisplay.  This gdi_display is \
> used as the global handle  
> if I am reading the code correctly.  
> 
> 
> 
> Now this is where my pointer knowledge goes south and I think this is right... and \
> this is where the problem might be: 
> 
> 
> in the process_attach routine someone says gdi_display = display.  Display is a \
> local pointer to the routine and will 
> go away when the function returns. 
> 
> 
> 
> Here is my theory :
> 
> 
> 
> with the ATI card being a pig for memory and Wine allocating alot of memory itself \
> the pointer to the driver gets invalidated 
> somehow corrupted etc. and when it is used later X thinks its another display and \
> everything happily crashes. 
> 
> 
> Mind you this is a theory right now but is this possible?  I think an easy fix to \
> this would be to do the following instead: 
> 
> 
> gdi_display = XopenDisplay()'; This allocates the display structure off the global \
> heap not the local heap 
> display = gdi_display;
> 
> 
> 
> and then leave the rest of the code alone.
> 
> 
> 
> Am I going down the right track with this? If so it would be alot simpler fix that \
> some of the ones out there being forced around. And it should not 
> effect any of the other supported cards.
> 
> 
> 
> Chris
> 
> 
> 
> ------------------------------------------------------------------------
> The Famous, the Infamous, the Lame - in your browser. Get the TMZ 
> Toolbar Now 
> <http://toolbar.aol.com/tmz/download.html?NCID=aolcmp00050000000014>!
> 
> 
> ------------------------------------------------------------------------
> 
> 

That FIXED IT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! the open gl error 
is now GONE! I am not using  ulimit... I am not using the comment patch 
in directx. Its a simple Change!!!!


in x11drv_main.c

change to this and I no longer get the opengl error at all:

     /* Open display */

     if (!(gdi_display = XOpenDisplay( NULL ))) return FALSE;
     display = gdi_display;


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic