[Paraview-developers] IceT

[Moreland, Kenneth]

Yup.  And of course in desktop-delivery mode, IceT is set to have a single
tile (which, as you said, is the same size as the GUI render view), and
the compositing basically reverts to something like binary swap.

If you are interested, there is also some oddness in the implementation in
that if you have split the GUI into multiple render windows, those are
actually implemented as a single render context on the server with
viewports that split the render context in a manner equivalent to that in
the GUI.  This simplifies things in tiled display mode where the
resolution and aspect ratio of the display do not actually match what the
user set in the GUI.

-Ken

   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********  
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel




On 2/15/11 6:57 AM, "Paul Melis" <paul.melis at sara.nl> wrote:

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