Red Hat Bugzilla – Bug 666523
r600: unmapping 3D windows in wine causes FBO-related glyph/pixmap corruption
Last modified: 2012-08-16 14:26:21 EDT
Description of problem:
I'm running a x86_64 Fedora 14 system with a Radeon 3450 graphics card running with the r600 driver and GEM/DRI2.
If I unmap the window of certain OpenGL applications while the application is running, by minimizing it or switching to another workspace, I can often see pixmap and text glyph corruption all over the desktop, in addition to random texture corruption in the application itself. The text glyph corruption persists after the 3D application exits, and is only corrected if either the X server or all the X clients using the glyph get restarted (so that the XRender glyph gets uploaded again). It thus looks like video (and maybe GTT) memory corruption.
So far the corruption appears to be "blocky" rather than "noisy": a corruption text glyph usually becomes entirely invisible or entirely black, but can also occasionally become partially black.
The bug can only be triggered by certain OpenGL applications, mostly newer Touhou games running in wine. I have not been able to reproduce this problem using glxgears, stellarium or gzdoom.
Disabling sync-to-vblank with sync_to_vblank=0 does not help. While I'm currently using metacity, switching to compiz does not help either.
The system is otherwise perfectly stable, even if the offending 3D application is run for a long time without unmapping its window.
Version-Release number of selected component (if applicable):
Updating to the rawhide kernel makes no difference. Using a patched git-master version of Mesa allows more games to be run smoothly, but it too makes no difference with regard to this bug.
Most of the time; the corruption is random, but minimizing the window twenty times or so is usually enough for significant corruption.
Steps to Reproduce:
0. Start a firefox instance displaying http://www.infinality.net/files/font.html, which should make the subsequent corruption more visible.
1. Install an offending 3D application. "Uwabami Breakers" is a good choice since it works well enough with stock Mesa and Wine and is available for free at the official website (http://alcostg.amatukami.com/; http://mirror.studio-ramble.com/upload/578/200801/alcostg_web.zip is among the list of usable download mirrors). However, it is a Japanese game, so when installing and running it, LANG=ja_JP.UTF-8 should be set.
2. After installation, run the game in wine with e.g. "LANG=ja_JP.UTF-8 wine alcostg.exe". The bug can be reproduced with a clean WINEPREFIX.
3. When the game shows the main menu, minimize its window, display it again, and repeat 20-30 times. The game window usually becomes garbled and displays random textures after the first minimization, but the glyphs over the entire desktop also becomes increasingly corrupted in the manner described above.
Unmapping the window of a running 3D application have historically triggered many bugs for me. In Fedora 10 with the then-current Catalyst driver, this always locked up the system with a garbled screen. In Fedora 12, it used to crash the X server due to bug #550752, but there was no longer any problem (even the game window itself displays the correct contents) after this bug gets fixed. The current situation is thus a rather inconvenient regression.
I have looked into some of the relevant wine and DRI2 code, but could not find any clue. If I understand correctly, in a GEM system the kernel DRM module should be checking the command stream for validity and processing the relocations pointing to buffer objects, so I think such corruption is likely the DRM module's fault.
Created attachment 471275 [details]
My /var/log/dmesg. Triggering the bug does not give any extra output in dmesg or /var/log/Xorg.0.log.
Created attachment 471276 [details]
Xorg.0.log. Looks uninteresting.
Created attachment 471277 [details]
Detailed installation instructions:
1. Download alcostg_web.zip from the website above and decompress it into some directory under the Linux home directory.
2. Run "LANG=ja_JP.UTF-8 wine alcostg_setup.exe" in the appropriate directory to install the game. The installation path can be another directory under the Linux home directory (z:\home\user-name\XXX). Otherwise just click "Next" (the button labeled with N).
3. Run "LANG=ja_JP.UTF-8 wine alcostg.exe" in the appropriate directory. The button on the right starts the game in windowed mode.
After some investigation, it turns out that Wine treats an unmapped/minimized windows as one having 32x32 size, and wine's dlls/wined3d/swapchain.c:IWineD3DSwapChainImpl_Present() function then considers the window to have been resized and turns on render_to_fbo (not really necessary in this case). So the corruption of text glyphs all over the desktop is probably an FBO bug in Mesa or the kernel-side DRM driver; indeed, it also occurs when I attempt to use an enlarged window size (e.g. 960x720) in newer Touhou games, which presumably also uses FBO. Such FBO use did not cause any problem in Fedora 12.
The corruption of the game graphics after unmapping/minimization is an orthogonal issue: the stock Mesa supports GL_EXT_framebuffer_object but not GL_EXT_framebuffer_blit, but wine attempted to bind GL_DRAW_FRAMEBUFFER anyway. This can be fixed by enabling GL_EXT_framebuffer_blit in the Mesa r600 DRI driver, which had no other ill effect in Fedora 12. In Fedora 14, game graphics is no longer garbled after such a fix, but pixmap and text glyph corruption in the desktop remains.
For now a workaround is to set wine's OffscreenRenderingMode to backbuffer so that it avoids using FBOs, which could reduce performance in some cases and fail to implement some effects.
This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here: