[Bug 42324] New: Wine selects wrong OpenGL renderer on macOS
https://bugs.winehq.org/show_bug.cgi?id=42324 Bug ID: 42324 Summary: Wine selects wrong OpenGL renderer on macOS Product: Wine Version: 2.0-rc6 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: critical Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: f.platte(a)platte-web.de Created attachment 57072 --> https://bugs.winehq.org/attachment.cgi?id=57072 example images I'm using a 13 inch 2012 MacBook Pro with a Thunderbolt eGPU (GTX 750Ti). Due to macOS limitations the the eGPU can only accelerate the external monitor. (Some application which support selecting a renderer work on the internal display. e.g openglex4 [OpenGL Extensions Viewer]). To my knowledge the macOS applications else always use the renderer driving the screen where they are launched on. However wine does not respect this behaviour. I tried running several windows executables like the benchmark tools Valley and Heaven which keep using the Mac's internal Intel HD4000 graphics although being used on the external screen. I tried several wine engines from the staging, stable and development tree, which all are affected. To check wether it might be an OS related issue I also ran the Mac-native versions of the benchmarks mentioned above which both worked as expected (using the OpenGL renderer driving the monitor they are launched on). This basically breaks games and other GPU heavy windows programs in my case. I do not know whether hackintoshes are affected as well as they basically are the only other macOS machines having integrated and dedicated GPU driving different monitors. The logical solution seems to be to make wine respect the way macOS assigns renderer while an ideal solution would be implementing a way to select a renderer/always default to the dedicated GPU as this would enable accelerating the internal monitor with the external GPU like it's possible with windows. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 Rastafabi <f.platte(a)platte-web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ken(a)codeweavers.com -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 Henri Verbeet <hverbeet(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|directx-d3d |winemac.drv --- Comment #1 from Henri Verbeet <hverbeet(a)gmail.com> --- I think this is primarily a winemac.drv issue. In the ideal case there's a wined3d component to this as well, to allow selecting a specific render through WGL_WINE_query_renderer, but the default is selected by winemac.drv. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #2 from Rastafabi <f.platte(a)platte-web.de> --- Sounds logical. Sadly I can't test the X11 driver right now as I just updated to Sierra 10.12.4 Beta and there are no compatible NVIDIA drivers released yet. (edited 10.12.3 driver do not work) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #3 from Henri Verbeet <hverbeet(a)gmail.com> --- For what it's worth, from a quick look I think the relevant code in winemac.drv is mostly map_renderer_index() and create_pixel_format_for_renderer(), but I'm not terribly familiar with winemac.drv. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #4 from Ken Thomases <ken(a)codeweavers.com> --- At the point where the Mac driver initializes OpenGL, queries its extensions, and enumerates its pixel formats, it uses the primary display. However, when it creates an OpenGL context for rendering, it doesn't tie it to any specific display[*]. That should result in a context which automatically switches to the appropriate GPU as the window is moved. In Apple's terminology, the context changes which "virtual screen" is active for the context. In theory, a Mac app should note when the context's virtual screen changes, re-query the GL extensions and limits, and reconfigure its rendering pipeline accordingly. However, Windows OpenGL apps are not prepared to do that. In theory, D3D apps should cope if WineD3D would tell them that the device was "lost", but the Mac driver doesn't have a good way to tell WineD3D that and, to my knowledge, WineD3D doesn't currently support marking devices as lost. What are the actual symptoms you're seeing? Is it just that the benchmarks are reporting the name of the GPU as "Intel HD4000"? Or are they actually running *really* slowly (more slowly, even, then when the window is on the internal display)? Also, what precisely do you mean that this "basically breaks games and other GPU heavy windows programs"? How are they broken? Also, what happens if you change the primary display to the external? In System Preferences > Displays > Arrangement, drag the representation of the menu bar from the internal display to the external. [*] In theory, the caller could request that the context be tied to a specific renderer by including the WGL_RENDERER_ID_WINE attribute in the attribute list passed to wglCreateContextAttribsARB(). However, WGL_RENDERER_ID_WINE is a Wine-specific attribute that no caller other than WineD3D would know to use, and WineD3D does not actually use it. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #5 from Henri Verbeet <hverbeet(a)gmail.com> --- (In reply to Ken Thomases from comment #4)
In Apple's terminology, the context changes which "virtual screen" is active for the context. In theory, a Mac app should note when the context's virtual screen changes, re-query the GL extensions and limits, and reconfigure its rendering pipeline accordingly. However, Windows OpenGL apps are not prepared to do that. In theory, D3D apps should cope if WineD3D would tell them that the device was "lost", but the Mac driver doesn't have a good way to tell WineD3D that and, to my knowledge, WineD3D doesn't currently support marking devices as lost.
Not in wined3d itself, but wined3d clients like ddraw or d3d9 do. See e.g. device_parent_mode_changed() and device_parent_activate() in ddraw. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #6 from Rastafabi <f.platte(a)platte-web.de> --- I just downgraded back to 10.9.3 as I was curious about wether the X11 driver would make a difference: Indeed it does. Now it's working as expected! (This means I can do further testing if needed.) (In reply to Ken Thomases from comment #4)
[…]
What are the actual symptoms you're seeing? Is it just that the benchmarks are reporting the name of the GPU as "Intel HD4000"? Or are they actually running *really* slowly (more slowly, even, then when the window is on the internal display)?
Not only the wrong name is reported. The benchmark actually runs on the wrong renderer (resulting in nearly the same score as if run on the internal screen).
Also, what precisely do you mean that this "basically breaks games and other GPU heavy windows programs"? How are they broken?
"Broken" might not have been the correct term to use. I meant it in a way that the whole purpose of the eGPU does not work for those programs. As they are accelerated by the low-power internal graphic-unit they are "unusable" in terms of fps and graphics quality.
Also, what happens if you change the primary display to the external? In System Preferences > Displays > Arrangement, drag the representation of the menu bar from the internal display to the external.
That's how it's set up. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #7 from Rastafabi <f.platte(a)platte-web.de> --- Another important note: The scores shown in the screenshot are NOT comparable at all - the wine one uses FullHD on lowest settings with the Intel HD4000, while the native one uses High Settings on FullHD with 4x Antialiasing. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #8 from Rastafabi <f.platte(a)platte-web.de> --- (In reply to Ken Thomases from comment #4)
In Apple's terminology, the context changes which "virtual screen" is active for the context. In theory, a Mac app should note when the context's virtual screen changes, re-query the GL extensions and limits, and reconfigure its rendering pipeline accordingly.
This might very well be theory because in reality I never came across an application which re-querys it's pipeline. All games benchmarks and GL-heavy applications I tested ran way better if launched on the external eGPU powers screen even if they were moved to the internal one afterwards. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #9 from Rastafabi <f.platte(a)platte-web.de> --- I made some additional testing. Windows programs with native OpenGL (no directx conversion, tested with Cinebench) also do work as expected with the MacDriver (using the renderer of the display they are launched on). Doesn't this indicate it's an D3D related issue, rather than a MacDriver related one? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #10 from Rastafabi <f.platte(a)platte-web.de> --- (In reply to Rastafabi from comment #9)
I made some additional testing. Windows programs with native OpenGL (no directx conversion, tested with Cinebench) also do work as expected with the MacDriver (using the renderer of the display they are launched on). Doesn't this indicate it's an D3D related issue, rather than a MacDriver related one?
Okay, it's getting strange. Some more details: Cinebench Mac version sticks to the GL renderer of the display it was initially launched on. - Even if moved while running the GL benchmark and even if starting the GL benchmark on another screen. Cinebench PC version does re-querying every time the window is moved from one display to another (while running benchmarks as well as when starting a new one) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #11 from Rastafabi <f.platte(a)platte-web.de> --- Any thoughts on this one? I think, that windows programs using should reflect the behaviour of the native applications, although it might not be 100% conform with official development guidelines (concerning the re-querys). Especially as while this underlyingly seems to work with the nativ OpenGL programs concerning their score it heavily degrades the experience as the UI driven on the screen actually does not reflect these theoretical behaviour, but makes the GL animation (after some second with a black window only) being rendered more like a slight show, even if moved to the more powerful external GPU. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #12 from Ken Thomases <ken(a)codeweavers.com> --- Created attachment 57133 --> https://bugs.winehq.org/attachment.cgi?id=57133 Patch to restrict pixel formats for multi-renderer systems (In reply to Rastafabi from comment #11)
Any thoughts on this one? I think, that windows programs using should reflect the behaviour of the native applications, although it might not be 100% conform with official development guidelines (concerning the re-querys).
As I've said, the Mac driver sets up its OpenGL contexts so that they should automatically track the appropriate GPU.
Especially as while this underlyingly seems to work with the nativ OpenGL programs concerning their score it heavily degrades the experience as the UI driven on the screen actually does not reflect these theoretical behaviour, but makes the GL animation (after some second with a black window only) being rendered more like a slight show, even if moved to the more powerful external GPU.
It's nearly impossible to debug something like this without being able to reproduce it myself. Unfortunately, I don't have a system with an external GPU with which to test. I'm attaching a patch which probably won't make any difference but might help. You can give it a try and see. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #13 from Rastafabi <f.platte(a)platte-web.de> --- 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. 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? --- 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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 Ken Thomases <ken(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #57133|0 |1 is obsolete| | --- Comment #14 from Ken Thomases <ken(a)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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #15 from Rastafabi <f.platte(a)platte-web.de> --- (In reply to Ken Thomases from comment #14)
Created attachment 57235 [details] Patch to restrict pixel formats for multi-renderer systems
(In reply to Rastafabi from comment #13)
[…]
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.
I'll test when I can (getting ready for vacation).
[…]
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.)
All test were made using winver = Win7.
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?
Difference are the prefixes: One is Wine 2.0 WINEARCH=32, one is Wine 2.0 WINEARCH=64 - both with a clean install of the 32-bit-only DirectX 9 program.
Do you mean the issue (only) affects 32-bit Windows apps running in a WoW64 Wine build?
Partly Yes. At least 32-bit Windows apps in 32-bit prefixes aren't affected. However I couldn't try 64bit (DirectX 9) apps in 64-bit prefixes as I don't know an appropriate program for this.
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.
Got it.
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.
I think I kind of understand. But when it can't repeat configuration why not disable the need for it? -> Disable redetection of screen where it currently runs after initial window creation on whatever screen. - Just keep it running in the original 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #16 from Rastafabi <f.platte(a)platte-web.de> --- (In reply to Ken Thomases from comment #14)
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.
I committed several (dump) errors at once. This time it went smooth. However the patch does not work. I'm still facing the same issue. That said I found one 64bit Wine build, made for Wineskin, that works just fine. http://www.insanelymac.com/forum/topic/308994-binary-releases-and-tests/#ent... However, as many patches went into it I can't tell which on fixes the issue. https://github.com/SergeySlice/Wine-Sherry/tree/master/patches -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 --- Comment #17 from Rastafabi <f.platte(a)platte-web.de> --- Still valid. Now of greater concern as it is an offical macOS feature. New linked bug: #45626 https://bugs.winehq.org/show_bug.cgi?id=45626 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=42324 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #18 from joaopa <jeremielapuree(a)yahoo.fr> --- Does the bug still occur with wine-7.0-rc5? -- 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.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla