Re: IgnoreClient question
On Jul 2, 2010, at 11:43 PM, Jesse Barnes wrote: On Tue, 29 Jun 2010 04:07:48 +0200 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: ... Then i think the idea of multiple wait queues doesn't allow to get rid of IgnoreClient(), but we will still need those wait queues in addition to IgnoreClient() to handle multiple blocking requests for one drawable from different clients / x-connections correctly. Right, we have lists in the server now too, so it shouldn't be too hard. Another question: If i have separate x-connections, e.g., one for each drawable and each connection has an opengl rendering context attached to the drawable, then i assume these context still can share state (display lists, shaders, texture objects, fbo's etc.), right? Anything associated with the drawable would be shared, but context specific information would still be separate per thread. Display lists can be shared explicitly, likewise for some of the other objects, so you should be able to get the sharing you want. Good. I will switch our client toolkit to a 1 x-connection per thread model. If a wait queue implementation in the dri2 sync swap bits hasn't magically shown up by the time i hit the limits of the current implementation, i'll give implementing it myself a try. -mario ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: IgnoreClient question
On Tue, 29 Jun 2010 04:07:48 +0200 Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: On Jun 29, 2010, at 2:24 AM, Keith Packard wrote: On Tue, 29 Jun 2010 02:18:31 +0200, Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: What i assume but didn't check is that xlib doesn't have a problem with getting replies out of sequence The X protocol is purely sequential -- you can't execute requests out of order (and queuing replies is part of the request execution). In particular, no X library would ever deal with replies being returned out of order; they count on the sequence number from the X server being monotonic. Ok, thanks. That makes live for multi-threaded clients a bit more difficult if they want to use the new extensions, because they would need to maintain multiple x connections, one for each thread, to circumvent this. I guess then xcb doesn't handle this either? Then i think the idea of multiple wait queues doesn't allow to get rid of IgnoreClient(), but we will still need those wait queues in addition to IgnoreClient() to handle multiple blocking requests for one drawable from different clients / x-connections correctly. Right, we have lists in the server now too, so it shouldn't be too hard. The current code assumes exactly one client / x-connection per drawable. I think if we have multiple threads accessing the drawable over separate connections then the current IgnoreClient() method will not work and we will end up with undefined behaviour for some of the new dri2 protocol requests. E.g., what should work according to the spec is that i have multiple threads, each of them using its own dedicated x-connection to perform a glXWaitForSbcOML() or glXWaitForMscOML() or glXSwapBuffers()/ glXSwapBuffersMscOML() call for the same drawable and getting its request retired when the corresponding event happens. Currently random stuff would happen if i tried this. If i remember correctly the first thread making a request would be correctly handled and all other threads would hang forever - their requests would disappear into nirvana. Anyway, this is a separate issue from IgnoreClient(), so i'll discuss it separately with Jesse. Another question: If i have separate x-connections, e.g., one for each drawable and each connection has an opengl rendering context attached to the drawable, then i assume these context still can share state (display lists, shaders, texture objects, fbo's etc.), right? Anything associated with the drawable would be shared, but context specific information would still be separate per thread. Display lists can be shared explicitly, likewise for some of the other objects, so you should be able to get the sharing you want. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
IgnoreClient question
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. Unfortunately the two don't work together. What I'm seeing is this: 1) client gets throttled in DRI2 due to an outstanding set of swaps pending (DRI2ThrottleClient from one of the DRI2 proto requests). IgnoredClientsWithInput should be set with the client fd at this point. 2) server is VT switched away 3) GLX code suspends all GLX clients using IgnoreClient. At this point, IgnoredClientsWithInput is cleared of the client fd. Then when we VT switch back to the server, the suspended client's fd is never serviced, because its input status was lost. IgnoreClient is fairly ancient though, so there's probably some reason for the clear IgnoredClientsWithInput behavior. Any suggestions on how to solve it? Fixing this issue fixes bug #27035. Maybe we could clear it in AttendClient instead, after copying it over to ClientsWithInput? Seems like losing it is the wrong thing to do... Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: IgnoreClient question
On Tue, 29 Jun 2010 02:18:31 +0200, Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: What i assume but didn't check is that xlib doesn't have a problem with getting replies out of sequence The X protocol is purely sequential -- you can't execute requests out of order (and queuing replies is part of the request execution). In particular, no X library would ever deal with replies being returned out of order; they count on the sequence number from the X server being monotonic. -- keith.pack...@intel.com pgplze5O3ArHQ.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: IgnoreClient question
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. Jesse, 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 requests. 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 * Mario Kleiner Max Planck Institute for Biological Cybernetics Spemannstr. 38 72076 Tuebingen Germany e-mail: mario.klei...@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) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: IgnoreClient question
On Jun 29, 2010, at 2:24 AM, Keith Packard wrote: On Tue, 29 Jun 2010 02:18:31 +0200, Mario Kleiner mario.klei...@tuebingen.mpg.de wrote: What i assume but didn't check is that xlib doesn't have a problem with getting replies out of sequence The X protocol is purely sequential -- you can't execute requests out of order (and queuing replies is part of the request execution). In particular, no X library would ever deal with replies being returned out of order; they count on the sequence number from the X server being monotonic. Ok, thanks. That makes live for multi-threaded clients a bit more difficult if they want to use the new extensions, because they would need to maintain multiple x connections, one for each thread, to circumvent this. I guess then xcb doesn't handle this either? Then i think the idea of multiple wait queues doesn't allow to get rid of IgnoreClient(), but we will still need those wait queues in addition to IgnoreClient() to handle multiple blocking requests for one drawable from different clients / x-connections correctly. The current code assumes exactly one client / x-connection per drawable. I think if we have multiple threads accessing the drawable over separate connections then the current IgnoreClient() method will not work and we will end up with undefined behaviour for some of the new dri2 protocol requests. E.g., what should work according to the spec is that i have multiple threads, each of them using its own dedicated x-connection to perform a glXWaitForSbcOML() or glXWaitForMscOML() or glXSwapBuffers()/ glXSwapBuffersMscOML() call for the same drawable and getting its request retired when the corresponding event happens. Currently random stuff would happen if i tried this. If i remember correctly the first thread making a request would be correctly handled and all other threads would hang forever - their requests would disappear into nirvana. Anyway, this is a separate issue from IgnoreClient(), so i'll discuss it separately with Jesse. Another question: If i have separate x-connections, e.g., one for each drawable and each connection has an opengl rendering context attached to the drawable, then i assume these context still can share state (display lists, shaders, texture objects, fbo's etc.), right? thanks, -mario * Mario Kleiner Max Planck Institute for Biological Cybernetics Spemannstr. 38 72076 Tuebingen Germany e-mail: mario.klei...@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) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
