Bug 71198

Summary: [SNA] G33/31 partial window redraw/update(?) regression
Product: xorg Reporter: Matti Hämäläinen <ccr>
Component: Driver/intelAssignee: Chris Wilson <chris>
Status: RESOLVED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: linuxhippy
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
i915 platform: i915 features:
Description Flags
Screenshot demonstrating the issue
Xorg.log with --enable-debug=full while reproducing the problem
Use MOVE_READ when promoting partial move_area to full move_to_gpu none

Description Matti Hämäläinen 2013-11-03 21:21:06 UTC
Created attachment 88580 [details]
Screenshot demonstrating the issue

An apparent redrawing/update issue / regression appeared as I updated to latest git the intel ddx: When opening a terminal window (urxvt 9.18), parts of the window sometimes fail to draw or update properly. This is especially apparent when switching to another virtual desktop and then back again to the one with the terminal window, the upper half of the window fails to draw.

Sometimes other parts may fail as well. I have not noticed this problem with any other applications, however.

Git-bisected to commit 638d4f60285709b6efc04cef72d4b530460e3239
sna: Remove the move-to-gpu shortcircuiting for partial GPU, no CPU damage

-- Window manager: WindowMaker 0.95.4
-- chipset: 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31
Express Integrated Graphics Controller (rev 10)
-- system architecture: i686 / 32bit
-- xf86-video-intel: GIT 4a7217b05c232484a80abc7bd67494996dd32057
-- xserver: X.Org X Server 1.14.3-4 from latest Debian testing
-- mesa: 9.2.2-1 from Debian testing
-- libpixman: 0.30.2-1
-- libdrm version: 2.4.46-3
-- kernel version: 3.11.6 (vanilla+grsec)
-- Linux distribution: current Debian Testing
-- Machine or mobo model: Asus P5KPL-CM
-- Display connector: VGA
Comment 1 Chris Wilson 2013-11-04 10:04:33 UTC
Does it require anything in particular on workspace 2 (or a particular webpage)? I've set my machine up roughly identically to yours (other than a different kernel and probably completely different font configuration for urxvt etc) and I'm just wondering if there is anything else I can do to make this more likely to happen... (Hmm, actually not using userptr is one...)
Comment 2 Chris Wilson 2013-11-04 10:20:26 UTC
For the record, disabling userptr alone is not enough to make my system trivially misbehave. Any suggestions welcome!
Comment 3 Matti Hämäläinen 2013-11-04 20:45:17 UTC
Nothing new to suggest, issue still present in GIT head (587c4866652e40e1e228b333028114766a6d3b08), reverting 638d4f60285709b6efc04cef72d4b530460e3239 fixes it (at least seemingly).

Steps I've used to reproduce are:

1) startx
2) On initial WindowMaker workspace (#1), open urxvt terminal
3) Switch to workspace #2 (I use alt+2, not sure if that is the default binding) then back to workspace #1 (alt+1)
4) Upper half of the terminal should now be empty (typically the shell prompt not visible, if no other application run in the terminal.)

--- optional ---

5) "ls -l" or something to produce output, this should look a bit wonky as only the lower half of the terminal will draw the damaged areas correctly.
6) Hitting enter several times after 5) should demonstrate weirdly updating damaged areas.

Oh, and this is on x86-32bit, of course, seems I've forgotten to mention that - sorry. :(
Comment 4 Matti Hämäläinen 2013-11-05 07:55:38 UTC
Created attachment 88668 [details]
Xorg.log with --enable-debug=full while reproducing the problem

No idea if this is of any use, but attached Xorg.log with --enable-debug=full where reproducing the issue as described in the previous comment.

Compressed with xz due to the large size.
Comment 5 Chris Wilson 2013-11-05 21:15:15 UTC
3.10 kernel? Did that actually get all the GEM fixes? Can you check with a 3.12?
Comment 6 Chris Wilson 2013-11-05 21:15:54 UTC
Or maybe I was just reading the wrong log. Ignore me...
Comment 7 Chris Wilson 2013-11-05 21:33:10 UTC
Created attachment 88731 [details] [review]
Use MOVE_READ when promoting partial move_area to full move_to_gpu

Spotted this in the trace - certainly a bug, but is it the bug?
Comment 8 Matti Hämäläinen 2013-11-06 05:53:18 UTC
Lo, and behold! It was :) Tried git head this morning - bug still there. Applied the patch - and it works. Thanks!
Comment 9 Chris Wilson 2013-11-06 09:01:56 UTC

commit 736b496b458d666416ea94f157c05ce78f98a600
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Nov 5 21:33:18 2013 +0000

    sna: Mark partial move_area_to_gpu with MOVE_READ on promotion to move_to_gpu
    When promoting a partial move_area_to_gpu to a full move_to_gpu, we have
    to disable certain optimisations that we try to use if MOVE_READ==0.
    Reported-and-tested-by: Matti Hamalainen <ccr@tnsp.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71198
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

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.