Bug 84651 - Distorted graphics or black window when running Battle.net app on Intel hardware via wine
Summary: Distorted graphics or black window when running Battle.net app on Intel hardw...
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2014-10-04 06:02 UTC by Xinkai Chen
Modified: 2015-03-14 19:39 UTC (History)
10 users (show)

See Also:
i915 platform:
i915 features:

Twisted graphics with HD2000 (963.25 KB, image/png)
2014-10-04 06:02 UTC, Xinkai Chen
apitrace log on i965 (5.67 KB, text/plain)
2014-11-12 10:02 UTC, Lubosz Sarnecki
apitrace log on nouveau (4.24 KB, text/plain)
2014-11-12 10:03 UTC, Lubosz Sarnecki
Trimmed trace (379.69 KB, application/octet-stream)
2014-11-19 15:53 UTC, Lubosz Sarnecki

Description Xinkai Chen 2014-10-04 06:02:48 UTC
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/

With regards,
Comment 1 Chris Wilson 2014-10-04 06:57:32 UTC
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.
Comment 2 Xinkai Chen 2014-10-04 09:46:00 UTC
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.
Comment 3 Chris Wilson 2014-10-04 09:56:23 UTC
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.
Comment 4 mathieu 2014-10-24 16:28:30 UTC
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
Comment 5 Xinkai Chen 2014-10-24 17:24:06 UTC
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.
Comment 6 Lubosz Sarnecki 2014-10-25 00:38:35 UTC
Apitrace to reproduce:

Using LIBGL_ALWAYS_SOFTWARE=1 displays the texture correctly. With hardware rendering the texture is apparently uploaded but not displayed correctly.
Comment 7 Lubosz Sarnecki 2014-10-25 00:56:42 UTC
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
Comment 8 Lubosz Sarnecki 2014-10-25 10:40:16 UTC
The trace can be played back on nouveau correctly.
Comment 9 Lubosz Sarnecki 2014-10-29 12:05:40 UTC
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)
Comment 10 Lubosz Sarnecki 2014-11-05 19:25:08 UTC
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 ;)

Comment 11 Lubosz Sarnecki 2014-11-10 13:18:28 UTC
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.

Comment 12 Lubosz Sarnecki 2014-11-12 10:01:50 UTC
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.
Comment 13 Lubosz Sarnecki 2014-11-12 10:02:44 UTC
Created attachment 109329 [details]
apitrace log on i965
Comment 14 Lubosz Sarnecki 2014-11-12 10:03:09 UTC
Created attachment 109330 [details]
apitrace log on nouveau
Comment 15 Lubosz Sarnecki 2014-11-19 15:53:35 UTC
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.
Comment 16 Ilia Mirkin 2014-11-20 17:15:18 UTC

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

I guess the fan is a bit uncommon, perhaps that's not working well in conjunction with the tex coords?
Comment 17 Chris Forbes 2014-11-25 04:09:20 UTC
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.
Comment 18 Chris Forbes 2014-11-25 10:04:48 UTC
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
Comment 19 Xinkai Chen 2014-11-25 11:05:52 UTC
Confirm: Installing the master version of lib32-mesa and lib32-mesa-dri solved the problem on my Arch machine.

SNB HD2000 here.
Comment 20 Lubosz Sarnecki 2014-11-25 15:58:23 UTC
I can also confirm that it's fixed.
Comment 21 Sven 2014-12-06 21:27:56 UTC
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.