One thing I'm curious about is how you were able to get Mesa and VirtualGL to work together. Mesa doesn't support Pbuffers, AFAIK.
On 7/18/11 7:47 AM, Mark Howison wrote: > Here are the FB configs that it is grabbing when I use :0.0 > > visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav drw > id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat typ > > -------------------------------------------------------------------------- > > 0x7d 0 tc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 0 0 None PXW > > and when I use :0.1 (we have two M2050s) > > 0xb0 0 tc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 0 0 None PX > > Are either of these static gray? I don't know how to interpret the > different fields in this list. It seems strange that they are different, > and that one has an "a" (alpha channel?) and the other doesn't. > > We also see these null values in the dlopen calls (and no open of > NVIDIA's libGL.so?): > > 987 [VGL] dlopen (filename=NULL flag=257 retval=0x2aabf0398000) > 988 [VGL] dlopen (filename=NULL flag=1 retval=0x2aabf0398000) > 989 [VGL] dlopen (filename=/lib64/libc.so.6 flag=1 retval=0x2aabf1773000) > 990 [VGL] dlopen (filename=/lib64/libdl.so.2 flag=1 > retval=0x2aabf03993d0) > 991 [VGL] dlopen (filename=/lib64/libpthread.so.0 flag=1 > retval=0x2aabf1fdb4c8) > 992 [VGL] dlopen (filename=libnvidia-tls.so.260.19.29 flag=1 > retval=0x2aabf21f75e8) > 993 [VGL] dlopen (filename=NULL flag=1 retval=0x2aabf0398000) > 994 [VGL] dlopen (filename=libc.so.6 flag=1 retval=0x2aabf1773000) > > I don't know if they are relevant. > > Thanks for your help, > > Mark > > On Jul 15, 2011, at 5:44 PM, DRC wrote: > >> It's possible that, for whatever reason, it's not giving you a visual >> with a depth buffer. You can use 'vglrun +tr' and examine the trace >> output to see what FB config ID is being mapped to the X visual whenever >> the application calls glXCreateContext(), then you can run >> '/opt/VirtualGL/bin/glxinfo -c' on display :0 (or whatever display >> you're using as your 3D X server) to see what attributes that FB >> config has. >> >> I just checked in a fix yesterday which works around an issue whereby, >> under rare and somewhat hard-to-define circumstances, the nVidia GLX >> client library would return a bizarre 128-bit StaticGray FB config >> whenever VirtualGL tried to call glXChooseFBConfig() to obtain an FB >> config for one of its Pbuffers. The workaround is currently in the CVS >> head and 2.2 stable branch (tag "stablebranch_2_2") if you want to try >> it out. >> >> As far as performance, I'll give my standard spiel on that: >> >> VirtualGL's default behavior is to spoil frames so that, in interactive >> applications, the 3D rendering on the server will keep pace with user >> interaction. Thus, as long as a sufficient frame rate (typically 15-20 >> fps or above) is maintained so that the human eye doesn't perceive the >> frame changes, then the application will "feel local". There are >> definite exceptions to this, such as immersive environments in which a >> higher frame rate has to be maintained to avoid nausea, but what I'm >> referring to is the normal case of running desktop 3D applications. In >> fact, with frame spoiling, applications are still quite usable even >> below 15 fps-- although you will be able to perceive the frames change, >> the rendering still keeps pace with your mouse movements. >> >> It is precisely this frame spoiling mechanism, however, that makes >> benchmarks meaningless in a VirtualGL environment, so frame spoiling >> must be disabled (via 'vglrun -sp') when running benchmarks. Otherwise, >> the benchmark is going to be running nearly unimpeded on the server, but >> only a very small percentage of those frames will actually make it to >> the client. In an interactive application, the frame rate is gated by >> the speed of user interaction, so letting the 3D app run unimpeded >> doesn't really tell you anything useful. >> >> Once frame spoiling is disabled, then you can use a 3D benchmark to >> measure the frame rate of the entire VGL system. It's important to >> understand what you're measuring, though. Since VGL is a pipeline, 3D >> rendering and pixel readback occur in parallel to compression and >> transmission on the server, so in most cases, the compression will be >> the primary bottleneck limiting the frame rate (depending on the client, >> you may find that decompression is the bottleneck instead. And, on slow >> networks, the network can become the bottleneck.) However, I >> re-emphasize that you can't simply hold this up next to local rendering >> and say "local is 100 fps, but VirtualGL is only 40 fps, thus local is >> better." It's an apples-to-oranges comparison. Because of frame >> spoiling, VGL will feel local, even though the actual number of frames >> being drawn in front of the user is not as high as the local case. It >> goes without saying, also, that pretty much anything higher than 60 fps >> has no meaning, either, since that exceeds the refresh rate of most >> monitors. >> >> Thus, the notion of benchmarks in a VirtualGL environment is a bit >> different. Typically, people run 3D benchmarks so they can attempt to >> quantify whether 3D rendering will become a bottleneck to user >> interaction. In VirtualGL, however, 3D rendering is usually not the >> bottleneck, so you have to have an understanding of what the other >> likely bottlenecks are in order to get meaningful data out of the >> benchmarks. You also have to really examine the user's experience, >> which is harder to quantify. We have some tools, such as TCBench (which >> measures the frame rate as seen on the client), which can be helpful >> there. It's unavoidable, however, that nebulous concepts such as >> "perceptual performance" come into the conversation. >> >> Further, GLXGears is a horrible benchmark to use under any >> circumstances. It has a very low triangle count and a small window >> size, so its execution time is dominated by overhead rather than actual >> OpenGL rendering time. Even when running locally, the numbers it >> generates have little correlation to actual 3D performance. In a >> VirtualGL environment, the images it generates are not complex enough to >> really give the JPEG compressor a workout (too much solid color, and >> most of the window is static from frame to frame.) >> >> That's why we have GLXSpheres. GLXSpheres generates more complicated >> images, with a more realistic percentage of change between frames as >> well as a more realistic use of color. It also defaults to a somewhat >> larger geometry, and you can increase the number of triangles even >> further via command line options to simulate the types of geometry >> workloads you may encounter in a real-world application. It has other >> features designed specifically to give VirtualGL a workout. >> >> Try comparing, for instance, >> >> vglrun -sp /opt/VirtualGL/bin/glxspheres -p 1000000 >> >> vs. running >> >> /opt/VirtualGL/bin/glxspheres -p 1000000 >> >> in Mesa, and I think you'll find that the difference between VirtualGL >> and Mesa is a lot more than 4x. :) >> >> >> On 7/15/11 12:51 PM, Mark Howison wrote: >>> Hi, >>> >>> We've been trying to install VirtualGL with TurboVNC on our GPU >>> cluster that uses NVIDIA M2050 cards. We can successfully run >>> glxgears through vglrun, access the pbuffer, etc. but we see these >>> strange artifacts around the triangles, like in the attached >>> screenshot. If you zoom in, it looks as if the borders of the >>> triangles aren't being rasterized correctly. This happens both when >>> we use the NVIDIA OpenGL driver and with MESA. >>> >>> Do you have any ideas what might be causing this? We have all of this >>> installed on a stripped-down CentOS image, with some libraries >>> provided over a parallel file system, so this is by no means a >>> standard environment. >>> >>> Also, we are seeing frame rates for glxgears in the 1100-1200 FPS >>> range. Does that sound like reasonable performance? With MESA, we get >>> more like 250 FPS (dual quad-core Nehalems). >>> >>> Thanks, >>> >>> Mark Howison >>> Application Scientist >>> Center for Computation & Visualization >>> Brown University >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> AppSumo Presents a FREE Video for the SourceForge Community by Eric >>> Ries, the creator of the Lean Startup Methodology on "Lean Startup >>> Secrets Revealed." This video shows you how to validate your ideas, >>> optimize your ideas and identify your business strategy. >>> http://p.sf.net/sfu/appsumosfdev2dev >>> >>> >>> >>> _______________________________________________ >>> VirtualGL-Users mailing list >>> VirtualGL-Users@lists.sourceforge.net >>> <mailto:VirtualGL-Users@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >> >> ------------------------------------------------------------------------------ >> AppSumo Presents a FREE Video for the SourceForge Community by Eric >> Ries, the creator of the Lean Startup Methodology on "Lean Startup >> Secrets Revealed." This video shows you how to validate your ideas, >> optimize your ideas and identify your business strategy. >> http://p.sf.net/sfu/appsumosfdev2dev >> _______________________________________________ >> VirtualGL-Users mailing list >> VirtualGL-Users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > ------------------------------------------------------------------------------ > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video shows you how to validate your ideas, > optimize your ideas and identify your business strategy. > http://p.sf.net/sfu/appsumosfdev2dev > > > > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users ------------------------------------------------------------------------------ Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
