On 8/14/12 6:10 PM, marty scholes wrote: > I did the following (with the VBoxTestOGL softlinked to /bin/true) > > bash-4.1$ vglrun -c 0 VirtualBox -startvm "Windows 7 Media" > Segmentation Fault > > Sadly, it passes the VBoxTestOGL test, which claims I have 3D. On a > side note, is this stuff documented? I never knew VBoxTestOGL existed > and cannot find it in the manual. Heck, it's barely in google.
In a word, no. I didn't even know about it until it magically started failing in VBox 4.1.10 -- or rather, from the VirtualBox point of view, it magically started succeeding, which then made VirtualGL magically start failing. > Actually, it wasn't needless. 20 years of coding, from device drivers > to assembly to web apps, and I have *never* pulled a stack trace, much > less tried to read one. I have pasted below the results of "pstack > core" which I assume is the correct way to get a trace. I generally just use dbx, but this works as well. Unfortunately, the stack trace wasn't terribly revealing. It did tell me that it's VirtualBox that is causing the segfault and not VirtualGL. Can you verify that VirtualGL is even loading? Pass +tr to vglrun to get tracing output and verify whether VirtualGL is actually interposing any X11 or GLX calls. One thing to be cognisant of on Solaris is that VirtualBox is a setuid root executable, so you have to add the directory containing librrfaker.so (/opt/VirtualGL/lib/[64], for instance) to the system library path using crle (that, at least, is documented in the VGL User's Guide.) If none of that reveals any new information, I'm out of ideas. > Message: 3 > Date: Mon, 13 Aug 2012 15:06:19 -0500 > From: DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>> > Subject: Re: [VirtualGL-Users] Solaris 11 + SRS 5.3 + VB 4.1 + > VirtualGL 2.3 = Segmentation fault > To: virtualgl-users@lists.sourceforge.net > <mailto:virtualgl-users@lists.sourceforge.net> > Message-ID: <50295e3b.8040...@users.sourceforge.net > <mailto:50295e3b.8040...@users.sourceforge.net>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > There is a known issue with VBox > 4.1.8 and VGL, and the VirtualBox > developers are unfortunately dragging their feet in fixing it. What > happened was that, previous to 4.1.10, the VBoxTestOGL application (on > Linux, this is located in /usr/lib/virtualbox, but I don't know about > Solaris) wasn't really doing anything-- that is, it was always returning > true. When they fixed this application in 4.1.10, suddenly VirtualBox > stopped working with VGL, because the LD_PRELOAD environment variable > was not getting passed down to VBoxTestOGL. > > After examining the VBox code, I believe this is fixable by simply > changing the way the VBoxTestOGL application is executed from within the > VirtualBox executable. I communicated this to the VBox developers. I > also recommended that they allow the VBoxTestOGL application to respond > to the CR_SYSTEM_GL_PATH environment variable (this was, traditionally, > the 'alternate' way of using VirtualGL with VirtualBox, but it hasn't > worked for a while. I'd be happy if even that method of using VGL with > VBox worked again, even if we couldn't launch VirtualBox directly using > vglrun.) > > The current workaround is to rename VBoxTestOGL and symlink /bin/true to > it. I'd try that first and see if that enables VirtualGL and VirtualBox > to run. > > If you are still getting a segfault, try passing an argument of -c 0 to > vglrun. That will force the use of the X11 Transport. The default on > Sun Ray is to use YUV encoding and the VGL Transport if the 3D server > and the Sun Ray server are different machines (in which case, you should > be using vglconnect to connect to the 3D server) or the XV Transport if > they are the same machine. Forcing it to use the X11 Transport will > eliminate the possibility that there is a bug in our YUV encoding or X > Video code. > > Needless to say, a stack trace would also be helpful! > > > On 8/13/12 9:48 AM, marty scholes wrote: >> I am new to the list but hoping someone has seen this before. I have >> somewhat documented my experience in the below VirtualBox forum. >> >>https://forums.virtualbox.org/viewtopic.php?f=11&t=50846&p=233184 >> >> I managed to get all OpenGL apps working under Solaris 11 with Quadro FX >> 1700 using Sun Ray 5.3 and VirtualGL 2.3. The only exception was that >> VirtualBox would crash with a segmentation violation when run under vglrun. >> >> Has anyone experienced this before? Is there someplace I can look for >> pointers and guidance? >> >> Many thanks, >> Marty >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> >> >> >> _______________________________________________ >> VirtualGL-Users mailing list >>VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> >>https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> > > > > ------------------------------ > > Message: 4 > Date: Tue, 14 Aug 2012 22:07:17 +1000 > From: James Wettenhall <james.wettenh...@monash.edu > <mailto:james.wettenh...@monash.edu>> > Subject: [VirtualGL-Users] -quality option on Mac OS X TurboVNC X11 > vncviewer > To: VirtualGL Users <virtualgl-users@lists.sourceforge.net > <mailto:virtualgl-users@lists.sourceforge.net>> > Message-ID: <882f330b-33d3-4fe8-be56-21114b0c6...@monash.edu > <mailto:882f330b-33d3-4fe8-be56-21114b0c6...@monash.edu>> > Content-Type: text/plain; charset=us-ascii > > Hi, > > Does the TurboVNC X11 vncviewer's -quality option work on Mac OS X ? > > I have tried: > > -samp 4x -quality 30 > > which results in the following appearing in the VNC window's title bar: > > [Tight + JPEG 4X Q30] > > but the images look remarkably good - I can't see the same artefacts I > see when using a low image quality quality setting with the Windows > TurboVNC viewer. > > Thanks, > James > > > > > ------------------------------ > > Message: 5 > Date: Tue, 14 Aug 2012 13:56:56 -0500 > From: DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>> > Subject: Re: [VirtualGL-Users] -quality option on Mac OS X TurboVNC > X11 vncviewer > To: virtualgl-users@lists.sourceforge.net > <mailto:virtualgl-users@lists.sourceforge.net> > Message-ID: <502a9f78.7070...@users.sourceforge.net > <mailto:502a9f78.7070...@users.sourceforge.net>> > Content-Type: text/plain; charset=ISO-8859-1 > > It works, but you have to be connecting to a server that supports JPEG > encoding. The built-in VNC server in OS X doesn't, for instance, so > you're probably actually using Hextile or ZRLE. Thus, the titlebar > reflects what you requested, not necessarily what you got. The Java > viewer (and I think the Windows viewer as well) will show you the "most > recent encoding" in their Connection Info dialogs, which tells you > whether the server is honoring your request or not. Unfortunately, > there's not a very straightforward way to make the GUI reflect what the > server is actually sending you, because it is perfectly legal for the > VNC server to ignore all of your requested encodings if it doesn't > support them, and it's also perfectly legal for it to send each > framebuffer update using a different encoding. However, in reality, VNC > servers don't change encodings that frequently, so it seems like it > would be reasonable to have the titlebar reflect the most recent > encoding used, rather than what was requested. > > On 8/14/12 7:07 AM, James Wettenhall wrote: >> Hi, >> >> Does the TurboVNC X11 vncviewer's -quality option work on Mac OS X ? >> >> I have tried: >> >> -samp 4x -quality 30 >> >> which results in the following appearing in the VNC window's title bar: >> >> [Tight + JPEG 4X Q30] >> >> but the images look remarkably good - I can't see the same artefacts I see >> when using a low image quality quality setting with the Windows > TurboVNC viewer. >> >> Thanks, >> James > > > > ------------------------------ > > Message: 6 > Date: Tue, 14 Aug 2012 14:29:23 -0500 > From: DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>> > Subject: Re: [VirtualGL-Users] Inconsistent performance with > glxspheres > To: virtualgl-users@lists.sourceforge.net > <mailto:virtualgl-users@lists.sourceforge.net> > Message-ID: <502aa713.3010...@users.sourceforge.net > <mailto:502aa713.3010...@users.sourceforge.net>> > Content-Type: text/plain; charset=ISO-8859-1 > > VNC is a bit of a tricky beast in terms of performance. Because the > flow is client-controlled (that is, updates are sent only when the > viewer requests them, which it does only when it's free to receive > them), you encounter situations in which the VNC server effectively > spoils frames sometimes and doesn't spoil them other times. Thus, you > can't really rely upon the throughput reported by GLXspheres in this > case. You have to measure the throughput from the client end using > TCBench. That is also tricky, because whenever the VNC server is > cycling like this, its CPU usage will fluctuate wildly, which can affect > its ability to deliver frames to the client. If you're just concerned > with frame rate, then I would suggest just using TCBench-- it should be > accurate enough. If you're interested in measuring things like > per-frame encoding time and the other metrics I typically use when > benchmarking TurboVNC, then the procedure for that is not very pretty > and generally requires an expert's touch. > > What I'm working on right now is porting over the TigerVNC flow-control > extensions. These allow updates to be sent continuously from the > server, but they also introduce a mechanism to prevent those updates > from being sent any faster than the client is able to process them. > Thus, it should be possible to introduce a sort of equivalent to 'vglrun > -sp' in TurboVNC, making it much easier to benchmark. > > Even though you're running without frame spoiling in VirtualGL, when > TurboVNC enters a phase in which it starts spoiling frames, the > GLXspheres frame rate will cease being coupled to the rate of frame > delivery to the client, and thus it will run basically as fast as your > graphics card is able to render and VirtualGL is able to read back and > blit the frames into the VNC server. The reason why glXSwapBuffers() > shows such a high CPU usage is that, when frame spoiling is disabled in > VGL, the 3D rendering thread (that is, the application's main thread in > the case of GLXspheres) is coupled to the blitter thread, so the > XPutImage() call will basically occur before glXSwapBuffers() returns. > > I should also note that, rather than decreasing the window size, you can > also simply decrease the image quality to improve your throughput. > GLXspheres will typically generate ~2 bits/pixel of compressed image > data when using Perceptually Lossless JPEG, ~1 bit/pixel with > Medium-Quality JPEG, and ~0.5 bits/pixel with Low-Quality JPEG, so 15 > Mpixels/sec is about the max you'll see on a 30 Mbps network unless you > decrease the image quality. > > > On 8/13/12 8:34 AM, Leander Koornneef wrote: >> On 13 August 2012 13:55, Leander Koornneef >> <leander.koornn...@clustervision.com > <mailto:leander.koornn...@clustervision.com>> wrote: >>> >>> Hi list! >>> >>> I'm setting up a graphics/visualization server with VirtualGL and am >>> currently testing the setup using the glxspheres(64) application. The server >>> is a Dell Precision R5500 Rack Workstation with two Nvidia Quadro 6000 >>> GPU's, running Scientific Linux 5.8 (x86_64). The VirtualGL/TurboVNC >>> installation seems to be working, but the performance I get with the >>> glxspheres application is rather inconsistent and I don't really have an >>> idea why. When I run 'vglrun -d :0.0 +v -sp +pr +tr >>> /opt/VirtualGL/bin/glxspheres64' it typically starts out rendering around >>> 500fps. Then, after a while, the fps will drop dramatically to only a few >>> per second, like so: >>> >>> 487.153071 frames/sec - 495.941312 Mpixels/sec >>> 383.257436 frames/sec - 390.171400 Mpixels/sec >>> 200.162382 frames/sec - 203.773311 Mpixels/sec >>> 138.313337 frames/sec - 140.808510 Mpixels/sec >>> 1.102129 frames/sec - 1.122012 Mpixels/sec >>> 25.927141 frames/sec - 26.394867 Mpixels/sec >>> 7.162349 frames/sec - 7.291557 Mpixels/sec >>> 18.690150 frames/sec - 19.027321 Mpixels/sec >>> 1.763289 frames/sec - 1.795099 Mpixels/sec >>> 2.448173 frames/sec - 2.492338 Mpixels/sec >>> 1.189486 frames/sec - 1.210945 Mpixels/sec >>> 10.394469 frames/sec - 10.581986 Mpixels/sec >>> 21.496225 frames/sec - 21.884017 Mpixels/sec >>> 11.616107 frames/sec - 11.825661 Mpixels/sec >>> 1.926034 frames/sec - 1.960780 Mpixels/sec >>> 1.843533 frames/sec - 1.876790 Mpixels/sec >>> 1.929879 frames/sec - 1.964694 Mpixels/sec >>> 1.881723 frames/sec - 1.915670 Mpixels/sec >>> 1.944252 frames/sec - 1.979326 Mpixels/sec >>> >>> Sometimes it will go back to >100fps, only to drop back again to single >>> digits soon after. I've looked at the trace output and it seems that an >>> inordinate amount of time (hundreds of milliseconds) is spent in >>> glXSwapBuffers(). I'll attach the trace output to this message. >>> This happens on both Quadro cards and with both the 32-bit and 64-bit >>> glxspheres. I've tried different versions of the nvidia kernel module, but >>> that does not seem make much of a difference, altough the older versions >>> (275.xx) seem to have a much faster startup time. With the 295.xx version >>> module, I typically have to wait around 30 seconds before I get any output >>> at all, whereas with older versions of the module I'll get output after only >>> a few seconds. >>> >>> Now I'm not sure what to do next, so I've come here hoping for some help. >>> I will gladly provide more information if needed. >> >> Replying to my own post here, with apologies for the html in the >> original message. >> >> It seems I may have underestimated the importance of having enough >> bandwidth between the VNC client and server. With the default window >> size of glxspheres (in my case about 1200x900 pixels), the link >> between me and the server (30mbit/s, 30ms roundtrip over 1500 >> kilometers) was pretty much completely saturated straight away. When I >> decrease the size of the window, it happily renders hundreds or even >> thousands of frames per second, depending on the window size. >> >> However, the issue with the slow startup when using the newer nvidia >> module still remains, but I'm not sure if that is even necessarily >> related to VirtualGL? >> >> Best regards, >> Leander >> >> > ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> VirtualGL-Users mailing list >>VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> >>https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> > > > > ------------------------------ > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > ------------------------------ > > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > End of VirtualGL-Users Digest, Vol 61, Issue 7 > ********************************************** > > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
