1193615 - Minimize X11 calls on the compositor thread using GL layers

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Andrew Comminos [:acomminos]]

X11 synchronization on the compositor thread using GL layers is quite costly; we require an exclusive lock on the X11 display whenever making a call (using XInitThreads), blocking the main thread's X11 calls. This is responsible for many of our freezes using OMTC during startup.

GLX defines two command streams, the X11 and GL streams. As per the GLX 1.4 specification:

> Commands in the OpenGL stream, which obey the sequentiality guarantees for OpenGL requests are:
> - glXWaitX
> - glXSwapBuffers (see below)
> - All OpenGL Commands
> glXSwapBuffers is in the OpenGL stream if and only if the display
> and drawable are those belonging to the calling thread’s current
> context; otherwise it is in the X stream.

We should aim to minimize the number of calls on the X11 stream on the compositor thread. One option to consider would be using a separate X11 display on the compositor thread in order to reduce contention in the output buffer if the GLX implementation performs a sync. That may require changing some our expectations of synchronization with GLX.

Comment 1

[Karl Tomlinson (:karlt)]

(In reply to Andrew Comminos [:acomminos] from comment #0)
> X11 synchronization on the compositor thread using GL layers is quite
> costly; we require an exclusive lock on the X11 display whenever making a
> call (using XInitThreads), blocking the main thread's X11 calls. This is
> responsible for many of our freezes using OMTC during startup.

Are you referring to the lock to write requests to the stream, or is there a lock held while waiting for a reply?

It makes sense to do everything possible to avoid X11 round trips on the compositor thread.  If it's merely the lock to write to the same stream, then I'm surprised if that was causing freezes.

> One option to consider would be using a separate X11
> display on the compositor thread in order to reduce contention in the output
> buffer if the GLX implementation performs a sync.

Perhaps, but there is only one server thread processing the streams.
My guess would be the the extra synchronization required would be more costly than the benefit.

Comment 2

[Andrew Comminos [:acomminos]]

(In reply to Karl Tomlinson (ni?:karlt) from comment #1)
> (In reply to Andrew Comminos [:acomminos] from comment #0)
> > X11 synchronization on the compositor thread using GL layers is quite
> > costly; we require an exclusive lock on the X11 display whenever making a
> > call (using XInitThreads), blocking the main thread's X11 calls. This is
> > responsible for many of our freezes using OMTC during startup.
> 
> Are you referring to the lock to write requests to the stream, or is there a
> lock held while waiting for a reply?

Default Xlib does hold the display lock on some calls when waiting for a reply; for example, see XGetGeometry as defined in Xlib's src/GetGeom.c. The display is not unlocked until after a response is obtained from the server.

The freezes aren't terribly bad, sorry if that wasn't clear in the original bug. Mainly just reduced composition performance when the main thread is especially active with X11 events.

Comment 3

[Karl Tomlinson (:karlt)]

UnlockDisplay() is called before xcb_wait_for_reply() in _XReply.

Round-trips on the main thread will affect performance, but I'd hope it
doesn't stall the compositor thread.

Comment 4

[Andrew Comminos [:acomminos]]

Closing; we got rid of XGetGeometry on the compositor thread, and we use a separate display now as well.