Bug 666523

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):

kernel-2.6.35.10-74.fc14.x86_64
libdrm-2.4.22-1.fc14.x86_64
xorg-x11-drv-ati-6.13.1-0.3.20100705git37b348059.fc14.x86_64
xorg-x11-server-Xorg-1.9.3-3.fc14.x86_64
mesa-dri-drivers-7.9-5.fc14.x86_64
wine-1.3.9-1.fc14.i686

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.

How reproducible:

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.
  
Additional info:

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.