Bug 91526 - World of Warcraft (on Wine) has UI corruption with nouveau
Summary: World of Warcraft (on Wine) has UI corruption with nouveau
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/nouveau (show other bugs)
Version: git
Hardware: Other Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Nouveau Project
URL:
Whiteboard:
Keywords:
: 94650 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-08-01 19:27 UTC by Gediminas Jakutis
Modified: 2016-03-28 12:41 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
example of UI corruption (2.25 MB, image/png)
2015-08-01 19:27 UTC, Gediminas Jakutis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gediminas Jakutis 2015-08-01 19:27:28 UTC
Created attachment 117482 [details]
example of UI corruption

When I run World of Warcraft under Wine with Nouveau, the game has UI corruption ranging from very mild (e.g. bits of text garbled here and there) to severe (complete lack of UI whatsoever).
I recorded an apitrace trace[2] and when replaying on Nouveau, the corruptions still do happen, complete with variations[1]. The same trace replayed on LLVM (i.e. with LIBGL_ALWAYS_SOFTWARE=1) results with the UI being rendered 100% fine.
Running on the binary blob also does result in the UI being rendered 100% fine.

I tested with two WoW versions: the [at the time of writing] latest 6.20 and an old 3.3.5a client – both have the same kind of corruptions.

Do note that in some cases, the initial game "login screen" appears to look perfectly fine; until one tries to e.g. enter one's login credentials or open the settings menu. So in order to tell if there are corruptions or not, simply launching the game might not be enough.

[1] the corruptions seem to be consistent between runs (on both actual game and trace replay) as long as I don't change anything window-wise. e.g. opening a some program or moving some random window around results in different corruptions each time while not touching anything and just re-starting the game (or replay) results in very consistent corruptions.
I also noticed that when it comes to typed-in text (e.g. field to enter the account name), the typed in letters seem to most of the time contain bits from other portions of the screen outside of game's window.

[2] https://seriouss.am/wow-nouveau-2015-08-01T2052.trace.xz filesize: 20.4MiB
Comment 1 Gediminas Jakutis 2015-08-01 19:30:37 UTC
Oh, forgot to mention, I am running:
GPU: GTX 770 (GK104)
Kernel: 4.1.3
Mesa: always latest git
Comment 2 Ilia Mirkin 2015-08-01 19:58:18 UTC
Reproduced on a fermi (GF108), although instead of corruption I just get that whole render as black (i.e. your corrupted regions are just all black). Disabling optimizations does not seem to have any effect.

