[Paraview-developers] IceT

[Moreland, Kenneth]

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) 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview-developers/attachments/20110214/2f95ccaa/attachment.htm>