In zaphod mode (i.e. two screens) when running Xnest I get rendering corruptions when I i.e. move a xfce-terminal window over another xfce-terminal window. The problem becomes even more obvious when having the Xnest window spanning across the two screens and then moving windows within the Xnest session across screen borders. The contents of the moving window is rarely rendered at all. Since this issue mainly happens within Xnest, I guess it has to do with area copying of child of child of child windows or so. Xnest works fine when not having the zaphod mode active meaning only one physical X screen configured even if it spans two outputs.
FORCE_FALLBACK set to one in sna_accel.c fixes the rendering corruption when moving one xfce-terminal over another. But it has no influence on the rendering issue when crossing screen borders. So this might be a different thing.
The xfce-terminal corruptions seem to come from sna_poly_fill_rect(). When I force fallback only in this function, the corruptions disappear. Nevertheless the screen crossing issue remains.
Are you able to grab a screenshot or photograph of the screen crossing issue? The first sounds like the bad damage tracking in bug 71198, but the second sounds new.
Created attachment 88739 [details] Screen corruption after moving one window over another within a Xnest session
Created attachment 88740 [details] Windows are not drawn when crossing physical screens within a Xnest session
I've just tried the fix from bug 71198. It makes things a slightly better it seems but does not completely fix the issues. In regards to the screen shot above (intel_screen_corruption_issue.jpg) the corruptions are reduced with this fix in the "Application Launcher" window there. But the "Local Terminal" corruptions still remain. I've done some tests myself and I have found that I can get rid of the xfce-terminal corruptions when I set NO_TILE_8x8 in sna_accel.c to one. So sna_poly_fill_rect_tiled_8x8_blt() is disabled and some fallback function is used. I hope this helps a little in tracking this issue further.
The zaphod mode seems not to influence the issue. Both issues are also seeable without zaphod mode (xrandr). In that case moving the Xnest window beyond the native Xserver screen borders shows the same issue as when I cross screens in zaphod mode. Seems to have the same reason though.
Do you mind writing down a recipe for me to follow to reproduce the non-Zaphod error?
Also it would be worthwhile to check if the same issue is apparent in 2.21.1 or 2.99.901.
2.99.901 shows the issue as well.
Here is the recipe to reproduce the issue: 1. start the X server with SNA enabled and two displays enabled (I've not tested only one display so far but I guess it should show the issue as well) 2. start a window manager (I'm using xfwm4) on that X server (make sure it does opaque window moves) 3. start Xnest on that X server: "Xnest :1 &" 4. start a window manager in Xnest: "DISPLAY=:1 xfwm4 &" (make it does opaque window moves as well) 5. start a terminal window in Xnest: "DISPLAY=:1 xfce-terminal &" 6. start another app i.e with GTK file dialog; I used totem: "DISPLAY=:1 totem &" - NOTE: The totem main window does not show any issues, but the file dialog (Movie->Open...) does, see next step. 7. Move the terminal window over the file dialog. Wipe it over the totem file dialog; you should see rendering corruptions there. 8. Move the totem file dialog over the xfce-terminal window. You should see corruption there as well. But the cause seems to be different. 9. Move the whole Xnest window so it goes beyond your physical screen extents, then move the Xnest window back into screen. You'll notice that some of the windows within the Xnest window are not redrawn correctly I hope this is not too complicated to reproduce for you. If I missed something or you're not able to reproduce the issues, just let me know. Best regards
Ta, I had an compositing (unexpected) window manager running the first time which masked the redraw issue. Step one before narrowing down the issue with the tiled blt.
I've just tried the latest GIT version of the driver and it seems that the "sna: Always copy from the tile source" fix helps my issue somewhat. It seems to fix the drawing issues in i.e. the gtk file dialog or the "Application Launcher" when referring to my screenshots. I've done some further investigations and I've found out that when I comment out the sna_poly_fill_rect_tiled_nxm_blt() call in sna_poly_fill_rect_tiled_blt() I don't get corruptions anymore when I move a window over the xfce-terminal. ... sna_poly_fill_rect_tiled_blt(...) { ... #if 0 if ((tile->drawable.width | tile->drawable.height) <= 0xc && is_power_of_two(tile->drawable.width) && is_power_of_two(tile->drawable.height)) return sna_poly_fill_rect_tiled_nxm_blt(drawable, bo, damage, gc, n, rect, extents, clipped); #endif ... } Is there a bug in the condition around the sna_poly_fill_rect_tiled_nxm_blt() or is there an issue in the function itself?
More likely a bug in the function. The idea is that as the hardware can natively handle 8x8 patterns we creating tessellate smaller patterns to match the hardware (i.e. repeat 2x2, 4x2, 4x4, 8x4 until they generate 8x8 blocks). Do you mind wrapping the nxm_blt function with #undef DBG #define DBG(x) ErrorF x ... #undef DBG #define DBG(x) and attaching the resulting debug log?
The only output I see many many times with this is: sna_poly_fill_rect_tiled_nxm_blt: 4x4 No other dimensions are printed out with my test. Nevertheless the corruption is there.
Do you mind highlighting which corruption is caused by the tiled_nxm_blt fail? Please capture it as a png.
Created attachment 88887 [details] tiled_nxm_blt caused screen corruptions.
The corruption highlights itself in attachment 88887 [details] I think. But don't hesitate if you have any questions about it.
That's not making much sense yet, can you please attach an Xorg.0.log so that I can double check for any other known issues?
Created attachment 88998 [details] Xorg log file with sna_poly_fill_rect_tiled_nxm_blt debug enabled The log file was of course created while triggering the issue (xfce-terminal corruptions when moving another window across).
Is there any chance you can test with a more recent kernel?
I've just tried it on an Ubuntu 12.04.3 LTS where I've installed "linux-generic-lts-quantal" which means that I have kernel version 3.5.0-43-generic kernel. I've installed xfce and Xnest, used my xorg.conf for Zaphod mode and replaced the intel_drv.so by the one I've built from th GIT. Then I did my tests from within an xfce desktop session (mainly to avoid compositors). I started Xnest and started xfwm4 and xfdesktop within the Xnest server and moved a window over an xfce-terminal window. I also moved the Xnest window beyond the screen borders. The results were exactly the same as with the older kernel. I got all the corruptions just as posted in the first three attachments above. So probably it is not kernel driver related unless you think kernel version 3.5 is not recent enough. But testing newer kernels would be much harder for me I fear. What do you think of these results?
I was expecting 3.11+ when I said recent (thinking of some kernel corruption bugs that did not get fixed until then.)
Ok, I'll see if I can get things together to test it on my target machine with one of the latest kernel versions. But besides that I'm still curious that it only happens when I do things within Xnest and not when running the same tests on the local X server directly. Any ideas on that? Does it change timing or caching? Or some synchronization issue only triggered through Xnest?
Ok, just tested it with kernel version 3.12.0-031200-generic from the ubuntu mainline ppa and still get all the issues described above. So I'm quite sure now that the issues do not depend on the kernel version. Would you agree?
That rules out the known issues ;-)
Created attachment 89035 [details] sna_accel.c log for the issue Enabled debug at the beginning of sna_accel.c only and provoked the issue. Maybe the log file helps to track down the issue(s).
I'm still trying to track down the issue about the xfce-terminal in Xnest when moving another window across it. Currently I'm in sna_blt_copy_boxes() since it seems that this is the function that does the fill in xfce-terminal. So my suspicion at the moment is that the driver optimizes fills by filling a small offscreen tile with the desired colour or pattern and then copies the tile to the target x/y on the screen as many times as needed to fill the desired area. Is that the case? If so, it seems to me that the offscreen tile might get corrupted from time to time ... or maybe only the src_pitch is not correct for some reasons. Does anything I've said makes sense to you?
I've just tried the "LinearFramebuffer" driver option along with "ZaphodHeads" and found that I run into an assertion when doing my xfce-terminal test: sna_accel.c:2430: sna_drawable_move_region_to_cpu: Assertion `has_coherent_map(sna, priv->gpu_bo, flags)' failed. Note that the line number might be a little out of sync since I've added some extra debug lines. That made me come to the idea that the issue might be related to the fact that in zaphod mode there are more than one framebuffers and that some piece of code might be not prepared for that good enough. What do you think on that idea?
The redraw issue looks to be an error in Xnest. If you watch xtrace xterm whilst moving a terminal over the Xnest window exposing the contained xterm, you see lots of: Event Expose(12) window=0x200001b x=65535 y=65220 width=1 height=316 count=0 Ho hum.
I disagree with that. When I don't use ZaphodHeads and only one screen but two displays, I don't see any issue. So I still suspect some issue in the framebuffer/backbuffer handling in zaphod mode.
(In reply to comment #31) > I disagree with that. When I don't use ZaphodHeads and only one screen but > two displays, I don't see any issue. So I still suspect some issue in the > framebuffer/backbuffer handling in zaphod mode. You disagree with that Xnest is sending back an obviously invalid event?
;-) I'm sorry. My answer was quite imprecise. I only disagree with saying it is Xnests sole fault when I see corruptions on the screen while I don't see these corruptions with a different driver or the intel driver in a different configuration. Didn't mean any offense anyway.
Created attachment 89149 [details] [review] Fixed typo in sna_blt_fill_begin() It does not change anything regarding my issue. And although I could imagine that the related value might be ignored, I thought I should post this. Maybe it helps someone else.
I just did some wild guessing and did try some xorg.conf options of the intel driver. Nothing did help the issue. But I've noticed that the xfce-terminal crossing issue in Xnest is not related to the zaphod mode. So in normal xrandr mode I do get the same corruptions. Just wanted to let you know.
I've reflected what you've said about the Xnest exposure event coordinates and I agree with that this causes the window contents not being redrawn when crossing screen borders. So we can skip this. But I still have the issue with the sna_poly_fill_rect_tiled_nxm_blt() function. I've tried to debug it and found out that I can reproduce the issue more reliable when I do the following in the Xnest->xfce-terminal window: 1. Start Xnest 2. Start xfce4-terminal within the Xnest server 3. The selected font in the xfc4-terminal is "Monospace 12" 4. Do a "xdpyinfo" in the xfce4-terminal window and watch the output 5. In the last line of the output you should find the word "color", double click it to select it and you should see corruptions as well 6. It seems all words with 5 or 6 characters trigger the corruption, I've not seen any other sizes to corrupt the screen contents Could you try this as well and see if you do get the same issue on your side? If so, do you have any idea why only certain sizes trigger the issue? I hope I don't bother you with this bug too much but I think it might cause corruption in other situations as well. So in order to get a rock solid driver it should be fixed I think. Best regards.
These six calls are generated by one double-click on the "color" word in xfce4-terminal as described in my previous post. Do you see anything strange in the contents of *bo ? Maybe some alignment issue? ========================================================================= Breakpoint 1, sna_poly_fill_rect_tiled_nxm_blt (drawable=0x8064f130, bo=0x806521d0, damage=0x0, gc=0x8064e4a0, n=1, rect=0xb5fba034, extents=0xbffff7d0, clipped=0) at sna_accel.c:11774 11774 in sna_accel.c 1: *bo = {rq = 0x0, exec = 0x0, proxy = 0x0, list = {next = 0x806521dc, prev = 0x806521dc}, request = {next = 0x806521e4, prev = 0x806521e4}, vma = { next = 0x806521ec, prev = 0x806521ec}, map__cpu = 0xb7ffb000, map__gtt = 0x0, binding = {next = 0x0, format = 0, offset = 0}, presumed_offset = 27459584, unique_id = 725, refcnt = 1, handle = 54, target_handle = 4294967295, delta = 0, size = {pages = {count = 2, bucket = 1}, bytes = 134217730}, pitch = 216, tiling = 0, reusable = 1, gpu_dirty = 0, gtt_dirty = 0, domain = 1, needs_flush = 0, snoop = 0, io = 0, flush = 0, scanout = 0, purged = 0} (gdb) Continuing. Breakpoint 1, sna_poly_fill_rect_tiled_nxm_blt (drawable=0x80651928, bo=0x8064fe08, damage=0x0, gc=0x8064e3e8, n=1, rect=0xb5fba034, extents=0xbffff7d0, clipped=0) at sna_accel.c:11774 11774 in sna_accel.c 1: *bo = {rq = 0x0, exec = 0x0, proxy = 0x0, list = {next = 0x8064fe14, prev = 0x8064fe14}, request = {next = 0x8064fe1c, prev = 0x8064fe1c}, vma = { next = 0x8064fe24, prev = 0x8064fe24}, map__cpu = 0xb7ff9000, map__gtt = 0x0, binding = {next = 0x0, format = 0, offset = 0}, presumed_offset = 28786688, unique_id = 777, refcnt = 1, handle = 61, target_handle = 4294967295, delta = 0, size = {pages = {count = 2, bucket = 1}, bytes = 134217730}, pitch = 216, tiling = 0, reusable = 1, gpu_dirty = 0, gtt_dirty = 0, domain = 0, needs_flush = 0, snoop = 0, io = 0, flush = 0, scanout = 0, purged = 0} (gdb) Continuing. Breakpoint 1, sna_poly_fill_rect_tiled_nxm_blt (drawable=0x8064f130, bo=0x806521d0, damage=0x0, gc=0x8064e4a0, n=1, rect=0xb5fba0c0, extents=0xbffff7d0, clipped=0) at sna_accel.c:11774 11774 in sna_accel.c 1: *bo = {rq = 0x8064ed53, exec = 0xb6f655e0, proxy = 0x0, list = {next = 0x806521dc, prev = 0x806521dc}, request = {next = 0x80651f9c, prev = 0x8064ed5c}, vma = {next = 0x806521ec, prev = 0x806521ec}, map__cpu = 0xb7ffb000, map__gtt = 0x0, binding = {next = 0x0, format = 0, offset = 0}, presumed_offset = 27459584, unique_id = 725, refcnt = 1, handle = 54, target_handle = 54, delta = 0, size = {pages = {count = 2, bucket = 1}, bytes = 134217730}, pitch = 216, tiling = 0, reusable = 1, gpu_dirty = 1, gtt_dirty = 0, domain = 1, needs_flush = 1, snoop = 0, io = 0, flush = 0, scanout = 0, purged = 0} (gdb) Continuing. Breakpoint 1, sna_poly_fill_rect_tiled_nxm_blt (drawable=0x80651928, bo=0x8064fe08, damage=0x0, gc=0x8064e3e8, n=1, rect=0xb5fba0c0, extents=0xbffff7d0, clipped=0) at sna_accel.c:11774 11774 in sna_accel.c 1: *bo = {rq = 0x80652663, exec = 0xb6eda5e0, proxy = 0x0, list = {next = 0x8064fe14, prev = 0x8064fe14}, request = {next = 0x80651e24, prev = 0x8065266c}, vma = {next = 0x8064fe24, prev = 0x8064fe24}, map__cpu = 0xb7ff9000, map__gtt = 0x0, binding = {next = 0x0, format = 0, offset = 0}, presumed_offset = 28786688, unique_id = 777, refcnt = 1, handle = 61, target_handle = 61, delta = 0, size = {pages = {count = 2, bucket = 1}, bytes = 134217730}, pitch = 216, tiling = 0, reusable = 1, gpu_dirty = 1, gtt_dirty = 0, domain = 0, needs_flush = 1, snoop = 0, io = 0, flush = 0, scanout = 0, purged = 0} (gdb) Continuing. Breakpoint 1, sna_poly_fill_rect_tiled_nxm_blt (drawable=0x8064f130, bo=0x806521d0, damage=0x0, gc=0x8064dda8, n=1, rect=0xb5fba0ec, extents=0xbffff7d0, clipped=0) at sna_accel.c:11774 11774 in sna_accel.c 1: *bo = {rq = 0x8064ed53, exec = 0xb6f655e0, proxy = 0x0, list = {next = 0x806521dc, prev = 0x806521dc}, request = {next = 0x80651f9c, prev = 0x8064ed5c}, vma = {next = 0x806521ec, prev = 0x806521ec}, map__cpu = 0xb7ffb000, map__gtt = 0x0, binding = {next = 0x0, format = 0, offset = 0}, presumed_offset = 27459584, unique_id = 725, refcnt = 1, handle = 54, target_handle = 54, delta = 0, size = {pages = {count = 2, bucket = 1}, bytes = 134217730}, pitch = 216, tiling = 0, reusable = 1, gpu_dirty = 1, gtt_dirty = 0, domain = 1, needs_flush = 1, snoop = 0, io = 0, flush = 0, scanout = 0, purged = 0} (gdb) Continuing. Breakpoint 1, sna_poly_fill_rect_tiled_nxm_blt (drawable=0x80651928, bo=0x8064fe08, damage=0x0, gc=0x8064dcf0, n=1, rect=0xb5fba0ec, extents=0xbffff7d0, clipped=0) at sna_accel.c:11774 11774 in sna_accel.c 1: *bo = {rq = 0x80652663, exec = 0xb6eda5e0, proxy = 0x0, list = {next = 0x8064fe14, prev = 0x8064fe14}, request = {next = 0x80651e24, prev = 0x8065266c}, vma = {next = 0x8064fe24, prev = 0x8064fe24}, map__cpu = 0xb7ff9000, map__gtt = 0x0, binding = {next = 0x0, format = 0, offset = 0}, presumed_offset = 28786688, unique_id = 777, refcnt = 1, handle = 61, target_handle = 61, delta = 0, size = {pages = {count = 2, bucket = 1}, bytes = 134217730}, pitch = 216, tiling = 0, reusable = 1, gpu_dirty = 1, gtt_dirty = 0, domain = 0, needs_flush = 1, snoop = 0, io = 0, flush = 0, scanout = 0, purged = 0} (gdb)
I've just noticed that bo->tiling is zero. Might that cause the issue? Is it some allocation thing for the target pixmap then?
Created attachment 89584 [details] [review] Only use kgem_bo's suitable for tiling. I've followed the bo->tiling == 0 case and found that it fixes my issue when I make sure that sna_poly_fill_rect_tiled_nxm_blt() is not called with bo's where tiling == 0. So only use kgem_bo's suitable for tiling when calling sna_poly_fill_rect_tiled_nxm_blt(). Does that make sense to you? If so, I'd be glad if you could apply the patch to the HEAD. Let me know if you have any doubts about this.
Ah, bo->tiling is the layout of the surface in GPU memory. The GPU prefers a tiled allocation to improve TLB hitrate and spatial coherency. As such, we allocate all surfaces as tiled when possible - especially the frontbuffer. So in effect your patch just says not to use nxm tiling code.
(In reply to comment #34) > Created attachment 89149 [details] [review] [review] > Fixed typo in sna_blt_fill_begin() > > It does not change anything regarding my issue. > And although I could imagine that the related value might be ignored, I > thought I should post this. Maybe it helps someone else. Ta. Unfortunately that only helps people running future hardware...
(In reply to comment #40) > Ah, bo->tiling is the layout of the surface in GPU memory. The GPU prefers a > tiled allocation to improve TLB hitrate and spatial coherency. As such, we > allocate all surfaces as tiled when possible - especially the frontbuffer. > So in effect your patch just says not to use nxm tiling code. Yes, that's what the patch does and it is since nxm seems not to work with non-tiling buffers. Doesn't that make sense?
Your insistence that bo->tiling mattered made me double check that I was setting the right bits in the BLT command headers. And would you believe that I missed the tiled_8x8_blt XY_SETUP_BLT? Pushed commit 38ef572.
I'm sure your fixes are correct and logical. But unfortunately they don't fix my problem. I still get bo's with tiling==0 in nxm and still get the screen corruption. See the gdb debug session: Breakpoint 5, kgem_choose_tiling (kgem=0xb6e9a000, tiling=1, width=54, height=22, bpp=32) at kgem.c:3815 3815 kgem.c: No such file or directory. (gdb) bt #0 kgem_choose_tiling (kgem=0xb6e9a000, tiling=1, width=54, height=22, bpp=32) at kgem.c:3815 #1 0x0067593c in kgem_can_create_2d (kgem=0xb6e9a000, width=54, height=22, depth=24) at kgem.c:3901 #2 0x0067d250 in sna_create_pixmap (screen=0x80240880, width=54, height=22, depth=24, usage=0) at sna_accel.c:1239 #3 0x80032b31 in ?? () #4 0x800e3e53 in ?? () #5 0x800379ed in ?? () #6 0x800253ea in ?? () #7 0x003204d3 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6 #8 0x80025729 in _start () (gdb) n 3816 in kgem.c (gdb) bt #0 kgem_choose_tiling (kgem=0xb6e9a000, tiling=0, width=54, height=22, bpp=32) at kgem.c:3816 #1 0x0067593c in kgem_can_create_2d (kgem=0xb6e9a000, width=54, height=22, depth=24) at kgem.c:3901 #2 0x0067d250 in sna_create_pixmap (screen=0x80240880, width=54, height=22, depth=24, usage=0) at sna_accel.c:1239 #3 0x80032b31 in ?? () #4 0x800e3e53 in ?? () #5 0x800379ed in ?? () #6 0x800253ea in ?? () #7 0x003204d3 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6 #8 0x80025729 in _start () (gdb) cont Continuing. Breakpoint 5, kgem_choose_tiling (kgem=0xb6f25000, tiling=1, width=54, height=22, bpp=32) at kgem.c:3815 3815 in kgem.c (gdb) bt #0 kgem_choose_tiling (kgem=0xb6f25000, tiling=1, width=54, height=22, bpp=32) at kgem.c:3815 #1 0x0067593c in kgem_can_create_2d (kgem=0xb6f25000, width=54, height=22, depth=24) at kgem.c:3901 #2 0x0067d250 in sna_create_pixmap (screen=0x80235538, width=54, height=22, depth=24, usage=0) at sna_accel.c:1239 #3 0x80032b31 in ?? () #4 0x800e3e53 in ?? () #5 0x800379ed in ?? () #6 0x800253ea in ?? () #7 0x003204d3 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6 #8 0x80025729 in _start () (gdb) n 3816 in kgem.c (gdb) c Continuing. Breakpoint 5, kgem_choose_tiling (kgem=0xb6f25000, tiling=1, width=54, height=22, bpp=32) at kgem.c:3815 3815 in kgem.c (gdb) n 3816 in kgem.c (gdb) bt #0 kgem_choose_tiling (kgem=0xb6f25000, tiling=0, width=54, height=22, bpp=32) at kgem.c:3816 #1 0x0067c4d1 in sna_pixmap_choose_tiling (pixmap=0x806d8920, tiling=1) at sna_accel.c:616 #2 0x00681f5a in sna_pixmap_move_to_gpu (pixmap=0x806d8920, flags=3) at sna_accel.c:3801 #3 0x0068147c in sna_drawable_use_bo (drawable=0x806d8920, flags=25, box=0xbffff7d0, damage=0xbffff7dc) at sna_accel.c:3409 #4 0x0069c7b1 in sna_poly_fill_rect (draw=0x806d8920, gc=0x806d7450, n=1, rect=0xb33e8034) at sna_accel.c:13884 #5 0x8010f9ad in ?? () #6 0x80033ee9 in ?? () #7 0x800e6901 in ?? () #8 0x800379ed in ?? () #9 0x800253ea in ?? () #10 0x003204d3 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6 #11 0x80025729 in _start () (gdb) cont Continuing. Breakpoint 1, sna_poly_fill_rect_tiled_nxm_blt (drawable=0x806d8920, bo=0x806db8f0, damage=0x0, gc=0x806d7450, n=1, rect=0xb33e8034, extents=0xbffff7d0, clipped=0) at sna_accel.c:11761 11761 sna_accel.c: No such file or directory. (gdb) print *bo $1 = {rq = 0x0, exec = 0x0, proxy = 0x0, list = {next = 0x806db8fc, prev = 0x806db8fc}, request = {next = 0x806db904, prev = 0x806db904}, vma = { next = 0x806db90c, prev = 0x806db90c}, map__cpu = 0xb5433000, map__gtt = 0x0, binding = {next = 0x0, format = 0, offset = 0}, presumed_offset = 76075008, unique_id = 466, refcnt = 1, handle = 137, target_handle = 4294967295, delta = 0, size = {pages = {count = 14, bucket = 3}, bytes = 402653198}, pitch = 216, tiling = 0, reusable = 1, gpu_dirty = 0, gtt_dirty = 0, domain = 0, needs_flush = 0, snoop = 0, io = 0, flush = 0, scanout = 0, purged = 0} (gdb) (gdb) bt #0 sna_poly_fill_rect_tiled_nxm_blt (drawable=0x806d8920, bo=0x806db8f0, damage=0x0, gc=0x806d7450, n=1, rect=0xb33e8034, extents=0xbffff7d0, clipped=0) at sna_accel.c:11761 #1 0x006968d0 in sna_poly_fill_rect_tiled_blt (drawable=0x806d8920, bo=0x806db8f0, damage=0x0, gc=0x806d7450, n=1, rect=0xb33e8034, extents=0xbffff7d0, clipped=0) at sna_accel.c:11856 #2 0x0069c8a4 in sna_poly_fill_rect (draw=0x806d8920, gc=0x806d7450, n=1, rect=0xb33e8034) at sna_accel.c:13904 #3 0x8010f9ad in ?? () #4 0x80033ee9 in ?? () #5 0x800e6901 in ?? () #6 0x800379ed in ?? () #7 0x800253ea in ?? () #8 0x003204d3 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6 #9 0x80025729 in _start () (gdb)
Would you mind to accept the "Only use kgem_bo's suitable for tiling."-patch from above? It is still needed in my situation and makes sure that the nxm_blit function never gets pixmaps not suitable for it. Don't you think that is a good thing? Best regards.
(In reply to comment #45) > Would you mind to accept the "Only use kgem_bo's suitable for tiling."-patch > from above? It is still needed in my situation and makes sure that the > nxm_blit function never gets pixmaps not suitable for it. Don't you think > that is a good thing? No. The patch is just a hack that disables the use of the pattern blits.
But in kgem_choose_tiling() there are paths depending on the pixmap dimensions that return I915_TILING_NONE. And these are exactly the pixmaps that don't work in the nxm-function later on. That's my understanding. So where should this issue be fixed then? In kgem_choose_tiling()?
Finally got around to writing a test case for tiled/stippled blits and fixing up the failures. Can you please give tip of xf86-video-intel a whirl?
(In reply to comment #48) > Can you please give tip of xf86-video-intel a whirl? What does that mean? I'm not a native speaker so I have some difficulties to interpret your sentence.
(In reply to comment #49) > (In reply to comment #48) > > Can you please give tip of xf86-video-intel a whirl? > > What does that mean? I'm not a native speaker so I have some difficulties to > interpret your sentence. Please update to the latest xf86-video-intel from git (http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/) and retest.
Sorry for the delay. I've just tested the current GIT version and found that it fixes the nxm issue. That's great news for me. Thanks for your continuous help and for your efforts to fix this actually. I'm closing this bug then. Best regards.
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.