Well, your original question was regarding a client limit on the 3D X server, not the 2D X server. While VirtualGL is only opening one connection per process to the 3D X server, on the 2D X server it will open as many as 3 connections per 3D window. This is done in order to support pipelined drawing-- that is, so that a separate thread can draw the image while another thread is either rendering it (X11 Transport) or decoding it (VGL Transport.) But the assumption is that only one user will be using the 2D X server (whereas the 3D X server is shared by multiple users), and generally that one user will only be running one or two apps at a time on their 2D X server.
I observe with TurboVNC that your script starts to fail after about 28 instances. That still seems low, because each GLXgears instance should only be using a maximum of 4 2D X server connections (1 for the app itself, and up to 3 for VirtualGL.) Unfortunately, I observe that xlsclients is useless for detecting VirtualGL connections. Not sure why. I can tell you that there are plenty of shops out there with 40 or 50 simultaneous users banging on a VirtualGL server, often leaving their 3D app sessions running in TurboVNC all the time, and they haven't complained about running out of X11 connections yet, so it is minimally a rare occurrence. If necessary, I could modify the X11 Transport such that only 1 connection is used if VGL_SYNC is specified. VGL doesn't do that currently for expedience and because VGL_SYNC is kind of a "last resort" setting (it will never perform very well, since it is disabling all pipelining and frame spoiling.) On 12/6/13 8:27 AM, Kevin Van Workum wrote: > Not sure what happened. I don't think it was due to the application > misbehaving because for example, I could only start a single instance of > glxgears. Starting a second produced the same errors. Also " xlsclients > -d :0 | wc -l" showed 0 clients connected, even with 1 glxgears window > running. After upgrading my video driver and restarting Xorg, it seems > to be fine. So I guess the problem was in the X server. The server had > been running for about 2 months, so maybe something got screwed up over > time. I've added '-terminate' to the server's init script hoping to > prevent the issue in the future. > > This issue lead me to test exactly how many 3D windows I could open at > once. So I ran a script to see: > > for i in `seq 1 24`; do > glxgears >& /dev/null & > sleep 1 > done > > Turns out that the max is 17 instances of glxgears. On starting the > 18'th instance, I get: > > [VGL] ERROR: Could not send data to client. Client may have disconnected. > [VGL] ERROR: in send-- > [VGL] 399: Broken pipe > > So I guess the limit is in vglclient. However 17 should be more than > enough. > > > > On Thu, Dec 5, 2013 at 5:28 PM, DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>> wrote: > > VirtualGL only opens one connection to :0 (or the specified 3D X server) > the first time XOpenDisplay() is called, and it reuses that same > connection for all subsequent 3D operations. Thus, VirtualGL is only 1 > "client" from the 3D X server's point of view. I think Xorg can have a > max. of 256. > > Minimally, this appears to be due to an ill-behaved application, > although it might be possible to work around it if I knew more about the > underlying cause. > > Googling > maximum number of clients reached x11 > > reveals this page > > http://www.linuxquestions.org/questions/slackware-14/x11-maximum-number-of-clients-reached-864156/ > which has some potentially useful command lines that you might be able > to use to further diagnose where all of the X11 connections are > coming from. > > > On 12/5/13 2:49 PM, Kevin Van Workum wrote: > > I'm trying to run Visit (https://wci.llnl.gov/codes/visit/) and am > > getting the following error: > > > > Maximum number of clients reached[VGL] ERROR: Could not open display :0. > > > > Visit tries to open several windows of which I guess at lease two are > > trying to connect to :0. Is there a way around this? > > > > -- > > Kevin Van Workum, PhD > > Sabalcore Computing Inc. > > "Where Data Becomes Discovery" > >http://www.sabalcore.com > > 877-492-8027 ext. 11 > > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > -- > Kevin Van Workum, PhD > Sabalcore Computing Inc. > "Where Data Becomes Discovery" > http://www.sabalcore.com > 877-492-8027 ext. 11 > > > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > > > > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
