https://bugs.winehq.org/show_bug.cgi?id=56163
Bug ID: 56163 Summary: Unigine Sanctuary is badly broken with OGL/WineD3D (only works with Gallium Nine) Product: Wine Version: 9.0-rc4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: opengl Assignee: wine-bugs@winehq.org Reporter: kle@bluewin.ch Distribution: ---
Created attachment 75862 --> https://bugs.winehq.org/attachment.cgi?id=75862 Unigine Sanctuary CLI output OpenGL
Hi all
Here follows a bug report about the Unigine Sanctuary benchmark which is unfortunately broken with OpenGL/WineD3D.
I have tested this recently with Wine 9.0-rc4 and it works stable only when Gallium Nine is used. At the CLI there is a "Failed to load libGL: libGL.so.1" information present. See the CLI output file for more details.
For me, the OGL path was always broken while the D3D10 mode had worked (with some flaws) at some point with Wine 8.x. The D3D11 renderer was not intensively tested because the corresponding D3D11 support was incomplete in earlier Wine / WineD3D releases.
And finally, there is an additional strange problem concerning the native "openal32.dll" file present which can lead to a hard system hang. This never occurred on Wine builds which had an in-built "openal32.dll" file. Will open a separate issue report about that.
This was tested under Kubuntu 22.04 LTS with Mesa 24.0-git2401110600.813b19-oibaf-j (git-813b193 2024-01-11 jammy-oibaf-ppa). The system is an old iMac 12,2 containing an Radeon HD 6770M GPU which is using the r600 Mesa driver.
Note, the Unigine Sanctuary benchmark can still be downloaded from the original website: https://benchmark.unigine.com/sanctuary
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #1 from C. Leu kle@bluewin.ch --- Created attachment 75863 --> https://bugs.winehq.org/attachment.cgi?id=75863 video mode error (OGL)
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #2 from C. Leu kle@bluewin.ch --- Created attachment 75864 --> https://bugs.winehq.org/attachment.cgi?id=75864 fatal error (OGL)
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #3 from C. Leu kle@bluewin.ch --- Created attachment 75865 --> https://bugs.winehq.org/attachment.cgi?id=75865 video mode error (D3D10)
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #4 from C. Leu kle@bluewin.ch --- Created attachment 75866 --> https://bugs.winehq.org/attachment.cgi?id=75866 fatal error (D3D10)
https://bugs.winehq.org/show_bug.cgi?id=56163
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
--- Comment #5 from Zeb Figura z.figura12@gmail.com --- You're missing GL drivers; please consult the forum or some other help channel for how to install them for your distribution.
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #6 from C. Leu kle@bluewin.ch --- Many thanks Zeb Figura for the fast hint.
Indeed I had to run "sudo apt install libgl1:i386" and after that the "Failed to load libGL: libGL.so.1" warning is gone.
It is now possible to launch Unigine Sanctuary also via OpenGL but the screen output is totally broken. There are a ton of GLSL warnings displayed and after that the output is just orange and orange-yellow.
This is the stage how it looked on earlier Wine versions when OpenGL was selected. As far as I remember it never worked with pure OpenGL. It worked to some degree via WineD3D and mostly fine on Nine.
See the new attachments for more details.
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #7 from C. Leu kle@bluewin.ch --- Created attachment 75875 --> https://bugs.winehq.org/attachment.cgi?id=75875 GLSL warnings (OGL)
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #8 from C. Leu kle@bluewin.ch --- Created attachment 75876 --> https://bugs.winehq.org/attachment.cgi?id=75876 yellow-orange screen (OGL)
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #9 from C. Leu kle@bluewin.ch --- Created attachment 75877 --> https://bugs.winehq.org/attachment.cgi?id=75877 Unigine Sanctuary CLI output D3D10
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #10 from C. Leu kle@bluewin.ch --- A new addition. The D3D10 path which uses WineD3D seems to be working again after the installation of the libGL.so dependency.
There are just some warnings present at the CLI like "d3d:state_linepattern_w Setting line patterns is not supported in OpenGL core contexts" and various "d3dcompiler:skip_u32_unknown Skipping 1 unknown u32s" ones. But overall the screen output looks correct.
Check the "Unigine Sanctuary CLI output D3D10.txt" file for more details.
https://bugs.winehq.org/show_bug.cgi?id=56163
C. Leu kle@bluewin.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |--- Status|RESOLVED |UNCONFIRMED
--- Comment #11 from C. Leu kle@bluewin.ch --- The OpenGL screen output is still totally broken even if the libGL.so dependency is installed.
https://bugs.winehq.org/show_bug.cgi?id=56163
C. Leu kle@bluewin.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Unigine Sanctuary is badly |Unigine Sanctuary is badly |broken with OGL/WineD3D |broken with OGL (works with |(only works with Gallium |Gallium Nine & WineD3D) |Nine) |
https://bugs.winehq.org/show_bug.cgi?id=56163
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Summary|Unigine Sanctuary is badly |Unigine Sanctuary renders |broken with OGL (works with |incorrectly with builtin GL |Gallium Nine & WineD3D) |renderer Resolution|--- |NOTOURBUG
--- Comment #12 from Zeb Figura z.figura12@gmail.com --- The failure to render correctly with GL is an application bug. Mesa has a workaround for it by default, but only the Linux version. Adding
force_glsl_extensions_warn="true" disable_arb_gpu_shader5="true" disable_blend_func_extended="true"
to the command line makes it render correctly.
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #13 from C. Leu kle@bluewin.ch --- Great thanks for the resolving of the issue Zeb Figura.
So this is in the end a bug in Unigine Sanctuary.
In that case this bug report can be closed. :-)
https://bugs.winehq.org/show_bug.cgi?id=56163
mirh mirh@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh@protonmail.ch
--- Comment #14 from mirh mirh@protonmail.ch --- I was almost going to ping the mesa guys to add this little default (should be just a matter of duplicating the native version with .exe added at the end of the name) when a big conundrum hit me: suppose I wanted to use wined3d to run one of the d3d versions, are GL_ARB_blend_func_extended and GL_ARB_gpu_shader5 used in the translation? Because the executable is the same for all the renderers, and it would be funny if fixing one hindered (or broke?) the others.
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #15 from Zeb Figura z.figura12@gmail.com --- (In reply to mirh from comment #14)
I was almost going to ping the mesa guys to add this little default (should be just a matter of duplicating the native version with .exe added at the end of the name) when a big conundrum hit me: suppose I wanted to use wined3d to run one of the d3d versions, are GL_ARB_blend_func_extended and GL_ARB_gpu_shader5 used in the translation? Because the executable is the same for all the renderers, and it would be funny if fixing one hindered (or broke?) the others.
It's not a bug in the implementation; it's a bug in how the application uses them. We don't use GL extensions incorrectly (and if we do that's a Wine bug to be fixed.)
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #16 from mirh mirh@protonmail.ch --- Yes, I understand that. I believe the first drirc hack was created _exactly_ to address this very bug (and there are some long explanations of it).
But if we extended the blacklist of those two extensions to also cover for Sanctuary.exe (and I guess tropics, and whatnot), couldn't you also be damaging wined3d when you are instead running the thing under directx?
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #17 from mirh mirh@protonmail.ch --- Ok, I just figured out this may be already happening in Heaven and Valley So I filled out https://gitlab.freedesktop.org/mesa/mesa/-/issues/10445
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #18 from Zeb Figura z.figura12@gmail.com --- (In reply to mirh from comment #16)
But if we extended the blacklist of those two extensions to also cover for Sanctuary.exe (and I guess tropics, and whatnot), couldn't you also be damaging wined3d when you are instead running the thing under directx?
Ah, yes, we would lose certain capabilities that way. I don't know whether they matter in this case, but it has definitely mattered in other cases. In one egregious case, Mesa added a workaround for an application's non-default renderer that broke its default renderer. Unfortunately I don't immediately know how to address this problem.
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #19 from mirh mirh@protonmail.ch --- I didn't know this had already happened "for real", and to actually critical results. If you could drop a short mention of that in my bug report.. ?
https://bugs.winehq.org/show_bug.cgi?id=56163
--- Comment #20 from Zeb Figura z.figura12@gmail.com --- (In reply to mirh from comment #19)
I didn't know this had already happened "for real", and to actually critical results. If you could drop a short mention of that in my bug report.. ?
Done; we'll see if anything comes of it.