Bug 42619

Summary: rendering artifacts with super-large windows
Product: xorg Reporter: Clemens Eisserer <linuxhippy>
Component: Driver/intelAssignee: Chris Wilson <chris>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
font rendering broken for width > 8192
none
rendering completly broken for width > 16384
none
terminal rendering broken at about 4096px (could be 8192 too) none

Description Clemens Eisserer 2011-11-05 03:27:56 UTC
Don't know how important this is, it worked with UXA so I thought filing a bug report isn't a bad idea. I (and most others I guess) don't use such large windows.

When resizing windows to super-large dimensions, rendering artifacts occur.

Resizing XFCE's "Terminal" application there were two types of artifacts:
1.) Font rendering seems to struggle with windows > 8192px
2.) General distortion with windows > 16384px, can even crash the xserver

intel i945GM
intel-git
libdrm-2.4.27
pixman-0.23.8
linux-3.1.0
xorg 1.11.1
Comment 1 Clemens Eisserer 2011-11-05 03:28:58 UTC
Created attachment 53179 [details]
font rendering broken for width > 8192
Comment 2 Clemens Eisserer 2011-11-05 03:29:43 UTC
Created attachment 53180 [details]
rendering completly broken for width > 16384
Comment 3 Chris Wilson 2011-11-05 03:47:10 UTC
Hmm. Obviously I've used too small an integer somewhere. Can you attach the debug log for this as well?

sna uses two methods to handle large windows:

1. Like uxa, it copies out a small region for the operation and composites to the temporary before copying back.

2. If the operation is itself larger than the pipeline can support, the operation is split up into chunks. This is new for sna.

Last time I tested this is many, many months ago, and since then I've added more hardware paths that may have additional restrictions that I've missed.
Comment 4 Chris Wilson 2011-11-05 04:23:31 UTC
Actually I could also do with a reproduction recipe. At the moment, I'm being limited by screen geometry (exposures and double-buffered pixmaps being cropped).
Comment 5 Chris Wilson 2011-11-05 05:03:08 UTC
I caught an obviously stupid mistake that was causing unnecessary uncached readbacks, but I haven't yet seen anything like the corruption you had.

Let's start simple, update to get that fix and walk me through reproducing this. Thanks.
Comment 6 Clemens Eisserer 2011-11-05 08:09:38 UTC
Thanks, your patch fixes the font-corruption at width > 8192.

However, when I resize the Terminal window to more than 16384, I get the following crash:

Program received signal SIGSEGV, Segmentation fault.
__memcpy_ssse3 () at ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S:714
714             movdqu  %xmm0, (%esi)
(gdb) bt
#0  __memcpy_ssse3 () at ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S:714
#1  0x005c56a4 in memcpy_blt (src=0xb26b5800, dst=0xb0e9ae48,
bpp=<optimized out>, src_stride=65508, dst_stride=4, src_x=1225,
src_y=977, dst_x=1225,
   dst_y=977, width=65508, height=23) at blt.c:67
#2  0x005e522d in sna_copy_boxes (src=0xb63c0008, dst=0xa3523b0,
gc=0xa28ea28, box=0xa35f178, n=2, dx=-1225, dy=-977, reverse=0,
upsidedown=0,
   bitplane=0, closure=0x0) at sna_accel.c:2124
#3  0x081a9efb in miCopyRegion (pSrcDrawable=0xb63c0008,
pDstDrawable=0xa3523b0, pGC=0xa28ea28, pDstRegion=0xbfb46434,
dx=-1225, dy=-977,
   copyProc=0x5e4390 <sna_copy_boxes>, bitPlane=0, closure=0x0) at micopy.c:137
#4  0x081aa3e0 in miDoCopy (pSrcDrawable=0xb63c0008,
pDstDrawable=0xa3523b0, pGC=0xa28ea28, xIn=0, yIn=0, widthSrc=16377,
heightSrc=68, xOut=1225,
   yOut=977, copyProc=0x5e4390 <sna_copy_boxes>, bitPlane=0,
closure=0x0) at micopy.c:334
#5  0x005dcdae in sna_copy_area (src=0xb63c0008, dst=0xa3523b0,
gc=0xa28ea28, src_x=0, src_y=0, width=16377, height=68, dst_x=0,
dst_y=0)
   at sna_accel.c:2206
#6  0x081597b7 in damageCopyArea (pSrc=0xb63c0008, pDst=0xa3523b0,
pGC=0xa28ea28, srcx=0, srcy=0, width=16377, height=68, dstx=0, dsty=0)
   at damage.c:864
