Created attachment 125993 [details] apitrace of fs-uae waiting forever after using glFenceSync() Hi, In recent mesa-git (during August 2016), there was a change to amdgpu/radeonsi that has caused FS-UAE (Amiga emulator) to wait forever with glClientWaitSync() after using glFenceSync(). While it is waiting, it uses 24% CPU but does not cause the CPU to clock to higher pstates. Using an alternative OpenGL rendering mode that does not include fences allows FS-UAE to start as expected. This problem is not present on nVidia, AMDGPU-PRO, nor open source amdgpu as shipped with Ubuntu 16.04, and has only been a problem during this month (August 2016). Hardware: AMD FX-8350 AMD Radeon 380X 4Gb Asus MG279 27" 2560x1440 144Hz IPS, connected via DisplayPort Software: Ubuntu 16.04 AMD64 Padoka PPA FS-UAE 2.7.14dev2 from https://launchpad.net/~fengestad/+archive/ubuntu/devel Notable apitrace output on frame number 3 of a waiting instance of fs-uae (from the attached apitrace file): 1490 @0 glFenceSync(condition = GL_SYNC_GPU_COMMANDS_COMPLETE, flags = 0) = 0x8aba220 1491 @0 glFlush() 1492 @0 glClientWaitSync(sync = 0x8aba220, flags = GL_SYNC_FLUSH_COMMANDS_BIT, timeout = 0) = GL_TIMEOUT_EXPIRED 1493 @0 glClientWaitSync(sync = 0x8aba220, flags = 0x0, timeout = 0) = GL_TIMEOUT_EXPIRED ..... 15561 @0 glClientWaitSync(sync = 0x8aba220, flags = 0x0, timeout = 0) = GL_TIMEOUT_EXPIRED I suspect this will be related to the fences work that has been committed recently? Happy to do more testing. I have also reported the bug in the FS-UAE development thread here: http://eab.abime.net/showpost.php?p=1107609&postcount=1146 In case it's helpful at this point: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD TONGA (DRM 3.1.0 / 4.4.0-34-lowlatency, LLVM 4.0.0) OpenGL core profile version string: 4.3 (Core Profile) Mesa 12.1.0-devel - padoka PPA OpenGL core profile shading language version string: 4.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 12.1.0-devel - padoka PPA OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL ES profile version string: OpenGL ES 3.1 Mesa 12.1.0-devel - padoka PPA OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 Cheers
Created attachment 126023 [details] [review] possible fix Could you please try this patch?
Hi Marek, Thanks for the patch. I *think* it worked. I fumbled my way through building mesa (git cloning and applying the patch was easy), then copying just the new mesa/lib/gallium/radeonsi_dri.so to /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so , leaving everything else (binaries, libraries) as it is with the Padoka PPA, and now fs-uae will run with fences enabled. I haven't done any other tests (games etc) for any regressions. Cheers
I just verified it with a new apitrace. There is indeed glFenceSync() being called. Frame 3 now looks like: 1510 @0 glFenceSync(condition = GL_SYNC_GPU_COMMANDS_COMPLETE, flags = 0) = 0x8c47bf0 1511 @0 glFlush() 1512 @0 glClientWaitSync(sync = 0x8c47bf0, flags = GL_SYNC_FLUSH_COMMANDS_BIT, timeout = 0) = GL_TIMEOUT_EXPIRED 1513 @0 glClientWaitSync(sync = 0x8c47bf0, flags = 0x0, timeout = 0) = GL_ALREADY_SIGNALED 1514 @0 glBegin(mode = GL_QUADS) 1515 @0 glTexCoord2d(s = 0, t = nan) ... 1523 @0 glEnd() 1524 @0 glXSwapBuffers(dpy = 0x88db6a0, drawable = 83886088) and onto Frame 4, and so forth.
I pushed the fix. Closing.
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.