IgnoreClient question

Mario Kleiner mario.kleiner at tuebingen.mpg.de
Mon Jun 28 17:18:31 PDT 2010

On Jun 29, 2010, at 12:27 AM, Jesse Barnes wrote:

> In GL code, we have two subsystems using IgnoreClient these days: GLX
> and DRI2.
> GLX uses it to suspend clients while the server is VT switched away
> (not sure why, maybe some drivers can't handle it?).
> DRI2 uses it to implement swap throttling and various GLX extensions
> and DRI2 protocol requests.


do we really need IgnoreClient() for throttling in DRI2?

If i remember correctly, the DRI2 requests i've seen are all like this:

1. Some request (DRI2GetBuffersWithFormat() / DRI2SwapBuffers() /  
glXWaitForMscOML() / glXWaitForSBCOML().
2. Request needs to wait for some event, either a scheduled vblank  
event to be delivered from the kernel, or a swap to complete.
3. Server responds to the client which was waiting for a xreply in  
response to completion of the request.

The client's calling thread always has to wait for a reply from the  
server before it can continue doing anything, so that thread would  
block anyway in xlib, waiting for a xreply from the server at step 3.

Because we only have one "wait slot" per drawable, we block the whole  
xdisplay connection via IgnoreClient() to prevent other threads in  
the same client from issuing such "blocking" requests to the same  
drawable - it would overflow our single wait slot.

This implementation isn't safe if multiple display connections  
address a single drawable, e.g., 1 connection per client thread. It  
also doesn't allow to handle multipe or parallel outstanding  
requests, something that would be useful with some of the new DRI2  
protocol requests.

If we could replace that single "wait slot" with one wait list per  
drawable and protocol request (1 list for glXWaitForMscOML, 1 list  
for glXWaitForSbcOML and maybe 1 list for swap related throttling),  
then we probably wouldn't need to block the connection via  
IgnoreClient at all and could have multiple outstanding / parallel  

What i assume but didn't check is that xlib doesn't have a problem  
with getting replies out of sequence, e.g., getting a reply to a  
request with seq nr 15 before another reply with nr 12 on the same  
connection? Just neccessary for the sequence number in the reply  
matching the corresponding sequence number from the request? xlib  
doesn't time out if a request doesn't quickly get a reply?

If we could implement such wait lists then we could ignore  
IgnoreClient and solve the multi-threading / multiple drawable issues  
i believe exist.


Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen

e-mail: mario.kleiner at tuebingen.mpg.de
office: +49 (0)7071/601-1623
fax:    +49 (0)7071/601-616
www:    http://www.kyb.tuebingen.mpg.de/~kleinerm
"For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled."
(Richard Feynman)

More information about the xorg-devel mailing list