The cursor moving actually is not interesting. Hardware cursor movement is a separate thread of the Mir server and drawn separately to the Mir server process. So the Mir compositor can be hung and the hardware cursor will keep moving smoothly.
Turns out my compositor thread is hung deep in the radeon code below eglSwapBuffers, which supports the idea that this is purely GPU flooding/starvation:
#0 pthread_cond_wait@@GLIBC_2.3.2 ()
at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007fffef2624ab in cnd_wait (mtx=0x7ffff7ebd1c8, cond=0x7ffff7ebd1f0)
at ../../../../include/c11/threads_posix.h:159
#2 util_queue_job_wait (fence=fence@entry=0x7ffff7ebd1c8)
at ../../../../src/gallium/auxiliary/util/u_queue.c:46
#3 0x00007fffef59770f in radeon_drm_cs_sync_flush (rcs=0x7ffff7e95010)
at ../../../../../../src/gallium/winsys/radeon/drm/radeon_drm_cs.c:489
#4 radeon_drm_cs_flush (rcs=0x7ffff7e95010, flags=2, pfence=<optimised out>)
at ../../../../../../src/gallium/winsys/radeon/drm/radeon_drm_cs.c:680
#5 0x00007fffef46cd47 in r600_context_gfx_flush (context=0x555555809b90,
flags=2, fence=0x7fffe8c94838)
at ../../../../../src/gallium/drivers/r600/r600_hw_context.c:283
#6 0x00007fffef5b666e in r600_flush_from_st (ctx=0x555555809b90,
fence=0x7fffe8c948c0, flags=<optimised out>)
at ../../../../../src/gallium/drivers/radeon/r600_pipe_common.c:357
#7 0x00007fffef0b513a in st_context_flush (stctxi=0x55555581f620, flags=2,
fence=<optimised out>) at ../../../src/mesa/state_tracker/st_manager.c:506
#8 0x00007fffef1c860c in dri_flush (cPriv=<optimised out>,
dPriv=<optimised out>, flags=<optimised out>, reason=<optimised out>)
at ../../../../../src/gallium/state_trackers/dri/dri_drawable.c:532
#9 0x00007ffff4322714 in ?? ()
from /usr/lib/x86_64-linux-gnu/mesa-egl/libEGL.so.1
#10 0x00007ffff4312faf in eglSwapBuffers ()
from /usr/lib/x86_64-linux-gnu/mesa-egl/libEGL.so.1
#11 0x00007fffee5c18fb in mir::graphics::mesa::helpers::EGLHelper::swap_buffers
(this=0x555555807e08)
at /home/dan/bzr/mir/toy/src/platforms/mesa/server/display_helpers.cpp:402
#12 0x00007fffee5953b3 in mir::graphics::mesa::DisplayBuffer::swap_buffers (
this=0x555555807d60)
at /home/dan/bzr/mir/toy/src/platforms/mesa/server/kms/display_buffer.cpp:284
#13 0x00007ffff5e2bbbb in mir::renderer::gl::CurrentRenderTarget::swap_buffers
(this=0x7fffe40008c8)
at /home/dan/bzr/mir/toy/src/renderers/gl/renderer.cpp:75
#14 0x00007ffff5e2c878 in mir::renderer::gl::Renderer::render (
this=0x7fffe40008c0,
renderables=std::vector of length 2, capacity 2 = {...})
at /home/dan/bzr/mir/toy/src/renderers/gl/renderer.cpp:217
The cursor moving actually is not interesting. Hardware cursor movement is a separate thread of the Mir server and drawn separately to the Mir server process. So the Mir compositor can be hung and the hardware cursor will keep moving smoothly.
Turns out my compositor thread is hung deep in the radeon code below eglSwapBuffers, which supports the idea that this is purely GPU flooding/ starvation:
#0 pthread_ cond_wait@ @GLIBC_ 2.3.2 () unix/sysv/ linux/x86_ 64/pthread_ cond_wait. S:185 d1c8, cond=0x7ffff7eb d1f0) ./../include/ c11/threads_ posix.h: 159 fence@entry= 0x7ffff7ebd1c8) ./../src/ gallium/ auxiliary/ util/u_ queue.c: 46 drm_cs_ sync_flush (rcs=0x7ffff7e9 5010) ./../.. /../src/ gallium/ winsys/ radeon/ drm/radeon_ drm_cs. c:489 5010, flags=2, pfence=<optimised out>) ./../.. /../src/ gallium/ winsys/ radeon/ drm/radeon_ drm_cs. c:680 gfx_flush (context= 0x555555809b90, 94838) ./../.. /src/gallium/ drivers/ r600/r600_ hw_context. c:283 9b90, 0x7fffe8c948c0, flags=<optimised out>) ./../.. /src/gallium/ drivers/ radeon/ r600_pipe_ common. c:357 0x55555581f620, flags=2, <optimised out>) at ../../. ./src/mesa/ state_tracker/ st_manager. c:506 <optimised out>, flags=<optimised out>, reason=<optimised out>) ./../.. /src/gallium/ state_trackers/ dri/dri_ drawable. c:532 x86_64- linux-gnu/ mesa-egl/ libEGL. so.1 x86_64- linux-gnu/ mesa-egl/ libEGL. so.1 :mesa:: helpers: :EGLHelper: :swap_buffers 0x555555807e08) bzr/mir/ toy/src/ platforms/ mesa/server/ display_ helpers. cpp:402 :mesa:: DisplayBuffer: :swap_buffers ( 0x555555807d60) bzr/mir/ toy/src/ platforms/ mesa/server/ kms/display_ buffer. cpp:284 :gl::CurrentRen derTarget: :swap_buffers 0x7fffe40008c8) bzr/mir/ toy/src/ renderers/ gl/renderer. cpp:75 :gl::Renderer: :render ( 0x7fffe40008c0, =std::vector of length 2, capacity 2 = {...}) bzr/mir/ toy/src/ renderers/ gl/renderer. cpp:217
at ../sysdeps/
#1 0x00007fffef2624ab in cnd_wait (mtx=0x7ffff7eb
at ../../.
#2 util_queue_job_wait (fence=
at ../../.
#3 0x00007fffef59770f in radeon_
at ../../.
#4 radeon_drm_cs_flush (rcs=0x7ffff7e9
at ../../.
#5 0x00007fffef46cd47 in r600_context_
flags=2, fence=0x7fffe8c
at ../../.
#6 0x00007fffef5b666e in r600_flush_from_st (ctx=0x55555580
fence=
at ../../.
#7 0x00007fffef0b513a in st_context_flush (stctxi=
fence=
#8 0x00007fffef1c860c in dri_flush (cPriv=<optimised out>,
dPriv=
at ../../.
#9 0x00007ffff4322714 in ?? ()
from /usr/lib/
#10 0x00007ffff4312faf in eglSwapBuffers ()
from /usr/lib/
#11 0x00007fffee5c18fb in mir::graphics:
(this=
at /home/dan/
#12 0x00007fffee5953b3 in mir::graphics:
this=
at /home/dan/
#13 0x00007ffff5e2bbbb in mir::renderer:
(this=
at /home/dan/
#14 0x00007ffff5e2c878 in mir::renderer:
this=
renderables
at /home/dan/