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

On 29 January 2014 22:34, Ken Thomases <ken@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.