[wined3d] Status update: Converting Wined3d to use WGL instead of GLX
Hi all, Just wanted to chime in with a status update on my porting of wined3d to WGL. Basically, I am in the debug phase, and at this point most bugs have been ironed out. That is, for dx9 stuff. I soon ran into problems/regressions with dx8 or lower (including ddraw!). So I ended up repeating the (almost) exactly same work for d3d8 and ddraw... not a pretty sight, and a pain to debug them all. As a result this conversion has become a fairly large and invasive change affecting all versions of directx... [I can't wait for all these to be completely ported to wined3d]. For testing d3d8 I've been using 3DMark2001SE and some DirectX tutorial/demo apps. For d3d9 I use World of Warcraft (hehe) and more tutorial/demo apps. I forget what I used for d3d7 though... I'll have to double check that. Most of the problems I've come across were GLXContext related... namely due to a problem in wine's wgl which causes an app to think there is a current context, when infact there isn't. (See wglGetCurrentContext in wgl.c, and see what happens when there is no glX context, especially between calls to wglCreateContext and wglMakeCurrent). Another change I made which I'm not sure about and would like feedback for, is to change wgl's process_attach to use wgl functions instead of glX functions. The reason for this is so that the GLXContext that is created will be properly added to the context list so it can be used for other purposes. This should reduce the number of GL contexts by one for all d3d and (behaved) opengl apps. I'm currently in the process of cleaning everything up and then I will post a patch on my site for people to download. Due to the scope of the changes, I really hope that people can help me test this sucker... once that's done I'll chop up the patch into logical pieces and submit them. That's all for now! - Aric P.S. If anyone wants, they can edit http://winehq.org/site/fun_projects and put me down for the "wined3d use wgl" project.
Hi,
Basically, I am in the debug phase, and at this point most bugs have been ironed out. That is, for dx9 stuff. I soon ran into problems/regressions with dx8 or lower (including ddraw!). So I ended up repeating the (almost) exactly same work for d3d8 and ddraw... not a pretty sight, and a pain to debug them all. Is it necessary to change all this libs at once? What if you changed WineD3D only, and wait for the d3d7 and d3d8 rewrite. Once these use WineD3D, the'll automatically use wgl, if I'm not mistaken :)
As a result this conversion has become a fairly large and invasive change affecting all versions of directx... [I can't wait for all these to be completely ported to wined3d]. Well, at least ddraw has to wait until after my math test, I'm afraid :(
Stefan
Stefan Dösinger <stefandoesinger <at> gmx.at> writes:
Hi,
Basically, I am in the debug phase, and at this point most bugs have been ironed out. That is, for dx9 stuff. I soon ran into problems/regressions with dx8 or lower (including ddraw!). So I ended up repeating the (almost) exactly same work for d3d8 and ddraw... not a pretty sight, and a pain to debug them all. Is it necessary to change all this libs at once? What if you changed WineD3D only, and wait for the d3d7 and d3d8 rewrite.
Unfortunately no. At first this was my plan as well and I had only ported wined3d. However upon testing any d3d8 or d3d7 apps, they all broke. The reason was that they are already partially using wined3d and the mix of glX and wgl calls was causing many problems. That's when I realized that it would be all or nothing. The other option is for me to wait for all d3d and ddraw stuff to be ported to wined3d before merging my wgl stuff, but my stuff is already done and who knows when the ddraw/d3d stuff will be completely ported to wined3d. Another scenario would be to port to wined3d just the ddraw/d3d* functions that use glX directly. I haven't looked into this though, so it may not even be possible.
As a result this conversion has become a fairly large and invasive change affecting all versions of directx... [I can't wait for all these to be completely ported to wined3d]. Well, at least ddraw has to wait until after my math test, I'm afraid :(
Good luck! :) Regards, Aric
Hi,
Unfortunately no. At first this was my plan as well and I had only ported wined3d. However upon testing any d3d8 or d3d7 apps, they all broke. The reason was that they are already partially using wined3d and the mix of glX and wgl calls was causing many problems. That's when I realized that it would be all or nothing. That is odd: As far as I know, d3d8 only loads WineD3D to load the DX configuration. And I've found no sign of WineD3D usage in the old ddraw libs.
Stefan
Hi Stefan, On 1/12/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Hi,
Unfortunately no. At first this was my plan as well and I had only ported wined3d. However upon testing any d3d8 or d3d7 apps, they all broke. The reason was that they are already partially using wined3d and the mix of glX and wgl calls was causing many problems. That's when I realized that it would be all or nothing. That is odd: As far as I know, d3d8 only loads WineD3D to load the DX configuration. And I've found no sign of WineD3D usage in the old ddraw libs.
Although technically there doesn't seem to be any links between ddraw and wined3d, it is possible for a 3D app to use d3d8 with ddraw. In fact this is exactly what 3DMark2001SE does, and it is the reason I ended up porting ddraw as well. Of course I would have preferred having to only modify wined3d, but I wanted to prevent as many regressions as possible when I finally submit my changes, so I went ahead and did ddraw along with d3d8 and wined3d. Regards, Aric -- Aric Cyr <Aric.Cyr at gmail dot com> (http://acyr.net)
The other option is for me to wait for all d3d and ddraw stuff to be ported to wined3d before merging my wgl stuff, but my stuff is already done and who knows when the ddraw/d3d stuff will be completely ported to wined3d. I guess that will slow down the process terribly.
Another scenario would be to port to wined3d just the ddraw/d3d* functions that use glX directly. I haven't looked into this though, so it may not even be possible. I don't expect this to work, at least not without much modification to the WineD3D initialization code.
The problem is that we are doing a lot of redundant work here. Oliver is working in d3d8, I'm working on ddraw, and you are working on moving all of them to wgl. At least your work on ddraw and d3d8 would be for nothing in the long term, and could be avoided with a better cooperation. One way would be to remove all WineD3D dependancy from today's ddraw and d3d8, so they remain untouched until Oliver and I replace them. But if ddraw is really affected by changes to WineD3D, allthough it shouldn't to my knowledge, this might be a more subtile problem. How about creating a temponary fork of the whole tree, so we can submit all our patches there without breaking wine. There's no need for this tree to work for any game at first, so broken patches are no problem. Once our patches coexist nicely, we can introduce them to main cvs. (The danger is, of course, that the differences take overhand and the forking can't be undone any more) What do you think about this? Stefan
Stefan Dösinger <stefandoesinger <at> gmx.at> writes:
The problem is that we are doing a lot of redundant work here. Oliver is working in d3d8, I'm working on ddraw, and you are working on moving all of them to wgl. At least your work on ddraw and d3d8 would be for nothing in the long term, and could be avoided with a better cooperation.
I'm fine with my ddraw and d3d8 stuff being thrown away in the future. I personally see it as a temporary fix to prevent regressions while ddraw and d3d8 are ported to wined3d. The real majority of work was in wined3d anyways, so it was just a matter of wash-rinse-repeat with dddraw and d3d8. It's just the testing that is a pain :)
One way would be to remove all WineD3D dependancy from today's ddraw and d3d8, so they remain untouched until Oliver and I replace them. But if ddraw is really affected by changes to WineD3D, allthough it shouldn't to my knowledge, this might be a more subtile problem.
As I sent you off-list, 3DMark2001SE makes initial capability queries with ddraw, then uses d3d8 for everything else. I assume a similar thing could occur for d3d9 apps, so there really is no way we can guarantee a separation between ddraw/d3d8 and wined3d as far as I can tell. So it's gonna be all wgl or nothing if we don't want a lot of regressions.
How about creating a temponary fork of the whole tree, so we can submit all our patches there without breaking wine. There's no need for this tree to work for any game at first, so broken patches are no problem. Once our patches coexist nicely, we can introduce them to main cvs. (The danger is, of course, that the differences take overhand and the forking can't be undone any more)
What do you think about this?
It's a lot of extra work for nothing really. There should be minimal conflicts with my patches and whatever you guys are working on. The only exception would be if you added or changes glX code. Even in the case of a conflict, it should be a trivial merge since wgl and glX are so similar. I'm willing to do the merge myself if you expect the ddraw and d3d8 code to be submitted soon, otherwise I'll just submit my wgl stuff and leave it up to you and Olvier to merge your patches. Anyways, I'm still bug hunting so I won't be submitting very soon. So hurry up with ddraw and d3d8! ;) Regards, Aric
On 1/14/06, Aric Cyr <Aric.Cyr(a)gmail.com> wrote:
How about creating a temponary fork of the whole tree, so we can submit all our patches there without breaking wine. There's no need for this tree to work for any game at first, so broken patches are no problem. Once our patches coexist nicely, we can introduce them to main cvs. (The danger is, of course, that the differences take overhand and the forking can't be undone any more)
What do you think about this?
It's a lot of extra work for nothing really. There should be minimal conflicts with my patches and whatever you guys are working on. The only exception would be if you added or changes glX code. Even in the case of a conflict, it should be a trivial merge since wgl and glX are so similar.
I'm willing to do the merge myself if you expect the ddraw and d3d8 code to be submitted soon, otherwise I'll just submit my wgl stuff and leave it up to you and Olvier to merge your patches.
Anyways, I'm still bug hunting so I won't be submitting very soon. So hurry up with ddraw and d3d8! ;)
Regards, Aric
I'm certainly in favor of having a temporary git fork for directx changes. So I can just pull the patch from there anytime instead of waiting for periodic test patches. The periodic patches haven't always applied cleanly either. These improvements are big changes and it would be nice if doing this would speed it up, since everyone could now work together.
On 1/11/06, Aric Cyr <Aric.Cyr(a)gmail.com> wrote:
Hi all,
Hello Aric,
Just wanted to chime in with a status update on my porting of wined3d to WGL.
:-)
For testing d3d8 I've been using 3DMark2001SE and some DirectX tutorial/demo apps. For d3d9 I use World of Warcraft (hehe) and more tutorial/demo apps. I forget what I used for d3d7 though... I'll have to double check that.
May I ask what kind of score your getting? and some basic hardware specs. I'm planning on updating my little benchmark page on the Wiki soon (TM) And I'm getting a score of: 6225 at 800x600x32 NoAA Z24 5663 at 1152x864x32 NoAA Z24 with a build from CVS, I'm just curious about what kind of performance your getting with your build.
- Aric
P.S. If anyone wants, they can edit http://winehq.org/site/fun_projects and put me down for the "wined3d use wgl" project.
I sent a patch. Tom
On Thu, Jan 12, 2006 at 02:17:11AM +0000, Aric Cyr wrote:
Most of the problems I've come across were GLXContext related... namely due to a problem in wine's wgl which causes an app to think there is a current context, when infact there isn't. (See wglGetCurrentContext in wgl.c, and see what happens when there is no glX context, especially between calls to wglCreateContext and wglMakeCurrent).
Could you explain in more details what the problem is ?
Another change I made which I'm not sure about and would like feedback for, is to change wgl's process_attach to use wgl functions instead of glX functions. The reason for this is so that the GLXContext that is created will be properly added to the context list so it can be used for other purposes. This should reduce the number of GL contexts by one for all d3d and (behaved) opengl apps.
This default context was only added to prevent one game from breaking (do not remember the name of it though) which did some 'glGet' stuff before creating its context. I checked that this worked just fine in Windows but did not work properly in GLX (where calling any GL function without a context set generates an error) so the only way I found out to work around the problem was to add this default context. And if you put in the context_list, in that case 'wglGetCurrentContext' will return this dummy context (instead of NULL as in the current code as it won't find this dummy one in the linked list). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Lionel Ulmer <lionel.ulmer <at> free.fr> writes:
On Thu, Jan 12, 2006 at 02:17:11AM +0000, Aric Cyr wrote:
Most of the problems I've come across were GLXContext related... namely due to a problem in wine's wgl which causes an app to think there is a current context, when infact there isn't. (See wglGetCurrentContext in wgl.c, and see what happens when there is no glX context, especially between calls to wglCreateContext and wglMakeCurrent).
Could you explain in more details what the problem is ?
Sure :) The problem occurs is wglGetCurrentContext is called between wglCreateContext and wglMakeCurrent, and there is no real glX context current. In this case glXGetCurrentContext() will return NULL, and wglGetCurrentContext will then search for a context matching NULL, which will be the deferred context created by wglCreateContext. The fix is simply to return NULL from wglGetCurrentContext() if glXGetCurrentContext is NULL... I believe a similar issue would happen in wglGetCurrentDC() as well, but I haven't verified it (other than visually).
Another change I made which I'm not sure about and would like feedback for, is to change wgl's process_attach to use wgl functions instead of glX functions. The reason for this is so that the GLXContext that is created will be properly added to the context list so it can be used for other purposes. This should reduce the number of GL contexts by one for all d3d and (behaved) opengl apps.
This default context was only added to prevent one game from breaking (do not remember the name of it though) which did some 'glGet' stuff before creating its context.
Yes, I gathered that from the comments, I just didn't know how common this case was.
And if you put in the context_list, in that case 'wglGetCurrentContext' will return this dummy context (instead of NULL as in the current code as it won't find this dummy one in the linked list).
The reason I put it in the context list is so that it can be seen by wglGetCurrentContext. Even though it is a hack for a broken game, there doesn't seem any reason to me to make it invisible to other applications. It is just a way of potentially saving the resources for one render context. Personally I'd love to get rid of that context all-together, but since it fixes a bug, I guess there is no choice. Regards, Aric
participants (6)
-
Aric Cyr -
Aric.Cyr
-
Jesse Allen -
Lionel Ulmer -
Stefan Dösinger -
Tom Wickline