[Paraview-developers] IceT

[Paul Melis]

Hi Ken,

Thanks for the detailed answers

A followup to confirm the (perhaps) obvious:
* When using Paraview in client-server mode the IceT tile size equals 
the GUI render view's resolution(s)?
* When using Paraview in tiled panel mode the tile size equals the 
resolution of a single panel display?

Paul

On 02/14/2011 04:24 PM, Moreland, Kenneth wrote:
> To answer your questions in order.
>
> The multi-tile algorithms in IceT have not changed in principle since 
> the 2001 article.  The IceT library documentation (available at 
> http://www.cs.unm.edu/~kmorel/IceT 
> <http://www.cs.unm.edu/%7Ekmorel/IceT>) also gives an overview of the 
> algorithms used internally, although not with detail or analysis.
>
> ParaView is hard coded to pick the “Reduce to Single Tile” strategy.
>
> The network utilization for IceT, just like any other sort-last 
> algorithm, is determined by how much pixel data is generated.  At a 
> minimum, every pixel generated must be transferred to the node 
> displaying the pixel.  In the worst case where every node generates 
> data for every pixel, that would mean that, for example with the 64 
> node cluster in the paper, you would have to transfer 63 times the 
> output image size.  As you can see, the IceT algorithms are typically 
> much more efficient than that.
>
> BTW, those measurements were actually taken using 4 bytes per pixel 
> because IceT keeps the alpha channel around.  Although not 
> particularly useful during depth compositing, they are kept around so 
> that the color values line up on 32-bit integer boundaries.  That 
> makes the compositing operations go much faster.  Considering that, 
> the transferred data is now only about 4.5 times the image size.  Also 
> note that the comparisons require a depth value for each pixel, which 
> takes another 4 bytes.  So if you count each pixel as 8 bytes, we are 
> now down to 2.25 times the image size, although this is not completely 
> fair as the depth data was dropped as soon as it was no longer needed.
>
> It is also helpful to keep in mind that ParaView is clever when it 
> comes to rendering small geometries.  When the geometry is small, it 
> takes less network overhead to simply distribute the data to all nodes 
> and render locally to each tile, and ParaView does just that.  In that 
> case the network usage per frame essentially goes to zero.
>
> -Ken
>
>
> On 2/14/11 5:53 AM, "Paul Melis" <paul.melis at sara.nl> wrote:
>
>     I've been reading up on IceT and all the nice compositing
>     strategies it
>     uses, based on the 2001 article by Kenneth et.al. (Sort-last parallel
>     rendering for viewing extremely large data sets on tile displays). I'm
>     trying to get a good mental picture of what IceT does and how it
>     works.
>     A few questions:
>
>     * Does the 2001 article still give a good overview of IceT as used in
>     Paraview or have things changed considerably since then?
>     * Does IceT as used in Paraview pick its own compositing strategy
>     based
>     on work-load and such? Or is the strategy fixed?
>     * It seems the bandwidth used for inter-node communication due to
>     compositing is quite high. E.g. table 1 in the article lists a network
>     usage of 213-340 MBytes per frame on the LNLL isosurface, when
>     rendering
>     a 12 megapixel output image. Assuming the output image uses 3
>     bytes per
>     pixel that's a compositing data size that is roughly 6-9.5 times the
>     output image size. Is that a good estimate for the general case?
>
>     Thanks,
>     Paul
>     _______________________________________________
>     Paraview-developers mailing list
>     Paraview-developers at paraview.org
>     http://public.kitware.com/mailman/listinfo/paraview-developers
>
>
>
>
>    ****      Kenneth Moreland
>     ***      Sandia National Laboratories
> ***********
> *** *** ***  email: _kmorel at sandia.gov
> _**  ***  **  phone: (505) 844-8919
>     ***      web: _http://www.cs.unm.edu/~kmorel 
> <http://www.cs.unm.edu/%7Ekmorel>
> _