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
Oh, forgot to mention, I am running: GPU: GTX 770 (GK104) Kernel: 4.1.3 Mesa: always latest git
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?
>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 ;]
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.
(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.
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>
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.
(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...
Diablo 3 seems to be hitting the exact same issue, BTW.
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.
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.
*** Bug 94650 has been marked as a duplicate of this bug. ***
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 =/
(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>
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. How we collect and use information is described in our Privacy Policy.