Bug 84651

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.