https://bugs.winehq.org/show_bug.cgi?id=43761
Bug ID: 43761 Summary: World of Warcraft d3d11 textures rendering regression and other... Wine Staging 2.17 Product: Wine-staging Version: 2.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: zefkerrigan@gmail.com CC: erich.e.hoover@wine-staging.com, michael@fds-team.de, sebastian@fds-team.de Distribution: ---
Created attachment 59257 --> https://bugs.winehq.org/attachment.cgi?id=59257 World of Warcraft d3d11 textures rendering regression. Wine Staging 2.17
Sorry, but I really do not have the opportunity to find out if this bug is in the development Wine branch, because World of Warcraft can only be launched in Wine Staging, but it can not be launched in a "vanilla" development Wine branch. So, I using only Wine Staging.
I could not get the output of the console, because, unfortunately, when I tried to run the game through the console, I did not manage to run the game until the stage of character management/movement. That is, the game hangs up every time the progress bar ends after clicking on the "Enter the World" button. But, I was surprised that the game is normally run through a shortcut on the dock bar, which also contains the same command in the line Exec=wine64 'c:/Program Files (x86)/World of Warcraft/Wow-64.exe' which I entered into the console (but, without "Exec=", of course).
When I used Wine Staging 2.16 I did not have any noticeable rendering bugs with the World of Warcraft in DirectX11 mode, or DirectX9. But, with Wine Staging 2.17 I began to see what's on the attached screenshot if WoW is running in DirectX11 mode. But, in DirectX9 mode this bug does not appear, and there are no any distortions in the graphics.
My specs: Arch Linux x86_64 with latest updates, GNOME. GPU Radeon HD7770 with latest Mesa. Wine Staging 2.17 with CSMT is on, x64 Wine prefix, 64bit WoW build.
https://bugs.winehq.org/show_bug.cgi?id=43761
zefkerr zefkerrigan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |ArchLinux Priority|P2 |P1 CC| |zefkerrigan@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=43761
--- Comment #1 from zefkerr zefkerrigan@gmail.com --- Created attachment 59258 --> https://bugs.winehq.org/attachment.cgi?id=59258 World of Warcraft with DX11 mode Wine Staging 2.16 or DirectX9 mode with any other version including Wine Staging 2.17.
https://bugs.winehq.org/show_bug.cgi?id=43761
--- Comment #2 from zefkerr zefkerrigan@gmail.com --- Created attachment 59259 --> https://bugs.winehq.org/attachment.cgi?id=59259 Some of console logs...
Some of console logs. I was able to get these logs by adding the line "Terminal = True" to the shortcut of the game. But, after the closing of the game, the terminal closed too. And while the logs continued to arrive, the terminal lagged heavily, so I could not even copy any text in it. Therefore, the only thing I could do was this screenshot.
https://bugs.winehq.org/show_bug.cgi?id=43761
--- Comment #3 from Michael Müller michael@fds-team.de --- In order to fix this issue, we will need the full debug log as text attachment. Please start WoW from a terminal as described in the following link (from the directory "$HOME/.wine/drive_c/Program Files (x86)/World of Warcraft") and attach the file log.txt
https://wiki.winehq.org/FAQ#How_can_I_get_a_debugging_log_.28a.k.a._terminal...
https://bugs.winehq.org/show_bug.cgi?id=43761
--- Comment #4 from zefkerr zefkerrigan@gmail.com --- Created attachment 59284 --> https://bugs.winehq.org/attachment.cgi?id=59284 At this point the game totally hung on the progress bar and I had to kill the process.
When I run the game in d3d11 mode from a terminal it normally starts up and works, but it instantly hangs completely, as soon as at least the edge of the broken textures appears on the screen. If you run the game through a shortcut, and not through the terminal, then the game does not hang when a broken textures appears on the screen. And if I left the game when there were broken textures within sight, then when I entered the game, I generally will not see the image in the game any further than the progress bar, because in this case the game hangs up every time when you enter the game world progress bar reaches 100%. I repeat, under the same conditions the game does not hang if it was launched via a shortcut. The game hangs only if it was launched via the terminal. Please note that not all textures are broken, but only some of their individual varieties. For example, if we draw an analogy, then after upgrading to Wine Staging 2.17 in Witcher 3, the textures of the surface of the ground, stones on the ground, paths, etc. appeared. But, at the same time, similar textures disappeared in WoW. I do not presume to say whether this can be related to the recent innovation or not: https://dev.wine-staging.com/patches/186/
https://bugs.winehq.org/show_bug.cgi?id=43761
--- Comment #5 from zefkerr zefkerrigan@gmail.com --- Created attachment 59285 --> https://bugs.winehq.org/attachment.cgi?id=59285 And after that I ran the game again under the same conditions.
https://bugs.winehq.org/show_bug.cgi?id=43761
--- Comment #6 from Michael Müller michael@fds-team.de --- Can you add your full glxinfo output as attachment? For me it seems like a driver bug. The interesting part from the log is:
fixme:d3d_shader:print_glsl_info_log Info log received from GLSL shader #241: fixme:d3d_shader:print_glsl_info_log error: definitions of interface block `shader_in_out' do not match
The reason for the difference is:
vertex shader: --------- out shader_in_out { vec4 reg0; vec4 reg1; vec4 reg2; vec4 reg3; [...] ---------
pixel shader: --------- in shader_in_out { vec4 reg0; centroid vec4 reg1; centroid vec4 reg2; centroid vec4 reg3; [...] ---------
This should be valid though according to the GLSL 4.4 spec: https://www.khronos.org/registry/OpenGL/specs/gl/GLSLangSpec.4.40.pdf
The statement on page 50 says: -------- For this interface, the last active shader stage output variables and fragment shader input variables of the same name must match in type and qualification, with a few exceptions: The storage qualifiers must, of course, differ (one is in and one is out). Also, interpolation qualification (e.g., flat) and auxiliary qualification (e.g. centroid) may differ. These mismatches are allowed between any pair of stages. When interpolation or auxiliary qualifiers do not match, those provided in the fragment shader supersede those provided in previous stages. ----
The excerpt explicitly states that the auxiliary qualifier centroid can differ. Unless you manually told Mesa to fake a GLSL version of 4.4 or newer, this is a bug in their driver. Try to update Mesa to a more recent version, otherwise you will need to report a bug in their bug tracker.
https://bugs.winehq.org/show_bug.cgi?id=43761
--- Comment #7 from zefkerr zefkerrigan@gmail.com --- Created attachment 59309 --> https://bugs.winehq.org/attachment.cgi?id=59309 glxinfo
https://bugs.winehq.org/show_bug.cgi?id=43761
--- Comment #8 from zefkerr zefkerrigan@gmail.com --- (In reply to Michael Müller from comment #6)
Can you add your full glxinfo output as attachment? For me it seems like a driver bug. The interesting part from the log is:
fixme:d3d_shader:print_glsl_info_log Info log received from GLSL shader #241: fixme:d3d_shader:print_glsl_info_log error: definitions of interface block `shader_in_out' do not match
The reason for the difference is:
vertex shader:
out shader_in_out { vec4 reg0; vec4 reg1; vec4 reg2; vec4 reg3; [...]
pixel shader:
in shader_in_out { vec4 reg0; centroid vec4 reg1; centroid vec4 reg2; centroid vec4 reg3; [...]
This should be valid though according to the GLSL 4.4 spec: https://www.khronos.org/registry/OpenGL/specs/gl/GLSLangSpec.4.40.pdf
The statement on page 50 says:
For this interface, the last active shader stage output variables and fragment shader input variables of the same name must match in type and qualification, with a few exceptions: The storage qualifiers must, of course, differ (one is in and one is out). Also, interpolation qualification (e.g., flat) and auxiliary qualification (e.g. centroid) may differ. These mismatches are allowed between any pair of stages. When interpolation or auxiliary qualifiers do not match, those provided in the fragment shader supersede those provided in previous stages.
The excerpt explicitly states that the auxiliary qualifier centroid can differ. Unless you manually told Mesa to fake a GLSL version of 4.4 or newer, this is a bug in their driver. Try to update Mesa to a more recent version, otherwise you will need to report a bug in their bug tracker.
Why is there no such problem on Wine Staging 2.16, but it appears if the only thing I do is update Wine Staging to version 2.17?
https://bugs.winehq.org/show_bug.cgi?id=43761
--- Comment #9 from Michael Müller michael@fds-team.de --- The feature for interpolation modifiers and auxiliary qualifiers was added in Wine Staging 2.17. In Wine Staging 2.16 those information in the hlsl shaders were simply ignored, leading to graphic glitches in some games.
Can you apply the following patch on top of Wine Staging https://dev.wine-staging.com/patches/199/ and check if it fixes the problem for you?
https://bugs.winehq.org/show_bug.cgi?id=43761
--- Comment #10 from zefkerr zefkerrigan@gmail.com --- (In reply to Michael Müller from comment #9)
The feature for interpolation modifiers and auxiliary qualifiers was added in Wine Staging 2.17. In Wine Staging 2.16 those information in the hlsl shaders were simply ignored, leading to graphic glitches in some games.
Can you apply the following patch on top of Wine Staging https://dev.wine-staging.com/patches/199/ and check if it fixes the problem for you?
Michael, Thank you very much! Your patch has solved my problem! WoW on d3d11 now again works well. All textures returned to their place.
https://bugs.winehq.org/show_bug.cgi?id=43761
--- Comment #11 from zefkerr zefkerrigan@gmail.com --- Created attachment 59368 --> https://bugs.winehq.org/attachment.cgi?id=59368 Here it is a modified PKGBUILD with an added fixing patch. That's how I compiled it.
To apply your patch, I took PKGBUILD from the official Arch Linux repository and only added a few lines to it to apply this patch.
https://bugs.winehq.org/show_bug.cgi?id=43761
--- Comment #12 from zefkerr zefkerrigan@gmail.com --- https://www.archlinux.org/packages/multilib/x86_64/wine-staging/
https://git.archlinux.org/svntogit/community.git/tree/trunk?h=packages/wine-...
https://bugs.winehq.org/show_bug.cgi?id=43761
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #13 from Michael Müller michael@fds-team.de --- Closing as FIXED. The workaround has been added in Wine Staging 2.18 although this seems more like a Mesa bug.
https://bugs.winehq.org/show_bug.cgi?id=43761
--- Comment #14 from zefkerr zefkerrigan@gmail.com --- (In reply to Michael Müller from comment #13)
Closing as FIXED. The workaround has been added in Wine Staging 2.18 although this seems more like a Mesa bug.
Michael, I want to write a bug report on Mesa's bugzilla about this Mesa bug, but I absolutely do not know what I should write in this bug report. So, help me please make a bug report on the Mesa's bugzilla so that after Mesa developers fix this bug in Mesa you could cancel this your workaround.
And I'm sorry for a completely different question. I was curious why the Wine Staging project recently began to look as if he had stopped developing? For some reason, you no longer accept new patches and no longer add new features. And in the news section on your site new announcements of new versions of Wine Staging have ceased to be added. This causes some concern for me and some of my friends.
Thank you!
https://bugs.winehq.org/show_bug.cgi?id=43761
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Closing Fixed Staging 3.14