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;