[EMAIL PROTECTED] 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;