Bug 97461

Summary:	FS-UAE waits forever with glClientWaitSync() when using glFenceSync() on amdgpu/radeonsi
Product:	Mesa	Reporter:	Lem <lem.jjr>
Component:	Drivers/Gallium/radeonsi	Assignee:	Default DRI bug account <dri-devel>
Status:	RESOLVED FIXED	QA Contact:	Default DRI bug account <dri-devel>
Severity:	normal
Priority:	medium
Version:	git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	apitrace of fs-uae waiting forever after using glFenceSync() possible fix

Description Lem 2016-08-24 09:06:57 UTC

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

Comment 1 Marek Olšák 2016-08-25 00:12:53 UTC

Created attachment 126023 [details] [review]
possible fix

Could you please try this patch?

Comment 2 Lem 2016-08-25 01:49:00 UTC

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

Comment 3 Lem 2016-08-25 01:55:51 UTC

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.

Comment 4 Marek Olšák 2016-08-25 21:09:39 UTC

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.