Fixing conflicts between WineD3D and WGL

[Roderick Colenbrander]

On Thu, Jan 30, 2014 at 4:34 AM, Henri Verbeet <hverbeet at gmail.com> wrote:

> On 29 January 2014 22:34, Ken Thomases <ken at codeweavers.com> wrote:
> > My point is that the current GL context is exposed through WGL but it
> also affects the behavior of GL functions (of course).  So, while we might
> be able to hide the change of the current GL context from
> wglGetCurrentContext(), that doesn't do us any good because we need GL
> functions to target the right context.  There's just no getting around
> switching the current GL context to WineD3D's when WineD3D needs to call GL
> functions and then back to the app's when control is returned to it.
>  (Except Chris's point of doing all GL on a different thread.)
> >
> > Do you know what makes wglMakeCurrent() expensive?  For X11, we'll still
> have to use glXMakeCurrent(), which sets the context drawable, even for my
> proposed wglMakeContextCurrentWINE().  Maybe it's the setting of the
> drawable that's expensive.  For the Mac, we can just make the context
> current without setting the drawable again.  That might be less expensive,
> although maybe there's a lot of thread state inside the GL engine that has
> to be swapped in and out.  (I would hope that that would all be stored in
> the context and switching contexts would be just a matter of swapping a
> pointer somewhere.)
> >
> I'm not sure. I have the impression most of the time is inside the
> driver instead of e.g. winex11 though.
>
>
At some I had a similar use case regarding hiding contexts more at the
SwapBuffers level for individual frames. The initial implementation used
context switching which worked, but Nvidia heavily discouraged us from
using it. At least their implementation (on Fermi/Kepler at the time)
performed a pipeline flush every context switch (I guess at glFlush or
worse), which makes glXMakeCurrent a very heavy call.

The other option as Chris said is moving GL to a different thread. Choosing
between two evils, I would probably more lean that way.

I have had a quick look at the tickets, but are all the issues ddraw
related or are there other known issues for newer d3d versions for which
this also helps?

We may also want to take into account future situations in which WineD3D
and GL may have conflicts. Maybe at some point we want to handle some of
the OpenGL / Direct3D (very Nvidia specifc) interop extensions or the
OpenCL versions. At least for D3D/GL interop there are probably funny
situations, though we may not care.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20140202/06535343/attachment.html>