Bug 107757

Oh, and a bt of the client side gives:

#0  0x00007f8e7dbf3ae9 in syscall () from /lib64/libc.so.6
#1  0x00007f8e400ffc12 in sys_futex (val3=0, addr2=0x0, timeout=0x0, val1=-1,
    op=0, addr1=0x7f8e6808f000) at xshmfence_futex.h:66
#2  futex_wait (value=-1, addr=0x7f8e6808f000) at xshmfence_futex.h:66
#3  xshmfence_await (f=0x7f8e6808f000) at xshmfence_futex.c:63
#4  0x00007f8e40b6aa1b in dri3_get_buffer.isra () from /lib64/libGLX_mesa.so.0
#5  0x00007f8e40b6b84e in loader_dri3_get_buffers ()
   from /lib64/libGLX_mesa.so.0
#6  0x00007f8e3ef15805 in intel_update_renderbuffers ()
   from /usr/lib64/dri/i965_dri.so
#7  0x00007f8e3ef15e95 in intel_prepare_render ()
   from /usr/lib64/dri/i965_dri.so
#8  0x00007f8e3ef11315 in brw_clear () from /usr/lib64/dri/i965_dri.so
#9  0x00007f8e6b2f62ba in device_clear_render_targets ()
   from /usr/bin/../lib64/wine/wined3d.dll.so
#10 0x00007f8e6b2efc05 in wined3d_cs_exec_clear ()
   from /usr/bin/../lib64/wine/wined3d.dll.so
#11 0x00007f8e6b2f169b in wined3d_cs_st_submit ()
   from /usr/bin/../lib64/wine/wined3d.dll.so
#12 0x00007f8e6b3060ba in wined3d_device_clear_rendertarget_view ()
   from /usr/bin/../lib64/wine/wined3d.dll.so
#13 0x00007f8e681883af in d3d11_immediate_context_ClearRenderTargetView ()
   from /usr/bin/../lib64/wine/d3d11.dll.so
#14 0x0000000140395718 in ?? ()
#15 0x000000000023f810 in ?? ()
#16 0x0000000000000000 in ?? ()

(courtesy of Carlos Garnacho ^_~)

The logs from attachment 141381 [details] are useless, WoW uses multiple windows and those are from a working case (where the window is decorated/reparented anyway).

But in the case of the actual game output window (the one which stays black), we get instead:

q 1 0x1eb93a0        1: 016000bf -> 016000b9 (crtc 0x126f450) flip 1 vsync 0 serial 1
	f 1 0x1eb93a0        1: 016000bf -> 016000b9
	e 1 ust 235274993625 msc 1
	n 1 0x1eb93a0        1: 016000bf -> 016000b9


And that's it!

So present_wmnd does notify and send an event to the client.

On the client side, the backtrace shows it's stuck in `xshmfence_await()` called from `dri3_get_buffer()` (through `dri3_fence_await()`) but I still don't understand what prevents that fence from being triggered.

Created attachment 141439 [details] [review]
loader/dri3: Only wait for fence when necessary in  dri3_get_buffer

Does this Mesa patch fix the problem?

(In reply to Michel Dänzer from comment #3)
> Does this Mesa patch fix the problem?

Unfortunately, no, it doesn't.

But I managed to get a better stacktrace with symbols of the hung thread (that's with mesa 18.2.0-rc5 _without_ attachment 141439 [details] [review] applied):

#1  0x00007f7ff5258c12 in sys_futex (val3=0, addr2=0x0, timeout=0x0, val1=-1, op=0, addr1=0x7f8005cf2000) at xshmfence_futex.h:66
#2  futex_wait (value=-1, addr=0x7f8005cf2000) at xshmfence_futex.h:66
#3  xshmfence_await (f=0x7f8005cf2000) at xshmfence_futex.c:63
#4  0x00007f7ff5cc5c5f in dri3_fence_await (buffer=0x7f7fcc0a4150, draw=0x7f7fcc03f4f8, c=<optimized out>) at loader_dri3_helper.c:239
#5  dri3_get_buffer (format=format@entry=4107, buffer_type=buffer_type@entry=loader_dri3_buffer_front, draw=draw@entry=0x7f7fcc03f4f8, 
    driDrawable=0x7f7fcc041a50) at loader_dri3_helper.c:1822
#6  0x00007f7ff5cc6b4a in loader_dri3_get_buffers (driDrawable=driDrawable@entry=0x7f7fcc041a50, format=4107, stamp=stamp@entry=0x7f7fcc041a80, 
    loaderPrivate=loaderPrivate@entry=0x7f7fcc03f4f8, buffer_mask=buffer_mask@entry=3, buffers=buffers@entry=0x563fa60)
    at loader_dri3_helper.c:1948
#7  0x00007f7fdb83d4a5 in intel_update_image_buffers (drawable=0x7f7fcc041a50, brw=0x7f7fcc068980) at brw_context.c:1757
#8  intel_update_renderbuffers (context=context@entry=0x7f7fcc041810, drawable=drawable@entry=0x7f7fcc041a50) at brw_context.c:1424
#9  0x00007f7fdb83db35 in intel_prepare_render (brw=brw@entry=0x7f7fcc068980) at brw_context.c:1445
#10 0x00007f7fdb838f63 in brw_clear () at brw_clear.c:254
#11 0x00007f80080627ea in device_clear_render_targets (device=<optimized out>, rt_count=<optimized out>, fb=<optimized out>, rect_count=1, 
    clear_rect=0x1301c090, draw_rect=0x1301c064, flags=1, color=<optimized out>, depth=0, stencil=0) at device.c:449
#12 0x00007f800805bd55 in wined3d_cs_exec_clear (cs=<optimized out>, data=0x1301c04c) at cs.c:574
#13 0x00007f800805e7b4 in wined3d_cs_run (ctx=<optimized out>) at cs.c:2856
#14 0x000000007bcb812a in call_thread_func (entry=0x7f800805e660 <wined3d_cs_run>, arg=0x12fba030) at signal_x86_64.c:4378
#15 0x0000000000000000 in ?? ()

(gdb) f 5
#5  dri3_get_buffer (format=format@entry=4107, buffer_type=buffer_type@entry=loader_dri3_buffer_front, draw=draw@entry=0x7f7fcc03f4f8, 
    driDrawable=0x7f7fcc041a50) at loader_dri3_helper.c:1822
1822	   dri3_fence_await(draw->conn, draw, buffer);
(gdb) list
1817	         }
1818	      }
1819	      buffer = new_buffer;
1820	      draw->buffers[buf_id] = buffer;
1821	   }
1822	   dri3_fence_await(draw->conn, draw, buffer);
1823	
1824	   /*
1825	    * Do we need to preserve the content of a previous buffer?
1826	    *

Sorry, I take that back, attachment 141439 [details] [review] works!

Thanks for the report and testing, fixed in Git master:

Commit: e34dd4f5084c73c0a2fcadf783e8f7d8199bb5ca
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=e34dd4f5084c73c0a2fcadf783e8f7d8199bb5ca

Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Tue Sep  4 18:18:57 2018 +0200

loader/dri3: Don't wait for fence of old buffer when re-allocating it