#7  0x08071c16 in ProcCopyArea (client=0xa2e7fb8) at dispatch.c:1645
#8  0x0807609f in Dispatch () at dispatch.c:432
#9  0x0806431a in main (argc=6, argv=0xbfb46704, envp=0xbfb46720) at main.c:287
(gdb)
#0  __memcpy_ssse3 () at ../sysdeps/i386/i686/multiarch/memcpy-ssse3.S:714
#1  0x005c56a4 in memcpy_blt (src=0xb26b5800, dst=0xb0e9ae48,
bpp=<optimized out>, src_stride=65508, dst_stride=4, src_x=1225,
src_y=977, dst_x=1225,
   dst_y=977, width=65508, height=23) at blt.c:67
#2  0x005e522d in sna_copy_boxes (src=0xb63c0008, dst=0xa3523b0,
gc=0xa28ea28, box=0xa35f178, n=2, dx=-1225, dy=-977, reverse=0,
upsidedown=0,
   bitplane=0, closure=0x0) at sna_accel.c:2124
#3  0x081a9efb in miCopyRegion (pSrcDrawable=0xb63c0008,
pDstDrawable=0xa3523b0, pGC=0xa28ea28, pDstRegion=0xbfb46434,
dx=-1225, dy=-977,
   copyProc=0x5e4390 <sna_copy_boxes>, bitPlane=0, closure=0x0) at micopy.c:137
#4  0x081aa3e0 in miDoCopy (pSrcDrawable=0xb63c0008,
pDstDrawable=0xa3523b0, pGC=0xa28ea28, xIn=0, yIn=0, widthSrc=16377,
heightSrc=68, xOut=1225,
   yOut=977, copyProc=0x5e4390 <sna_copy_boxes>, bitPlane=0,
closure=0x0) at micopy.c:334
#5  0x005dcdae in sna_copy_area (src=0xb63c0008, dst=0xa3523b0,
gc=0xa28ea28, src_x=0, src_y=0, width=16377, height=68, dst_x=0,
dst_y=0)
   at sna_accel.c:2206
#6  0x081597b7 in damageCopyArea (pSrc=0xb63c0008, pDst=0xa3523b0,
pGC=0xa28ea28, srcx=0, srcy=0, width=16377, height=68, dstx=0, dsty=0)
   at damage.c:864
#7  0x08071c16 in ProcCopyArea (client=0xa2e7fb8) at dispatch.c:1645
#8  0x0807609f in Dispatch () at dispatch.c:432
#9  0x0806431a in main (argc=6, argv=0xbfb46704, envp=0xbfb46720) at main.c:287
(gdb) Program received signal SIGSEGV, Segmentation fault.
Comment 7 Chris Wilson 2011-11-05 12:45:59 UTC
This should take care of this crash. Probably a few more 16k stride assumptions lurking around though.

commit e2165f0e6b0620e3d788546924a2174506fbbde5
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Nov 5 19:46:13 2011 +0000

    sna: For a 32k max window size, we need to handle up to 128k strides
    
    Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42619
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Comment 8 Clemens Eisserer 2011-11-07 02:49:40 UTC
Thanks, that fixes the crash.
However, once the window > 16384px, I still get rendering error.
Comment 9 Clemens Eisserer 2011-11-07 02:50:42 UTC
Created attachment 53240 [details]
terminal rendering broken at about 4096px (could be 8192 too)
Comment 10 Chris Wilson 2011-11-07 03:12:26 UTC
I'm trying to reproduce this using xfce4 and xfce4-terminal --geometry 4096x128 which should give a wide enough terminal. However, the WM is capping the new window at screen size which is frustrating.

How have you configured your WM and most importantly are using a (GL) compositor?
Comment 11 Clemens Eisserer 2011-11-07 03:15:16 UTC
I was manually resizing the window, no special WM configuration.

I was not using a compositor, as with current mesa-7.12 git I get a hard system lockup as soon as a GL window exceeeds 2048px: https://bugs.freedesktop.org/show_bug.cgi?id=42605
Comment 12 Clemens Eisserer 2011-11-07 03:16:29 UTC
btw I see the corruptions starting at x=4096 ony when the window itself is >16834, when the window is <16384, the whole window is rendered fine.
Comment 13 Chris Wilson 2011-11-07 03:43:26 UTC
Blitter works fine with the super-size windows (urxvt ftw! ;-), just need to look more closely at the composite paths.
Comment 14 Chris Wilson 2011-11-07 12:11:18 UTC
That was a few hours of poking before I gave in and actually read the source looking for likely suspects. At least I found and fixed a few other bugs in the process...

commit 65a440543b13e3e605a4a2d6209a460fbbe55736
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Nov 7 20:00:20 2011 +0000

    sna: Fix 16-bit overflow of rowlength for memcpy
    
    Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42619
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

I think it is working now (at least the 31x31 xfce4-terminal was ;)

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.