Created attachment 141381 [details] PresentDebug logs Description: WoW with Wine shows a black output window when run on Xwayland 1.20-rc2 and later (including 1.20.1 and master). Xwayland 1.20-rc1 worked fine. The issue first occured with the introduction of Present support in Xwayland (commit be087778). Steps to reproduce: 1. Download Wow for free (trial version https://battle.net/account/creation/tos.html?theme=wow&style=wow-trial) 2. Configure Wine to emulate Windows 7 (otherwise WoW won't install ...) 3. Run "wine World-of-Warcraft-Setup.exe" 4. Play the game Actual result: A black window shows up, while sounds plays. Expected result: The output window shows some content Additional data: xserver-1.20rc1 worked, xserver-1.20rc2 fails and first bad commit seems to be the enabling of Present support in Xwayland: commit be087778a0eae3093ffdbba3ff7c9f3863d8e1d4 Author: Roman Gilg <subdiff@gmail.com> Date: Tue Mar 13 16:00:57 2018 +0100 xwayland: Activate Present flips in rootless mode with Glamor Link the newly introduced support for Present flips. For now flips can only be used in rootless mode together with Glamor. Running Xwayland with PresentDebug enabled while the issue occurs gives (see attachment)
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
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.