On Thu, Feb 5, 2009 at 3:26 PM, Jim Montine <[email protected]> wrote: > Hi, > > Thanks for the information. Two quick follow-up questions. > > In case 1 below (where the server reads the file and executes filtering > operations but does > no rendering), is it worthwhile to do an mpirun pvserver in this mode? Will > the server do parallel work > in this case?
Yes. Consider doing something like contouring. Each of N processors only has to iterate over only 1/N'th of the cells to contour, so you can expect roughly Nx speedup. However, there are potential bottlenecks, particularly in the reader code, which has to do disk IO efficiently in the first place, and in more complicated filters (streamlines). > > In case 2 below (where the server optionally renders the polygons), why is > it necessary to set the > DISPLAY to the gfx head of the server (things are displayed on the PC) Why > is the DISPLAY environment > needed at all for this off-screen rendering case? > > Does mpirun also have an effect in this case? > Yes. When the data is large enough that paraview is shipping images to the client instead of polygons, you have N processors that use their own graphics cards to process only 1/N'th of the total number of polygons. If the server is not running MPI, or the polygons are being shipped to the client you have only 1 graphics card which has to scan convert all N of the polygons. > ________________________________ > From: David E DeMarle [mailto:[email protected]] > Sent: Thu 2/5/2009 11:20 AM > To: Jim Montine > Cc: [email protected] > Subject: Re: [Paraview] remote rendering with paraview > > On Thu, Feb 5, 2009 at 2:09 PM, Jim Montine <[email protected]> wrote: >> I download and I am running paraview 3.4.0. I run pvserver on a linux >> cluster (where a .cas data file to visualize resides) andI run paraview on >> my Windows laptop. >> >> First I tried running: pvserver --use-offscreen-rendering on the server >> (which has gfx hardware) without setting >> DISPLAY properly. I got a message that the display was not accessible and >> that remote rendering would be >> disabled. I was still able to run paraview on the PC and connect to the >> server and display the model. >> >> 1) In this scenario, is any work at all being done by pvserver, other than >> providing access to the data file? > > Yes. The server reads the file, and executes all of the filtering > operations, which may be extremely processor intensive. Think > arbitrary manipulation of large amounts of data. In the end the > surface extracts the polygonal surface geometry and sends that to the > client to display. > >> >> Next, I set DISPLAY to the gfx head on the server and reran: pvserver >> --use-offscreen-rendering. I got no >> messages this time and I again could connect to the server from the PC and >> display the model on the PC >> inside paraview. >> >> 2. In this scenario, is remote rendering happening on the server? How >> are >> things divided between the pvserver >> and paraview in this case? >> > > This server now does all of the above, and optionally renders the > polygons, producing pixels which are then depth composited and sent to > the client to display. I say optionally because if the geometry is > small enough paraview will simply send that rather than the pixels to > the client and render as above. "Small enough" is controlled via the > Preferences->Render View->Server->Remote Render threshold setting. > >> Finally, I tried running on a server with NO gfx hardware. I set DISPLAY >> to >> be the PC. Again I could >> connect and display the model inside paraview (on the PC) but it runs >> very >> slowly. >> >> 3. What is the correct way to run pvserver on a server with no gfx >> hardware >> and have the server do rendering that is >> then sent to the client? >> >> > See the setting up a server wiki page > http://www.paraview.org/Wiki/Setting_up_a_ParaView_Server. OSMesa is > the recommended solution. > >> Thanks >> _______________________________________________ >> ParaView mailing list >> [email protected] >> http://www.paraview.org/mailman/listinfo/paraview >> >> > > > > -- > David E DeMarle > Kitware, Inc. > R&D Engineer > 28 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-371-3971 x109 > -- David E DeMarle Kitware, Inc. R&D Engineer 28 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-371-3971 x109 _______________________________________________ ParaView mailing list [email protected] http://www.paraview.org/mailman/listinfo/paraview
