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
Created attachment 53179 [details] font rendering broken for width > 8192
Created attachment 53180 [details] rendering completly broken for width > 16384
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.
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).
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.
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.
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>
Thanks, that fixes the crash. However, once the window > 16384px, I still get rendering error.
Created attachment 53240 [details] terminal rendering broken at about 4096px (could be 8192 too)
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?
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
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.
Blitter works fine with the super-size windows (urxvt ftw! ;-), just need to look more closely at the composite paths.
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.