Created attachment 107309 [details] Twisted graphics with HD2000 Hello, Recently updated Battle.net App no longer works under wine. On my machine (SNB HD2000 + Arch + Mesa 10.3 + xf86-video-intel 2.99.916-3 + xorg-server 1.16.1-1), the graphics of the Battle.net app is twisted. (See attachment) Another person using Haswell HD 4600 hardware also experiences similar issues, except they seeing a black area instead of a twisted image. People also find switching to a different non-Intel card solves the problem. Original Wine bug: https://bugs.winehq.org/show_bug.cgi?id=37347 Battle.net app: https://us.battle.net/account/download/ With regards, Xinkai
My guess is mesa, but with so many packages updated it could be any of them. So could you downgrade each one and see which it is.
Sorry, I forgot to mention. In the original bug report, there're people with Wine 1.6.2 and mesa 10.1.5 who have this issue as well. Which means this is unlikely to be a regression, so no need to downgrade the graphics stack to see which one it is. Right? I can try changing the graphics settings to see if it helps, if you can tell me which settings I can tweak with.
It's still worth a shot though. If say mesa-9.0 or mesa-10.0 works, that will definitely help bisect and pinpoint either the feature or bug that breaks Battle.net. Otherwise, it may just be a bug between mesa and wine. Though, I would suggest you try a couple of old kernels, or old ddx, just to rule out breakage elsewhere.
I also had this problem but it did not occurs after a video driver related package, it happened after a Battle.net update (at the beginning of october) here are some information of the package I have installed on my gentoo: x11-drivers/xf86-video-intel-2.21.15 : 10:53:15 PM 02 sept 2014 media-libs/mesa-10.0.4 : 12:27:45 AM 07 feb 2014 x11-base/xorg-server-1.14.3-r2 : 11:25:30 AM 12 jan 2013 app-emulation/wine-1.7.28 : 02:45:20 PM 10 oct 2014 (I did try to downgrade wine but it did not changed anything) unfortunately downgrading Battle.net is not an option also, the comment in the wine bugtracker ( https://bugs.winehq.org/show_bug.cgi?id=37347#c17 ) does fix the distorted graphics : LIBGL_ALWAYS_SOFTWARE=1 wine ./.wine/drive_c/Program\ Files\ \(x86\)/Battle.net/Battle.net\ Launcher.exe but then performance are obviously very bad Integrated Graphics Chipset: Intel(R) HD Graphics 3000
Battle.net got an update from Qt4 to Qt5, which happened on Oct 1st-ish. It must be the cause. I didn't manage to downgrade individual packages to pin point the problem, since the Arch's GCC became too new to compile those older things. Also, it's worth to mention that somebody finds out that LIBGL_ALWAYS_SOFTWARE=1 wine ~/.wine/drive_c/Program\ Files\ \(x86\)/Battle.net/Battle.net\ Launcher.exe -- works around the problem.
Apitrace to reproduce: https://drive.google.com/file/d/0B0bLtNyAhxgodVI3N01vSW84SEU/view?usp=sharing Using LIBGL_ALWAYS_SOFTWARE=1 displays the texture correctly. With hardware rendering the texture is apparently uploaded but not displayed correctly.
I get a black window using Haswell-ULT / i915 mesa 10.3.1 linux 3.17.1 xorg-server 1.16.1 xf86-video-intel 2.99.916
The trace can be played back on nouveau correctly.
This post on Battle.net claims that copying DLLs Blizzard did not package fixes the issue for him on radeon. http://us.battle.net/en/forum/topic/14728822920?page=2#22 I could not reproduce the fix. He also notes that Qt5 introduces another layer of compatibility. So the graphics code is converted this way: OpenGL ES (Qt5) => D3D (wine) => OpenGL (mesa)
Tried mesa 9.0 and 9.2.5. Instead of a black screen, I get a white screen. The apitrace is still black. This issue is not a regression in mesa. The bounty for this bug is currently $10 ;) https://www.bountysource.com/issues/5642959-distorted-graphics-or-black-window-when-running-battle-net-app-on-intel-hardware-via-wine
This bug affects all application using Qt5 QtQuick 2 applications build with MSVC run on i965. http://en.wikipedia.org/wiki/Qt_Quick The MSVC Qt5 SDK uses the ANGLE graphics layer, in contrary to the MinGW one, which uses Desktop OpenGL. https://code.google.com/p/angleproject/ Since native Qt5 Linux applications do not use ANGLE, only applications using wine are affected. I have uploaded precompiled versions of the QtQuick clock example, one using MinGW, the other one MSVC. https://drive.google.com/folderview?id=0B0bLtNyAhxgod2RGeXpmbVB0ejg&usp=sharing The bug only occurs for the MSVC/ANGLE version. I also uploaded apitraces of the native Linux version and wine with MSVC and MinGW. All traces can be played back on nouveau and swrast (e.g. LIBGL_ALWAYS_SOFTWARE=1). The MSVC/ANGLE traces cannot be played back on i965. All software versions on both systems are identical. Traces using MSVC/ANGLE recorded on nouveau also cannot be played back on i965. Analyzing the MSVC/ANGLE trace with qapitrace on i965 shows that the texture is uploaded correctly, but apparently not displayed correctly. http://imgur.com/N5Yipyf
After analyzing the traces with "apitrace replay" on novueau and i965, I noticed slight differences in the log. i965 reports following errors that nouveau does not: Medium severity API performance issue 1, falling back to plain clear because buffers are untiled Could the clear function be a problem? Medium severity API other issue 2, FBO incomplete: Unsupported HW texture/renderbuffer format attached: MESA_FORMAT_L_SRGB8 Medium severity API other issue 2, FBO incomplete: Unsupported HW texture/renderbuffer format attached: MESA_FORMAT_L_UNORM16 Medium severity API other issue 2, FBO incomplete: Unsupported HW texture/renderbuffer format attached: MESA_FORMAT_L8A8_SRGB Medium severity API other issue 2, FBO incomplete: Unsupported HW texture/renderbuffer format attached: MESA_FORMAT_L8A8_UNORM Medium severity API other issue 2, FBO incomplete: Unsupported HW texture/renderbuffer format attached: MESA_FORMAT_RGBX_UNORM16 Are these texture formats implemented in gallium and swrast, but not i965? Maybe these warnings are just thrown because i965 debug is just more verbose. I attach the logs anyway.
Created attachment 109329 [details] apitrace log on i965
Created attachment 109330 [details] apitrace log on nouveau
Created attachment 109738 [details] Trimmed trace Trimmed apitrace, ending in a frame displaying the texture correctly on softpipe and nouveau. Not on i965. The bounty on this bug increased to $45 btw.
Observations: On my gen6 i965 (SNB), I see that the final draw in the trimmed trace is "messed up". In qapitrace I can see that the source texture is fine, which means that it's that final draw that's wrong. While there are a ton of fb incomplete/etc warnings, they don't seem to be related to the issue. Looking at the command sequence between the two draws, there's nothing particularly crazy. It uses texcoord's, and does something like enable GL_TEXTURE0 glTexCoordPointer enable GL_TEXTURE_COORD_ARRAY glDrawArrays(GL_TRIANGLE_FAN) I guess the fan is a bit uncommon, perhaps that's not working well in conjunction with the tex coords?
http://patchwork.freedesktop.org/patch/37469/ provides a partial fix (texture coordinates are no longer mangled when point sprite state is enabled, but drawing non-points), but some other things are still broken.
A proper fix for this is now in master: commit 0008d0e59eff365079323918508ffc87355a6bfd Author: Chris Forbes <chrisf@ijw.co.nz> Date: Tue Nov 25 09:44:19 2014 +1300 i965/Gen6-7: Do not replace texcoords with point coord if not drawing points Please test! -- Chris
Confirm: Installing the master version of lib32-mesa and lib32-mesa-dri solved the problem on my Arch machine. SNB HD2000 here.
I can also confirm that it's fixed.
Installing mesa 10.4.0-rc4 fixed the issue for me too.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.