[wined3d] Status update: Converting Wined3d to use WGL instead of GLX

[Aric Cyr]

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.

[wined3d] Status update: Converting Wined3d to use WGL instead of GLX

[Stefan Dösinger]

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

[wined3d] Status update: Converting Wined3d to use WGL instead of GLX

[Aric Cyr]

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

[wined3d] Status update: Converting Wined3d to use WGL instead of GLX

[Stefan Dösinger]

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

[wined3d] Status update: Converting Wined3d to use WGL instead of GLX

[Aric Cyr]

Hi Stefan,

On 1/12/06, Stefan Dösinger  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)

[wined3d] Status update: Converting Wined3d to use WGL instead of GLX

[Stefan Dösinger]

> 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

[wined3d] Status update: Converting Wined3d to use WGL instead of GLX

[Aric Cyr]

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

[wined3d] Status update: Converting Wined3d to use WGL instead of GLX

[Jesse Allen]

On 1/14/06, Aric Cyr  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.

[wined3d] Status update: Converting Wined3d to use WGL instead of GLX

[Tom Wickline]

On 1/11/06, Aric Cyr  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

[wined3d] Status update: Converting Wined3d to use WGL instead of GLX

[Lionel Ulmer]

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

[wined3d] Status update: Converting Wined3d to use WGL instead of GLX

[Aric.Cyr]

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