Nouveau - Feb 2009 - [Bug 20023] New: nv20: unwanted solid fills during busyloop rendering

http://bugs.freedesktop.org/show_bug.cgi?id=20023

           Summary: nv20: unwanted solid fills during busyloop rendering
           Product: Mesa
           Version: CVS
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: ASSIGNED
          Severity: minor
          Priority: medium
         Component: Drivers/DRI/nouveau
        AssignedTo: pq at iki.fi
        ReportedBy: pq at iki.fi
                CC: nouveau at lists.freedesktop.org


Created an attachment (id=22728)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=22728)
screenshot of the corruption

This bug is mostly for myself as a devel to keep track of the issue.
It appears on both my nv20 and nv28. Current testing is on nv28.

Nouveau Gallium3D nv20 driver has recently got e.g. trivial/tri to work.
Trivial/tri-repeat is a version of trivial/tri, that cycles the colors and
renders as fast as possible (RAFAP). Another RAFAP application is glxgears,
which still shows only a black window.

When a RAFAP application is running, moving focus to a terminal window (aterm,
xterm) sometimes paints a rectangle filled with a solid color into the terminal
window. Examples of this are seen in the attached screenshot. The color of the
solid color fill (SCF) is not random: the aterm cursor is a yellow block, the
irc client has a blue status bar that updates occasionally, and gray is the
basic color in the terminal. I have no idea where the red comes from.

When SCF first appears, it is a single complete solid rectangle, properly
clipped by other windows, if they overlap. The holes seen in the screenshot are
due to the terminal repainting some of its contents. The SCF seems to respect
the terminal window borders, which does not make any sense. Sometimes the SCF
stops at the same x-coordinate as the tri-repeat window, for instance.

The composite extension is disabled in the X server, so the terminal windows
should not have a backing pixmap in VRAM. If they had, it would be easy to
hypothesise that NV20 Gallium is overwriting some VRAM with solid color, and
separate backing pixmaps would explain respecting the window borders and the
clipping to other windows.

The fact, that the SCF is a rectangle, suggests that whatever draws it, has the
"correct" pitch. Otherwise it would not have straight vertical edges.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20023





--- Comment #1 from Pekka Paalanen <pq at iki.fi>  2009-02-09 12:51:52 PST
---
Hypothesis: Gallium hw ctx and EXA hw ctx are leaking state, incomplete context
switching.

Test: disable all EXA acceleration.

NV04EXAPrepareSolid(), NV04EXAPrepareCopy(), NV10EXACheckComposite() were
modified to return FALSE immediately. Additionally UTS and DFS were disabled
via xorg.conf.

Result: no impact. The SCF appears as before.

Even though EXA should not be using hw acceleration, the DRM and EXA hw ctxs
still exist. However, it is unlikely for the SCF to be caused by state leaking
from a context to another.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20023





--- Comment #2 from Pekka Paalanen <pq at iki.fi>  2009-02-09 12:52:53 PST
---
Hypothesis: NV2X_GRCTX_SIZE too small, which leads to contexts corrupting each
other.

Doubled it, no change.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20023





--- Comment #3 from Pekka Paalanen <pq at iki.fi>  2009-02-09 13:16:01 PST
---
The SCF appears only, when a RAFAP application is running, and a terminal
window draws something. The "drawing something" is most easily
triggered in
aterm by switching the focus between a RAFAP window and the aterm window. Aterm
fills the text cursor with yellow when it receives focus, and this fill may
"blow up".

The SCF seems to be drawn directly onto the framebuffer, any rendering
whatsoever will fix it for the rendered area. Except fluxbox window borders
while moving windows (no window content shown while moving). Switching virtual
desktops is a good way to clear it. SCF seems to never touch the background or
the root window.

Having three trivial/tri-repeat applications running at the same time works
fine, and it seems that the SCF happens more frequently/easily.

Todo:
- confirm it's not happening with swrast
- try disabling all 2D rendering (fill, clear, copy) in NV20 Gallium one by one

Ideas:
- could nv2x_graph_context_init (DRM) be incorrect?
- buggy hw ctx switching? Hope not! But nvidia did use sw ctx switching for
some reason.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20023





--- Comment #4 from Pekka Paalanen <pq at iki.fi>  2009-02-09 13:44:09 PST
---
Yay for malc0!

http://lists.freedesktop.org/archives/xorg/2009-February/043604.html
The program in that email triggers the same SCF as trivial/tri-repeat.
Compile it with:
 gcc -W -Wall -O2 Xdamage.c -o Xdamage -lX11 -lXfixes -lXdamage

Trivial/tri-repeat with swrast does not trigger the SCF.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20023


Pekka Paalanen <pq at iki.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|minor                       |normal
          Component|Drivers/DRI/nouveau         |Server/general
            Product|Mesa                        |xorg
            Summary|nv20: unwanted solid fills  |XDamageAdd problem (with
                   |during busyloop rendering   |Gallium3D)
            Version|CVS                         |git




--- Comment #5 from Pekka Paalanen <pq at iki.fi>  2009-02-09 14:03:39 PST
---
Trying to move this bug to Xorg.

Added Hellstr?m to CC, since he made the minimal program that reproduces this
issue. Change the summary according to Thomas' email.

Correction: I'm not adding Hellstr?m to CC, since bugzilla does not allow
it.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20023


Pekka Paalanen <pq at iki.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|pq at iki.fi                   |xorg-team at lists.x.org
             Status|ASSIGNED                    |NEW
          QAContact|                            |xorg-team at lists.x.org




-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20023





--- Comment #6 from Michel D?nzer <michel at daenzer.net>  2009-02-10
09:16:13 PST ---
Bug 20037 could explain this, please try the fix referenced there.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20023





--- Comment #7 from Pekka Paalanen <pq at iki.fi>  2009-02-10 12:28:57 PST
---
I updated xorg-server from git master, and then also evdev and mesa from git
master. Thomas' test app no longer triggers the SCF.

When visuals get fixed and Mesa/OpenGL works again, I'll test with NV20
Gallium, and then close this bug as fixed.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.freedesktop.org/show_bug.cgi?id=20023


Pekka Paalanen <pq at iki.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #8 from Pekka Paalanen <pq at iki.fi>  2009-02-11 11:06:17 PST
---
Okay, the visuals got fixed, and the SCF problem is fixed, too, in xorg-server
master.

The damage accounting does not seem to fully work with partially occluded GL
windows. If I have the top left corner of trivial/tri-repeat occluded by
another window and then raise the GL window, fluxbox does not redraw the GL
window decorations. But this is a completely different matter.

Closing as fixed. This bug really worried me, since I thought NV20 hw context
switching might be broken. Phew.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.