Several things clicked in my head whenever I saw the output from GLXinfo. Your 3D X server is on display :20, which tells me that it's probably not the "root" X server (sorry if I missed that before.) If there are multiple 3D X servers running on the machine, then you have to either:
-- make sure that the X server you want to use as the 3D X server is "active"-- that is, make sure that its output is visible and that it is receiving keyboard/mouse input ... or ... -- configure the X server that you want to use as the 3D X server to be "headless" by adding Option "UseDisplayDevice" "none" to the "Device" section of xorg.conf. The OpenGL error you're getting is the same error you would get if the server was switched to one of the text consoles (using CTRL-ALT-F1, F2, etc. on Red Hat) instead of the X server (CTRL-ALT-F7 on Red Hat). On 9/5/14 7:36 AM, Ladislaus Dombrowski wrote: > I've included the output from glxinfo in the attached file. > > The machines are using version 2.3.3. I will upgrade them both to 2.4 > beta and see if that helps. > > I'll reread the background document and see if it sinks in better this > time. > > $ /opt/VirtualGL/bin/glreadtest > > GLreadtest v2.3.3 (Build 20131014) > > /opt/VirtualGL/bin/glreadtest -h for advanced usage. > FB Config = 0x111 > Pbuffer size = 701 x 701 pixels > Using 1-byte row alignment > >>>>>>>>>>> PIXEL FORMAT: LUM <<<<<<<<<< > glDrawPixels(): 714.3 Mpixels/sec > glReadPixels(): 1.044 Mpixels/sec (min = 1.025, max = 1.054, sdev = > 0.01391) > glReadPixels() accounted for 99.98% of total readback time > >>>>>>>>>>> PIXEL FORMAT: RED <<<<<<<<<< > glDrawPixels(): 303.2 Mpixels/sec > glReadPixels(): 454.4 Mpixels/sec (min = 142.8, max = 471.1, sdev = 15.73) > glReadPixels() accounted for 99.98% of total readback time > >>>>>>>>>>> PIXEL FORMAT: BGRA <<<<<<<<<< > glDrawPixels(): 304.5 Mpixels/sec > glReadPixels(): 498.6 Mpixels/sec (min = 209.1, max = 505.0, sdev = 17.80) > glReadPixels() accounted for 99.98% of total readback time > >>>>>>>>>>> PIXEL FORMAT: ABGR <<<<<<<<<< > glDrawPixels(): 304.6 Mpixels/sec > glReadPixels(): 498.9 Mpixels/sec (min = 148.9, max = 504.5, sdev = 16.64) > glReadPixels() accounted for 99.98% of total readback time > >>>>>>>>>>> PIXEL FORMAT: BGR <<<<<<<<<< > glDrawPixels(): 303.5 Mpixels/sec > glReadPixels(): 464.7 Mpixels/sec (min = 145.0, max = 472.1, sdev = 15.52) > glReadPixels() accounted for 99.98% of total readback time > >>>>>>>>>>> PIXEL FORMAT: RGBA <<<<<<<<<< > glDrawPixels(): 302.2 Mpixels/sec > glReadPixels(): 395.0 Mpixels/sec (min = 195.2, max = 400.2, sdev = 12.70) > glReadPixels() accounted for 99.99% of total readback time > >>>>>>>>>>> PIXEL FORMAT: RGB <<<<<<<<<< > glDrawPixels(): 301.2 Mpixels/sec > glReadPixels(): 351.8 Mpixels/sec (min = 197.5, max = 355.5, sdev = 9.818) > glReadPixels() accounted for 99.99% of total readback time > > > > > On Thu, Sep 4, 2014 at 4:11 PM, DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>> wrote: > > > These are the assumptions I'm making from the above behavior. > > There is an X Server running on machine 1. > > When I log into machine 1, it gets attached to my DISPLAY. > > When I log into machine 1 through TurboVNC from machine 2, the X Server > > is not getting attached to that DISPLAY. > > Incorrect. The X server on Machine 1 will *never* get "attached" when > you are logging in remotely. What you are probably observing is that, > when you log in with SSH, the X11 traffic is forwarded from Machine 1 to > Machine 2 through the SSH connection. Thus, on the remote machine, the > DISPLAY environment in the SSH session will be set to the remote end of > the X11/SSH tunnel, which may be something like localhost:10.0 or > whatever. This is *not*, however, pointing to the 3D X server running > on Machine 1. In fact, it is pointing to the X server on Machine 2, and > when you run an X11 application in that SSH session, the application > will send all 2D and 3D rendering over the network through the SSH > tunnel, and Machine 2's X server will do the rendering. That isn't what > you want, and I refer you to the extensive background article on > VirtualGL to explain why. > > > > I realize this is where my wording is falling short. Why doesn't the X > > Server get attached to the DISPLAY that is set up by the TurboVNC > > vncviewer application? Is this a setting in the TurboVNC > > vncviewer/vncserver application? The only reason that 'glxgears' > > As I said, you need VirtualGL to act as a bridge between the 2D X server > and the 3D X server. It appears that you are running VirtualGL > correctly in your TurboVNC session, but it isn't working properly on > your system for some reason. To help me diagnose why, please run the > following on Machine 1's X server and attach the output: > > /opt/VirtualGL/bin/glxinfo -c > /opt/VirtualGL/bin/glreadtest > > Also specify what version of VirtualGL you are using. If it's not 2.4 > beta, please try upgrading to 2.4 beta and see if that fixes the > problem. > > > On 9/4/14 2:56 PM, Ladislaus Dombrowski wrote: > > Thanks, I appreciate you putting up with me. > > > > I agree, my wording is very inaccurate. In general, I program > > applications on top of systems, but I've been tasked to set up > > TurboVNC/virtualgl so here goes. Please forgive me for using incorrect > > terms, I'll try my best. > > > > Machine 1 has TurboVNC and VirtualGL installed. > > > > Machine 2 has TurboVNC and VirtualGL installed. > > > > From machine 2, I ssh -X and run 'opt/TurboVNC/bin/vncserver' on > > machine 1 (my account) > > I write down the number I get from that, let's say '5' > > > > From machine 2, I run '/opt/TurboVNC/bin/vncviewer' > > with the name of machine 1 + the number I received from the ssh command > > in this case '5' > > > > In the TurboVNC desktop that shows up on machine 2, I open a terminal > window > > Typing 'printenv DISPLAY' yields :2.0 > > > > I type 'glxgears' and get: > > > > Xlib: extension "GLX" missing on display ":2.0". > > Error: couldn't get and RGB, Double -buffered visual > > > > I type 'vglrun glxgears' and get: > > > > Running synchronized to the vertical refresh. The framerate should be > > approximately the same as the monitor refresh rate. > > [VGL] ERROR: OpenGL error 0x0502 > > [VGL] ERROR: in readpixels--- > > [VGL] 439: Could not read pixels > > > > I log on to machine 1 (same user) > > I run 'glxgears' > > I get a small window with 3 rotating gears > > > > I run 'vglrun gears' and I get: > > > > Running synchronized to the vertical refresh. The framerate should be > > approximately the same as the monitor refresh rate. > > [VGL] ERROR: OpenGL error 0x0502 > > [VGL] ERROR: in readpixels--- > > [VGL] 439: Could not read pixels > > > > On machine 1, I ask for the DISPLAY number - 'printenv DISPLAY' > > I get :17.0 > > > > On machine 2, I run 'vglrun glxgears' > > I get: > > > > Running synchronized to the vertical refresh. The framerate should be > > approximately the same as the monitor refresh rate. > > [VGL] ERROR: OpenGL error 0x0502 > > [VGL] ERROR: in readpixels--- > > [VGL] 439: Could not read pixels > > > > > > On machine 2, I run 'vglrun -d :17.0 glxgears' > > I get a small window with 3 rotating gears > > > > I log out of machine 1 and the small window with 3 rotating gears goes > > away from machine 2 > > > > On machine 2, I run vglrun glxgears > > I get: > > > > Running synchronized to the vertical refresh. The framerate should be > > approximately the same as the monitor refresh rate. > > [VGL] ERROR: OpenGL error 0x0502 > > [VGL] ERROR: in readpixels--- > > [VGL] 439: Could not read pixels > > > > > > These are the assumptions I'm making from the above behavior. > > There is an X Server running on machine 1. > > When I log into machine 1, it gets attached to my DISPLAY. > > When I log into machine 1 through TurboVNC from machine 2, the X Server > > is not getting attached to that DISPLAY. > > > > I realize this is where my wording is falling short. Why doesn't the X > > Server get attached to the DISPLAY that is set up by the TurboVNC > > vncviewer application? Is this a setting in the TurboVNC > > vncviewer/vncserver application? The only reason that 'glxgears' > > spinning gears window appears on machine 2 TurboVNC desktop is because > > by using '-d :17.0', I'm connecting to the X Server associated with the > > DISPLAY number I got from logging into machine 1. When I logged out of > > machine 1, the DISPLAY process associated with that login (:17.0) was > > killed, hence the 'vglrun -d :17.0 glxgears' process no longer had > > anything to connect to. > > > > Do I have this correct or am I still missing the boat. > > > > Lad > > > > > > On Thu, Sep 4, 2014 at 2:58 PM, DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net> > > <mailto:dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>>> wrote: > > > > Your question doesn't make sense, which means that either you aren't > > choosing your words correctly or you still don't understand how the > > system is supposed to work. What do you mean by "running"? The 3D > X > > server is completely independent of TurboVNC. They are different X > > servers. VirtualGL is the bridge between the two. The 3D X server > has > > to be running if you are using VirtualGL. It does not have to be > > running if you are using TurboVNC without VirtualGL. > > > > On 9/4/14 11:41 AM, Ladislaus Dombrowski wrote: > > > I agree the 3D X server is always running. That was why I was > supprised > > > that remotely logging in I don't get the 3D X server > functionality. I > > > only used the -d option to hijack the 3D X server functionality > from > > > another display. What I can't figure out is why the 3D X server > runs > > > when you log in directly to the machine, but doesn't run when you > log in > > > remotely with TurboVNC. > > > > > ------------------------------------------------------------------------------ > > Slashdot TV. > > Video for Nerds. Stuff that matters. > >http://tv.slashdot.org/ > > _______________________________________________ > > VirtualGL-Users mailing list > >VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > > <mailto:VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net>> > >https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > > > > > > > ------------------------------------------------------------------------------ > > Slashdot TV. > > Video for Nerds. Stuff that matters. > >http://tv.slashdot.org/ > > > > > > > > _______________________________________________ > > VirtualGL-Users mailing list > >VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > >https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > > > > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
