<HTML>
<HEAD>
<TITLE>Re: [Paraview-developers] IceT</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>To answer your questions in order.<BR>
<BR>
The multi-tile algorithms in IceT have not changed in principle since the 2001 article. The IceT library documentation (available at <a href="http://www.cs.unm.edu/~kmorel/IceT">http://www.cs.unm.edu/~kmorel/IceT</a>) also gives an overview of the algorithms used internally, although not with detail or analysis.<BR>
<BR>
ParaView is hard coded to pick the “Reduce to Single Tile” strategy.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
-Ken<BR>
<BR>
<BR>
On 2/14/11 5:53 AM, "Paul Melis" <<a href="paul.melis@sara.nl">paul.melis@sara.nl</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>I've been reading up on IceT and all the nice compositing strategies it<BR>
uses, based on the 2001 article by Kenneth et.al. (Sort-last parallel<BR>
rendering for viewing extremely large data sets on tile displays). I'm<BR>
trying to get a good mental picture of what IceT does and how it works.<BR>
A few questions:<BR>
<BR>
* Does the 2001 article still give a good overview of IceT as used in<BR>
Paraview or have things changed considerably since then?<BR>
* Does IceT as used in Paraview pick its own compositing strategy based<BR>
on work-load and such? Or is the strategy fixed?<BR>
* It seems the bandwidth used for inter-node communication due to<BR>
compositing is quite high. E.g. table 1 in the article lists a network<BR>
usage of 213-340 MBytes per frame on the LNLL isosurface, when rendering<BR>
a 12 megapixel output image. Assuming the output image uses 3 bytes per<BR>
pixel that's a compositing data size that is roughly 6-9.5 times the<BR>
output image size. Is that a good estimate for the general case?<BR>
<BR>
Thanks,<BR>
Paul<BR>
_______________________________________________<BR>
Paraview-developers mailing list<BR>
<a href="Paraview-developers@paraview.org">Paraview-developers@paraview.org</a><BR>
<a href="http://public.kitware.com/mailman/listinfo/paraview-developers">http://public.kitware.com/mailman/listinfo/paraview-developers</a><BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'><BR>
**** Kenneth Moreland<BR>
*** Sandia National Laboratories<BR>
*********** <BR>
*** *** *** email: <FONT COLOR="#0000FF"><U><a href="kmorel@sandia.gov">kmorel@sandia.gov</a><BR>
</U></FONT>** *** ** phone: (505) 844-8919<BR>
*** web: <FONT COLOR="#0000FF"><U><a href="http://www.cs.unm.edu/~kmorel">http://www.cs.unm.edu/~kmorel</a><BR>
</U></FONT></SPAN></FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT>
</BODY>
</HTML>