Skip to content

WIP: ipc: Implement xrWaitFrame by waiting on a shared semaphore

Christoph Haag requested to merge haagch/monado:christoph/waitframe_semaphore into master

If the compositor_wait_frame() is supplied with a callback function, it returns immediately and uses a posix timer to call the callback at the target time.

When a callback is supplied, the caller is responsible for waiting until the callback is called. In the ipc compositor this is implemented with the client waiting on a posix semaphore in shared memory which is signalled by the callback.

This fixes xrdesktop stalls caused by all OpenXR calls from other threads being blocked on the IPC while xrWaitFrame() is running.

Questions:

  • Is using one shared memory semaphore for this okay when multiple applications can run?
    • Only one application can run xrWaitFrame at a time (or in the case of overlays, use the same xrWaitFrame as the app)
    • Alternatives: array of shared memory semaphores, named semaphores, mutexes, splitting xrWaitFrame into two calls on the IPC protocol level, changing the protocol to enable concurrent send/receive
  • Is using a posix timer okay or do we want our own solution?
  • xrWaitSwapchainImage may need the same treatment, though waits are expected to be much shorter

Merge request reports