[Bug 42324] Wine selects wrong OpenGL renderer on macOS

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=42324

Ken Thomases <ken at codeweavers.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #57133|0                           |1
        is obsolete|                            |

--- Comment #14 from Ken Thomases <ken at codeweavers.com> ---
Created attachment 57235
  --> https://bugs.winehq.org/attachment.cgi?id=57235
Patch to restrict pixel formats for multi-renderer systems

(In reply to Rastafabi from comment #13)
> First off thank you for diagnosing the issue though not having access to a
> system for inspection. However the fix does not seem to work. I couldn't
> apply it without removing the first 2 lines, which might have broken it's
> purpose (I'm not that into it). While I could apply the patch afterwards it
> ended up in a useless MacDriver which couldn't even draw a window whatsoever.

I'm not sure why the old patch wouldn't apply.  I've replaced it with one
that's been rebased on the tip (wine-2.1-126-g06c5a9a).  If it doesn't apply,
please explain what you're doing and how it's failing.

In any case, a broken or misapplied patch to the opengl.c file within the Mac
driver code should not break general window drawing.  Programs which don't use
OpenGL would not be affected by that code at all.


> Apart from this I observed another important factor. It may not necessarily
> be valid in general, but the few test cases I tried so far all have this in
> common. While the issue I described earlier basically still is true it only
> applies in special cases: The issue does not exist, when running those 32bit
> DirectX 9 executables (Valley/Heaven benchmark) in a pure 32bit wine build,
> while they issue persists with 64bit builds of the very same engines (tried
> several back to 1.9.9). So far I haven't tested wether 64bit Direct x9
> programs suffer from the same issues (while being run in WOW64 and pure
> 64bit wine prefixes). Can anyone recommend a DX9-64bit test executable?
> (available in 32 & 64bit).
> Speaking of different build though I can tell so far that 64bit OpenGL exes
> (Cinebench/GPUTest 0.7.0) aren't affected while I cannot tell about 32bit
> ones (any recommendations?)
> 
> Does this clear anything or is it getting even more twisted?

It doesn't make things immediately clearer to me, no.  Are you using the same
winver regardless of the build?  (For example, you might be using Win7 for
64-bit but WinXP for 32-bit.)

When you say the "issue persists with 64bit builds of the very same engines",
I'm not sure which thing you kept the same and which you changed?  Do you mean
the issue (only) affects 32-bit Windows apps running in a WoW64 Wine build?


> I understood how the GL context switching works and why. However I still
> think, that while it is API conform it does not apply do real-world
> conditions as even nativ Mac application do not do so (seemingly for a good
> reason - black screen and significant performance drops until restarted,
> even when moved to the screen with the MUCH faster PU). That's why I think
> it should be changed or at better switchable using some registry keys.

The problem is that it's not clear how to do things differently so that it
won't be affected by the issue.  The OpenGL context may be created before the
window is shown on the screen or positioned on the screen where you will use
it.  It's actually possible to create it using an HDC from one window and then
use it with a different window.  It's not clear to me if, on Windows, screens
connected to different GPUs count as a different "devices" in the sense of the
HDC.  In any case, Wine doesn't currently have the infrastructure to treat
things that way.

The Mac driver can't destroy and recreate the OpenGL context when it detects
which screen the window has been shown on or moved to.  The app may have done
one-time configuration of the context after it was first created and the Mac
driver can't make it repeat the configuration for the new context.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.