Note that there is an outstanding wine bug (https://bugs.winehq.org/show_bug.cgi?id=38869) where it uses uninitialized values which could cause something like this... I had a patch somewhere that worked around it (initializing values to 0,0,0,1) at https://bugs.freedesktop.org/attachment.cgi?id=116966 .

Interesting, I applied the patch and it changed the output, so I suspected it was related. However then futzing it caused no change, and going back to the unpatched version still produced the changed thing. Not sure what to make of it. I wouldn't rule an issue with wine out.

Out of curiousity, does this happen with st/nine?
Comment 3 Gediminas Jakutis 2015-08-01 20:55:33 UTC
>Out of curiousity, does this happen with st/nine?

Hard to tell – with GalliumNine I get a whole different set of highly varying and inconsistent issues – from trivial negligible ones to it's-nigh-unplayable ones. All those while never noticing any of these UI problems at all. So it's hard to tell if the issues are related.

>I had a patch somewhere that worked around it (initializing values to 0,0,0,1) at https://bugs.freedesktop.org/attachment.cgi?id=116966

I see no difference in behaviour with this patch whatsoever. Neither "normally" nor with GalliumNine.

P.S. As a side-note, the most interestingly looking issue I encountered with GalliumNine was when one of the xyz coordinates on *some* objects very obviously appeared to be clamped to 0 ;]
Comment 4 Gediminas Jakutis 2015-08-01 20:59:17 UTC
Another note: I did play the game some with these UI issues present and I did not notice any other kind of rendering problems whatsoever. It appears to affect only the UI and text and absolutely nothing else.
Comment 5 Ilia Mirkin 2015-09-09 22:33:54 UTC
(In reply to Gediminas Jakutis from comment #4)
> Another note: I did play the game some with these UI issues present and I
> did not notice any other kind of rendering problems whatsoever. It appears
> to affect only the UI and text and absolutely nothing else.

I tracked down these issues to *something* to do with BGRA4 transfers. Commenting out the two BGRA4 formats in nv50_format.c "fixes" it for me. However no RGBA4-related tests appear to fail, teximage-colors is all happy, etc. So there's something more subtle may be going on.

Since this isn't show-stopping for the game, I think I'll keep looking into this without pushing out any shotgun fixes.

Should also double-check on a tesla to see if perhaps fermi+ have shed support for that format. But my guess is something in the blitter.
Comment 6 Ilia Mirkin 2015-09-10 01:58:46 UTC
Actually I ended up just pushing something that removes it on Fermi and newer. I tried to get the blob to use that format, but couldn't. This leads me to believe that for whatever reason it is no longer supported. Or... something. I double-checked that it still works on tesla though.

commit 342e68dc60eebb20ac1be9f47800ee9e604354f0
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Wed Sep 9 21:50:03 2015 -0400

    nvc0: remove BGRA4 format support
    
    Something is wrong with the support somewhere. I couldn't get the blob
    driver to use it either, although it happily used RGB5_A1.
    teximage-colors works, but WoW seems to fail in the menus for drawing
    text.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91526
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>
Comment 7 Gediminas Jakutis 2016-01-30 15:50:12 UTC
This is still an issue[1], so I suppose it should be re-opened.
I assume commit d68226087cf5f2f686d6c8f3377c5a1dec3d8bc4 might be at fault, but I haven't tested the game around that time, so I can't tell. I can bisect, if needed.

[1] I just re-tested with the current mesa git head on a fully patched WoW client and the problem is there.
Comment 8 Ilia Mirkin 2016-01-30 17:31:09 UTC
(In reply to Gediminas Jakutis from comment #7)
> This is still an issue[1], so I suppose it should be re-opened.
> I assume commit d68226087cf5f2f686d6c8f3377c5a1dec3d8bc4 might be at fault,
> but I haven't tested the game around that time, so I can't tell. I can
> bisect, if needed.
> 
> [1] I just re-tested with the current mesa git head on a fully patched WoW
> client and the problem is there.

Argh! You're right :( Just retested with latest mesa and the trace you originally supplied didn't work. But I *swear* it worked for me at commit d68226087c. Maybe it was through luck? Or perhaps something in st/mesa changed and it's taking a different path now...
Comment 9 Gediminas Jakutis 2016-02-04 17:09:17 UTC
Diablo 3 seems to be hitting the exact same issue, BTW.
Comment 10 blue-t 2016-03-25 07:31:27 UTC
http://workupload.com/file/rmdaFRu0 in 6.2.4 also has that corruption.
I tried with both wine 1.7.55 and 1.9.6-staging.
It starts with small missing pieces and gets worse if you maximize the game window.
Comment 11 Ilia Mirkin 2016-03-25 23:36:14 UTC
FTR, in the trace, things go wrong between call 722316 and 722358. In the middle, a SRGB8_ALPHA8 texture is created, and receives an upload from GL_BGRA + 4_4_4_4_REV data. According to qapitrace, that data is not properly reflected in the texture.

Running this with llvmpipe, the first glTexSubImage2D clears the data (all 0's) while the second glTexSubImage2D uploads the font. Since the font texture contains garbage, so does the remaining rendering. Need to figure out why the texture upload fails with the data in question.
Comment 12 Karol Herbst 2016-03-25 23:41:07 UTC
*** Bug 94650 has been marked as a duplicate of this bug. ***
Comment 13 Ilia Mirkin 2016-03-27 02:37:57 UTC
As I had originally suspected, this has nothing to actually do with BGRA4 format. It was just an odd place in the command stream.

The following patch should fix it: https://patchwork.freedesktop.org/patch/78448/

Please test. I think this has been broken since mesa 10.2 or so =/
Comment 14 Karol Herbst 2016-03-28 12:28:50 UTC
(In reply to Ilia Mirkin from comment #13)
> As I had originally suspected, this has nothing to actually do with BGRA4
> format. It was just an odd place in the command stream.
> 
> The following patch should fix it:
> https://patchwork.freedesktop.org/patch/78448/
> 
> Please test. I think this has been broken since mesa 10.2 or so =/

works great, thanks :)

Tested-by: Karol Herbst <nouveau at karolherbst.de>
Comment 15 Ilia Mirkin 2016-03-28 12:41:16 UTC
Pushed to master:

commit 41100b6b44e747b9003937f123fce571fd3dec46
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Sat Mar 26 22:32:43 2016 -0400

    nvc0: disable primitive restart and index bias during blits


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.