Created attachment 107309 [details]
Twisted graphics with HD2000
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/
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:
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
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.
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 ;)
This bug affects all application using Qt5 QtQuick 2 applications build with MSVC run on i965.
The MSVC Qt5 SDK uses the ANGLE graphics layer, in contrary to the MinGW one, which uses Desktop OpenGL.
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.
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.
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 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.
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
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:
Author: Chris Forbes <email@example.com>
Date: Tue Nov 25 09:44:19 2014 +1300
i965/Gen6-7: Do not replace texcoords with point coord if not drawing points
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.
on Jan 16, 2017 at 17:17:37.
(provided by the Example extension).