[Paraview] parallel rendering is slower than single process rendering and when using D3 filter it becomes much more slower

Chuck Atkins chuck.atkins at kitware.com
Sat Dec 24 08:41:57 EST 2016


>
> The dataset is polydata, so I use D3 filter to redistribute it among the 8
> processes.
>
D3 is an expensive operation but when the data starts of as a single
partition, there's not a whole lot of other options for re-distributing
it.  When the data is genereated, is it in a single partition or do you
combine it into one before vistualizing?  If it's generated in parallel
then opening the data in it's still-parallel state with ParaView  will let
you avoid the repartitioning and re-distribution step.

To my disappointment, it takes almost 3 times of the rendering time of
> single process rendering!
>
The rendering step alone or the combined D3 + rendering?


> I'm sure there are 8 cores in my rendering server, and the remote render
> threshold is 20 MB.  Could you tell me why the parallel rendering is so
> slow and how I can make it faster? Should'n it be faster than single
> process rendering?
>
In general yes, but it depends on a few factors, one of which is the
structure of the input data and how well it's partitioned.  in your case,
it's not partitioned at all and required repartitioning with D3, which is
very expensive.  Are you rendering with a GPU or are you rendering in
software using OSMesa?

By the way, I'm using ParaView 4.4.0 and the operating system is CentOS 6.3.
>
I would strongly suggest using 5.2 since the newer OpenGL backend used by
5.x is anywhere from 10x to 100x faster for most workloads.  If you're
using CPU based rendering with OSMesa, then you should also look at
building against a new Mesa, i.e 13.0.2 with swr, a high performance
multi-threaded CPU based renderer.

- Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20161224/bda5be89/attachment.html>


More information about the ParaView mailing list