Hi Rich,<br><br>I think the Mesa driver is installed by default on most linux distos today (maybe not?), but the proprietary hardware drivers take priority when installed and enabled. You can configure X11 (or uninstall your nvidia driver or whatever you may have), so that the mesa driver will kick in. If you run "glxinfo | grep vendor" then you'll either see the name of your enabled proprietary driver vendor, or you'll see Mesa. This is a system configuration thing, which driver is being used does not affect ParaView, it's invisible to ParaView (except ParaView might query for and use vendor specific extensions that are only available in the proprietary driver).<br>
<br>On ubuntu there are two packages: libgl1-mesa-swx11 and libgl1-mesa-glx. I think that the mesa-swx11 is used more infrequently, it is a pure software implementation while the mesa-glx packages actually uses hardware acceleration for it's drawing- <a href="http://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure">http://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure</a><br>
<br>OSMesa is different because it has a specific API that you have to code to and link your program to the OSMesa library.<br><br>Pat<br><br><div class="gmail_quote">On Tue, Oct 9, 2012 at 1:52 PM, Cook, Rich <span dir="ltr"><<a href="mailto:cook47@llnl.gov" target="_blank">cook47@llnl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
Very interesting. Brian Paul is everywhere! :-)
<div>I have a question, however. You say that one can use Mesa X11 rendering (as opposed to OSMesa rendering). How would that be done? The only mesa rendering I'm aware of is OSMesa. What is this "Mesa OpenGL driver" which renders in software but is not
OSMesa? </div>
<div>Thanks </div><span><font color="#888888">
<div>-- Rich </div>
</font></span><div><div><div><br>
<div>
<div>On Oct 9, 2012, at 6:28 AM, Pat Marion wrote:</div>
<br>
<blockquote type="cite">Hi Rich,<br>
<br>
I totally agreee with you, I find it very confusing that there is a compile time flag VTK_USE_OFFSCREEN, and a runtime flag --use-offscreen-rendering, and an OSMesa compile flag VTK_OPENGL_HAS_OSMESA. I think that the options could be presented in a way that
makes it more clear what is happening.<br>
<br>
I want to clarify some things here. There are actually several very different concepts that are all kinda mixed up by the way that VTK presents the options:<br>
<br>
1) hardware accelerated rendering vs. software rendering<br>
2) regular rendering vs. offscreen rendering vs. OSMesa rendering<br>
<br>
Just saying "offscreen rendering" is totally not specific enough to have any idea what is really happening under the hood, a lot of people assume different things when they hear "offscreen rendering", and I think that's where the problem is.<br>
<br>
First, hardware vs. software rendering. If you use the Mesa OpenGL driver (not to be confused with the OSMesa library!), you are using software rendering. But, the mesa driver renders into a buffer that is owned by the operating system and window manager
(X11). So you are using a software implementation of OpenGL, but rendering "on screen", and you depend on X11 APIs and an X server. If you have a GPU, then you can use a hardware driver, and similarly you depend on X11. You can switch between a hardware
driver and a Mesa driver without recompiling any software.<br>
<br>
Second, regular rendering vs. offscreen rendering. Here is an old, but very informative, article on the many different implementations of offscreen rendering:
<a href="http://www.mesa3d.org/brianp/sig97/offscrn.htm" target="_blank">http://www.mesa3d.org/brianp/sig97/offscrn.htm</a><br>
Note that Mesa offscreen rendering, OSMesa, is just one of many different offscreen rendering APIs described in the article. You can do hardware accelerated offscreen rendering, and that is totally different from OSMesa. For example, using X11, you can render
into a GLX pixmap. A GLX pixmap is a render buffer that is not associated with a window, it is "offscreen", but the rendering uses your GL driver, which could be a hardware accelerated driver or a Mesa software driver, but not OSMesa.<br>
<br>
Finally, there is OSMesa. It uses Mesa software rendering, and renders into a special OSMesa buffer. Using OSMesa, you have zero dependency on X11. You don't need X11 at build time or at run time. Here's more information about OSMesa:
<a href="http://www.mesa3d.org/osmesa.html" target="_blank">http://www.mesa3d.org/osmesa.html</a><br>
<br>
So, in summary,<br>
<br>
-you can use a GPU or Mesa (not OSMesa) and do on screen rendering into an X11 window.<br>
-you can use a GPU or Mesa (not OSMesa) and do offscreen rendering into an X11 managed offscreen buffer.<br>
-you can use OSMesa for software rendering without any dependency on X11.<br>
<br>
For MPI cluster runs of paraview, the two most common configurations are GPU with X11, or OSMesa without X11. If you didn't have a GPU on your nodes, you might also use Mesa with X11, but render on screen.<br>
<br>
If you grep VTK source code for "OSMESA", you will find multiple confusing flags, VTK_OPENGL_HAS_OSMESA and VTK_USE_OSMESA, and lots of confusing code to decide whether or not we want to use on screen or offscreen rendering with gpu, or OSMesa rendering. If
VTK is truly compiled for OSMesa, it means that ldd pvserver lists only OSMesa and no X11 or OpenGL dependencies. When you have compiled with OSMesa, the --use-offscreen-rendering flag can be completely ignored, VTK will always use OSMesa.<br>
<br>
I think the --use-offscreen-rendering flag is mostly for switching between on screen and offscreen while still using a regular GL driver, and I'm really not sure if anybody actually uses that feature, I certainly have not. To make things even more confusing,
in ParaView there is a preferences setting for "Use offscreen rendering for screenshots". Ouch.<br>
<br>
<br>
Hope this helps!<br>
<br>
Pat<br>
<br>
p.s. If anybody has corrections, please let me know!<br>
<br>
<br>
<div class="gmail_quote">On Mon, Oct 8, 2012 at 2:23 PM, Burlen Loring <span dir="ltr">
<<a href="mailto:bloring@lbl.gov" target="_blank">bloring@lbl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Rich,<br>
<br>
if you are installing on cluster, I would say that it's easier to use an MPI build. Of course when you build with MPI support you need to launch pvserver with mpirun (or the system equivalent). When you need a serial run just specify -n 1. You may be aware
that, providing a server config will let your users select the number of mpi ranks and the "layout" of mpi ranks across cluster nodes from ParaView's GUI. ParaView should run on any number of mpi ranks. When you say you're running in serial, are you using
the mpirun command? what errors/complaints are you experiencing?<br>
<br>
My recollection, is that the --use-offscreen-rendering is used to select between osmesa open gl and the system open gl when both are used in the same build. I haven't built ParaView this way in many years, hence my recollection is fuzzy. On the other hand,
if you have two builds, one built with osmesa and the other using a system provided hardware accelerated open gl, this command line flag is not necessary.<span><font color="#888888"><br>
<br>
Burlen</font></span>
<div><br>
<br>
On 10/08/2012 10:21 AM, Cook, Rich wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Are you assuming we are always running in parallel on the cluster? I find that Paraview for some reason complains when run in serial if you compile it with MPI. So currently I'm doing four builds, opengl, osmesa, opengl-mpi, osmesa-mpi. It's a PITA but now
it's all automated. Still I think it's confusing for our users.<br>
<br>
I'm also personally unsure about where there is a switch for "--use-offscreen-rendering." If I compile with OSMesa, I'm always going to want that, right? And if OpenGL, I'm always going to disable that, right? Why is there a command line switch for that?<br>
<br>
It does sound like yes, pvservers will render to graphics cards in parallel so that's good to know.<br>
<br>
Thanks!<br>
-- Rich<br>
<br>
On Oct 6, 2012, at 7:16 PM, Burlen Loring wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Rich,<br>
<br>
You're always going to want to build with MPI when running on a cluster. Leveraging your cluster's graphics cards comes down to building with or without os mesa. you probably want to provide both builds, and select the build to run depending on whether the
user has requested nodes that contain graphics cards or not. Hardware accelerated rendering can be faster than software based rendering depending on the amount of contention there is for the graphics card. eg 16 mpi ranks hitting the same card will likely
be slower than 16 cpu cores running os mesa. When submitting a job you could always control this by limiting the number of mpi ranks per graphics card. Also, some rendering algorithms, such as surface LIC, are disabled when using os mesa. it's nice to have
the hardware accelerated build in order to access the other algorithms when you need them.<br>
<br>
Burlen<br>
<br>
On 10/1/2012 5:05 PM, Cook, Rich wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We have large clusters and some of them have graphics cards on them. Most don't. So normally I expect to be using -DVTK_USE_OFFSCREEN:BOOL=ON -DPARAVIEW_USE_MPI:BOOL=ON with cmake.<br>
I got to thinking. First, if I compile with -DVTK_USE_OFFSCREEN:BOOL=ON then why do I have to use --use-offscreen-rendering to launch the pvservers. Secondly, can pvservers render to graphics cards for distributed rendering under MPI? If so, does it make
sense to do -DVTK_USE_OFFSCREEN:BOOL=OFF -DPARAVIEW_USE_MPI:BOOL=ON ??<br>
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
</div>
<div>
<div>______________________________<u></u>_________________<br>
Powered by <a href="http://www.kitware.com/" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">
http://www.kitware.com/<u></u>opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the ParaView Wiki at: <a href="http://paraview.org/Wiki/ParaView" target="_blank">
http://paraview.org/Wiki/<u></u>ParaView</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.paraview.org/mailman/listinfo/paraview" target="_blank">http://www.paraview.org/<u></u>mailman/listinfo/paraview</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
<br>
</div></div><div><div><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:13px;white-space:normal;font-family:Monaco;word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:13px;white-space:normal;font-family:Monaco;word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:13px;white-space:normal;font-family:Monaco;word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:13px;white-space:normal;font-family:Monaco;word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:13px;white-space:normal;font-family:Monaco;word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:13px;white-space:normal;font-family:Monaco;word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:13px;white-space:normal;font-family:Monaco;word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:13px;white-space:normal;font-family:Monaco;word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:13px;white-space:normal;font-family:Monaco;word-spacing:0px">
<div>-- </div>
<div>✐Richard Cook </div>
<div>✇ Lawrence Livermore National Laboratory</div>
<div>Bldg-453 Rm-4024, Mail Stop L-557 </div>
<div>7000 East Avenue, Livermore, CA, 94550, USA</div>
<div>☎ (office) <a href="tel:%28925%29%20423-9605" value="+19254239605" target="_blank">(925) 423-9605</a> </div>
<div>☎ (fax) <a href="tel:%28925%29%20423-6961" value="+19254236961" target="_blank">(925) 423-6961</a></div>
<div>---</div>
<div>Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept.</div>
<div>(opinions expressed herein are mine and not those of LLNL)</div>
<br>
</span></span></span></span></span></span></span><br>
</span></span></div>
<br>
</div></div>
</div>
</blockquote></div><br>