[Paraview] how to run ParaView 3.4.0 on MacOS Leopard in parallel?

[Karen Lee]

Hi Berk,

Thanks for your help. Our file format is .vtu, and there's only one GPU on
our machine. I'm wondering if there is some way we can tell which operations
execute on the GPU and which on the CPU, so that we could try a different
operation in order to see a parallel speedup.
Also, have you guys looked into having the client and server processes
detect the situation where the GPU is shared between them, and in that case
not attempt to parallelize GPU-based operations? Our situation of a
multi-CPU system with a single GPU is very common, and it would be nice to
get some benefit for CPU-based operations in this case without penalizing
GPU-based ones.

Thanks again for your help,
Karen


On Sat, Jul 4, 2009 at 10:46 AM, Berk Geveci <berk.geveci at kitware.com>wrote:

> Hi Karen,
>
> What file format are you using?
>
> There are a few factors here. First, we have to make sure that the
> file format you are using is suitable for parallel processing - not
> all formats are. Second, if you are using a GPU based algorithm such
> as projected tetrahedra (which is the default), you are likely to see
> a decrease in performance of volume rendering rather than increase.
> This is because all of the processes will be using 1 GPU and the
> resource contention that this causes is likely to make rendering
> slower. Assuming that the data is distributed properly, algorithms
> should run faster though. If you have multiple GPUs, it is also
> possible to make rendering scale to an extent but we haven't
> experimented with multiple GPU on one machine yet.
>
> -berk
>
> On Fri, Jul 3, 2009 at 4:55 PM, Karen Lee<kylkaren at gmail.com> wrote:
> > Hi, thanks for all of your responses.  It looks like the ParaView Guide
> book
> > is out-of-date, as it tells you that the client can be launched directly
> > with "mpirun -np <xx> paraview" as an alternative to running pvserver
> > separately.
> >
> > Now that we are using pvserver, it is partially working.
> >
> > We installed pvserver (in /usr/local/bin), and then used the "Connect"
> > option in the File menu to connect to a server running on "localhost"
> (Add
> > Server, then specifying Client/Server connecting to localhost port 11111,
> > launching pvserver with "/usr/bin/mpirun -np 7 /usr/local/bin/pvserver"),
> > and connected to the server successfully.
> >
> > Unfortunately, using pvserver on the same (8-processor) machine seems to
> be
> > significantly slower and more buggy than running the client by itself (we
> > tried -np 7, and also -np 2), for a fairly large (million-point)
> > unstructured-grid dataset that takes about 20 seconds for volume
> rendering
> > with one processor.  We had thought that this problem would be big enough
> to
> > benefit from at least using a couple of CPUs.
> >
> > When we connect to pvserver on the same machine, it not only takes much
> > longer to render (regardless of the number of CPUs we launch pvserver
> on),
> > but there are also some weird screen artifacts where it seems to open up
> a
> > second rendering window (with no controls or window decorations, just a
> > square with a duplicate of the rendering contents) that we cannot get rid
> > of.  At that point the program freezes.
> >
> > Any suggestions?  We are using the precompiled paraview 3.4.0 from the
> > paraview web site, compiled for MacOS Leopard/Intel, running on an 8-cpu
> > MacPro with 16GB of RAM.
> >
> > Thanks,
> > Karen Lee
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the ParaView Wiki at:
> > http://paraview.org/Wiki/ParaView
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.paraview.org/mailman/listinfo/paraview
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20090705/acecad80/attachment.htm>