http://bugs.winehq.org/show_bug.cgi?id=9810
Summary: wined3d calls GDI and USER functions inside ENTER_GL/LEAVE_GL Product: Wine Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: wine-directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: julliard@winehq.org
No GDI or USER function should be called from inside an ENTER_GL/LEAVE_GL block.
The main offender seems to be the context management; it looks like it abuses ENTER_GL to also lock its own data structures, so it's probably not just a matter of removing the ENTER_GL blocks.
http://bugs.winehq.org/show_bug.cgi?id=9810
Roderick Colenbrander thunderbird2k@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at, | |thunderbird2k@gmx.net
--- Comment #1 from Roderick Colenbrander thunderbird2k@gmx.net 2007-09-29 08:24:41 --- I have checked what functions can cause problems. I haven't included surface.c and the buffer code as Stefan is rewriting those. The main issues are in surface.c. The surface code itself is making various opengl calls for no reason and big parts of the wined3d code are calling surface code like PreLoad/LoadTexture and even from withing ENTER_GL. Both pieces of code so now and then make calls to ActivateContext.
The surface code might be using ENTER_GL correctly (I think I took care of that a while ago) but due to recursive ENTER_GL calls, ActivateContext is called within ENTER_GL/LEAVE_GL. (Because other source files are called PreLoad/LoadTexture between ENTER_GL/LEAVE_GL)
The following pieces of code are not correct: cubetexture.c: - Preload calls surface.c its LoadTexture which can call ActivateContext context.c: - CreateContext should do its own ENTER_GL/LEAVE_GL - ActivateContext should do its own ENTER_GL/LEAVE_GL (the ENTER_GL was added in m y e77da5ef8ac09dc40acf25783fd39617ff32e51c patch which prevented calling ActivateContext between ENTER_GL, ActivateContext itself wasn't updated yet) device.c: - call to CreateContext should not be made between ENTER_GL/LEAVE_GL directx.c: - CreateFakeGLContext makes GDI calls between ENTER_GL drawprim.c: - blt_to_drawable does is a helper function and perhaps shouldn't do its own ENTER_GL. Its called from another helper function but that one can't be within ENTER_GL/LEAVE_GL either as it is making a lot of other wined3d calls which can have their own ENTER_GL and which call ActivateContext and friends. swapchain.c: - Present makes lots of wined3d calls between ENTER_GL, various of the calls call ActivateContext and friends, so they are potential problems volume.c: - PreLoad calls at least surface.c its LoadTexture which can call ActivateContext
http://bugs.winehq.org/show_bug.cgi?id=9810
--- Comment #2 from Stefan Dösinger stefandoesinger@gmx.at 2007-09-29 09:08:26 --- I think we should check more than that, and should check where we're calling gl at all. Ideally we would perform opengl calls only once per d3d draw, blit, clear or frontbuffer unlock call. This would help in regards of multithreaded apps. Many are rendering from one thread only, but create and load resources from other threads. There are situations in which we create an additional context for a new thread just to call glDeleteTextures in surface.c.
http://bugs.winehq.org/show_bug.cgi?id=9810
--- Comment #3 from Stefan Dösinger stefandoesinger@gmx.at 2007-09-29 09:09:52 --- (In reply to comment #0)
The main offender seems to be the context management; it looks like it abuses ENTER_GL to also lock its own data structures, so it's probably not just a matter of removing the ENTER_GL blocks.
It was originally used for this purpose, but the data structures are protected by the client libs' lock, so the context manager doesn't need ENTER_GL / LEAVE_GL for that purpose any more.
http://bugs.winehq.org/show_bug.cgi?id=9810
Mike pmike2001@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pmike2001@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=9810
--- Comment #4 from Austin English austinenglish@gmail.com 2008-06-04 12:00:13 --- Is this still an issue in 1.0-rc3 or newer wine?
http://bugs.winehq.org/show_bug.cgi?id=9810
--- Comment #5 from Stefan Dösinger stefandoesinger@gmx.at 2008-06-04 12:02:54 --- yes, there are a few indirect cases where a function is called with the x11drv log held and calls GDI functions.
http://bugs.winehq.org/show_bug.cgi?id=9810
--- Comment #6 from Austin English austinenglish@gmail.com 2008-12-02 06:53:14 --- Is this still an issue in 1.1.9?
http://bugs.winehq.org/show_bug.cgi?id=9810
--- Comment #7 from Roderick Colenbrander thunderbird2k@gmx.net 2008-12-02 08:09:35 --- It could still be the case in some places though in most cases there are no recursive ENTER_GL/LEAVE_GL calls anymore. Though there are some 'new' gdi functions like glFlush/glFinish which might not be outside ENTER_GL everywhere.
http://bugs.winehq.org/show_bug.cgi?id=9810
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source
http://bugs.winehq.org/show_bug.cgi?id=9810
--- Comment #8 from Austin English austinenglish@gmail.com 2009-12-31 11:19:39 --- Probably still present.
http://bugs.winehq.org/show_bug.cgi?id=9810
--- Comment #9 from Henri Verbeet hverbeet@gmail.com 2009-12-31 11:38:54 --- (In reply to comment #8)
Probably still present.
Actually, this is fixed in the general case. It's always possible that there are individual cases that violate the policy, but I checked the entire wined3d GL locking not too long ago.
http://bugs.winehq.org/show_bug.cgi?id=9810
--- Comment #10 from Austin English austinenglish@gmail.com 2009-12-31 12:07:46 --- (In reply to comment #9)
(In reply to comment #8)
Probably still present.
Actually, this is fixed in the general case. It's always possible that there are individual cases that violate the policy, but I checked the entire wined3d GL locking not too long ago.
I figured Alexandre would mark it as resolved when it's fixed to his satisfaction ;-).
http://bugs.winehq.org/show_bug.cgi?id=9810
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2010-01-01 04:53:20 --- Fixed then.
http://bugs.winehq.org/show_bug.cgi?id=9810
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Jeff Zaroyko jeffz@jeffz.name 2010-01-09 04:54:58 --- Closing bugs fixed in 1.1.36.
-
wine-bugs＠winehq.org