On 9/17/06, Phil Costin philcostin@hotmail.com wrote:
Roderick Colenbrander wrote:
The problem is that I'm not sure (and I think it is Alexandre his issue aswell) whether this patch is a workaround or a real fix. I think that wined3d created a GLX context in lets say thread '1' and that it wants to create lets say another one in a different thread. If this is the case it could happen that for the new thread the x11drv visual needs to be 'rechosen'. This causes the 'info' code to be called again. Because this code creates a context we mess up the already active context.
Your patch indeed fixes that by storing the current GLX context and restoring it later on. Perhaps there's a nicer way to prevent this issue to happen at all.
In any case I think it might be nicer to use glXGetCurrentContext in case there's already some GLX context around. So in that case don't create a new context and don't kill it at the end. This would already be cleaner.
Roderick
I don't know myself either. I was just going to wait. I want to add a little more to say about it.
It's funny that the patch was only meant to affect the opengl/wgl code and the crashing apps are all d3d ones. However winex11 will now change the context on it's own when doing the opengl query and not set it back. What I noticed a couple weeks ago and now is that winex11 does usually gets inited twice, therefore it will change the current context twice. One at the start of the program, and another later on -- maybe on creation of a window or something. By that time wined3d is probably inited too, and making glXMakeCurrent calls too since it's based on opengl. So perhaps winex11 is causing wined3d to trip up at some point by changing the context. So if InitOpenglInfo just sets things back, then wined3d won't go boom.
From comments in wined3d, I can tell there isn't any "context
manager". So what wined3d does at most is very simple management of contextes. We probably need a manager to coordinate things like this better between the two libraries. But that will likely be a bigger patch and to do so... I don't know, we need a fix for all the broken d3d apps now.
Jesse
At the moment, this patch fixes regressions so if we don't have the code in there at all, many games do not work.
It may not be the ideal solution but is it not better for now to fix the regression and think about a proper solution separately without breaking applications by not having the patch applied?
Regards, Phil
Phil, Roderick,
I'm going to look at what I can do to improve the patch and gather more information on the handling of contextes. I just haven't had time yet. And Roderick, I'll discuss with you the newer patch when I'm ready so to see if you agree with it. I do lean towards agreeing with Phil on that this is simply needed and more than a workaround. I've already been asked many times if the patch has gotten in and that is why I posted to wine-patches so quickly; your patch broke alot of D3D apps for alot of people... The d3d9 stateblock test is the best clue.
Jesse
Hi,
I had a little amount of time to look at the issue and have posted a fix to the list. It appeared that the GLX context did still exist when X11DRV_InitOpenGLInfo got called the second time from a different thread. This most likely turned wined3d in a multithreaded OpenGL app which doesn't allways work well as OpenGL isn't threadsafe. By switching to a NULL context before killing the context, it got killed immedeately (before it became inactive which it never became). This fixes atleast 3dmark2001 and halflife2.
Roderick
Phil, Roderick,
I'm going to look at what I can do to improve the patch and gather more information on the handling of contextes. I just haven't had time yet. And Roderick, I'll discuss with you the newer patch when I'm ready so to see if you agree with it. I do lean towards agreeing with Phil on that this is simply needed and more than a workaround. I've already been asked many times if the patch has gotten in and that is why I posted to wine-patches so quickly; your patch broke alot of D3D apps for alot of people... The d3d9 stateblock test is the best clue.
Jesse
On 9/18/06, Roderick Colenbrander thunderbird2k@gmx.net wrote:
Hi,
I had a little amount of time to look at the issue and have posted a fix to the list. It appeared that the GLX context did still exist when X11DRV_InitOpenGLInfo got called the second time from a different thread. This most likely turned wined3d in a multithreaded OpenGL app which doesn't allways work well as OpenGL isn't threadsafe. By switching to a NULL context before killing the context, it got killed immedeately (before it became inactive which it never became). This fixes atleast 3dmark2001 and halflife2.
Roderick
It works with stateblock test too. So yes, that solved the actual problem.
Jesse
-
Jesse Allen -
Roderick Colenbrander