Parallel compositing is sometimes referred to as EnSight Enterpise (formerly EnSight HPC+ or EnSight PC). It enables users with an extremely large amount of visible geometry to distribute the client-side computation and rendering among multiple CPUs and GPUs in a cluster of workstations. The final result is an image in the EnSight rendering window that is indistinguishable from a standard EnSight client running on a single workstation, but at much higher performance.
Pros:
very-high polygon rates (Billions of triangles / sec)
scalable client memory and computation
ability to render remotely and view locally
Cons:
frame-rate upper-bound determined by network bandwidth
resolution limited to single workstation display
Compositing is for users working in a desktop environment who have large data which overwhelms the capability of a single workstation, in terms of memory, processing power, and/or rendering performance.
Note: Compositing is not an application for ganging together dozens of old workstations that have no other use - compositing itself requires fast processors and a fast network in order to achieve any measure of scalability.
EnSight Enterprise (formerly HPC+) Configuration
A properly configured EnShell network is required to use EnSight Enterprise (formerly HPC+), see Cave Environment, Wall Displays & Head-mounted Displays.
Given a running EnShell network, EnSight Enterprise (formerly HPC+) can be started by running the command:
ensight -enshell -prdist
[optional_prdist_file]
The command line option '-enshell' instructs EnSight to use the EnShell
network. The -prdist option stands for distributed parallel rendering, and it
instructs EnSight to use parallel compositing. The -prdist option takes an optional
prdist file name although it is not usually needed (see Command Line Start-up Options).
EnSight will run distributed rendering Clients on EnShells that have the role name 'DRCLIENTS'. If none have the role name 'DRCLIENTS', then any EnShells with role names 'SOS_SERVERS' will be used. If none have that role name then 'SERVER' will be tried and then finally 'localhost'. You should use either 'DRCLIENTS' or 'SOS_SERVERS' to be explicit as to which EnShells should be used.
EnSight will run the EnSight CollabHub on the EnShell with the role name 'COLLABHUB'. If that can't be found, then role names 'SOS' or 'localhost' will be used.
In EnSight 2024 R2 there are restrictions on the computers and their network connectivity.
The DRCLIENTS must be on the same computer as the COLLABHUB computer or no more than one EnShell connection away.
The DRCLIENT computers must be able to open a network connection to each other.
The COLLABHUB must be on the same computer as the main EnSight Client or one hop away.
The SOS must be on the same computer as the COLLABHUB or one hop away.
The functioning CEIStart configuration "Remote SOS" shows how the entire process can be fully automated including EnSight startup with optional one-click invocation of parallel compositing. Many users may find that this configuration is sufficient for real production use on a larger SMP type computer (for example, an 8 CPU or greater system with 8GB or more of memory).
The optional prdist file can be used to specify parallel compositing options; although, it is frequently not needed. The format of the file looks like:
#
pc [options]
where [options] may include:
guicomposite = "NONE" "NOCOMP" "COMP"
compression = "NONE" "LOW" "MED" "HIGH"
"AUTO"
guicompression = "{RAW|RLE|GZ} {final quality} {interactive
quality}" example: "RLE 0 2"
offscreen = "TRUE" "FALSE"
guicomposite
The parallel compositor (PC) needs to make a full set of TCP/IP connections between all of the render processes to exchange data between them. The master client (often called the GUI-client) is the EnSight client that actually displays a GUI and with which the user interacts. The guicomposite option has three possible values that determine the extent to which the master client participates in the compositing.
COMP: If the client is physically running on the same cluster as the other rendering nodes, use guicomposite="COMP". This causes PC to use the master node as part of the composite and as a side effect, leave the final image on that node. It is the most efficient way to get an image from PC to the screen, but the master node needs to be on the same high-performance network as the other render nodes for this to work well as it assumes symmetric bandwidth between the renderer clients and the master client. "TRUE" is the same as "COMP".
NOCOMP: The next level of performance is guicomposite="NOCOMP". In this mode, the master still makes TCP/IP connections to each of the renderer nodes, but it does not participate in the actual compositing. The various pieces of the final image are sent back to the master node in parallel over the N sockets to the render nodes. This mode works well if the master node is not located on the cluster interconnect, but can still make N connections to the cluster over a fairly high performance interface. (for example, the asymmetric bandwidth situation). In practice, few people use this mode as the number of off-cluster TCP/IP connections to the master can be a problem for things like firewalls.
NONE: The last level is guicomposite="NONE". In this mode, the PC system runs entirely on the cluster and the final image is passed to the first renderer node. That node can optionally compress the image and then sends it via TCP/IP to the collabhub which then sends it to the master client for display. This requires two network hops, but ensures that all of the TCP/IP connections of PC remain inside the cluster. It is the most firewall friendly mode as no new ports need to be opened up, but it is also the slowest mode.
compression
The compression option determines how the render
clients communicate during compositing. If the rendered images are large and the CPUs are fast
enough, enabling compression can increase the frame rate. These compression methods are all
lossless. There are very few situations where the best value us not "HIGH".
guicompression
The guicompression option only has an effect when
guicomposite is set to "NONE". This option
allows you to specify a compression level for images transmitted through the collaboration hub.
This option is most useful when the main client is remote from the rendering cluster, perhaps
over a lower-bandwidth and/or higher-latency network.
There are three compression methods each followed by two numbers: a final quality number and an interactive quality number. The higher the number, the lower the image quality. A quality value of 0 is lossless. The final number represents the quality of the still image when no more transforms are occurring, and the interactive number represents the quality of the image while undergoing transforms (for example, rotation or translation). Often the interactive number is higher (lower quality) than the final to accelerate transformations.
RAW - uncompressed pixels. In this mode, the final and interactive quality numbers represent spatial decomposition (elimination of some spatial fraction of the pixels). The final and interactive quality numbers can range from 0 to 8, where 0=all pixels, 1=every other pixel, 2=every third pixel, etc. Visually, this effectively looks like larger pixels.
RLE - the evo RLE scheme, which has a nice balance of speed vs compression. The final and interactive quality numbers represent the number of lower-order bits of a color that are set to zero before the RLE scheme is applied. For example, the value 2 means that the color of a pixel is first reduced to 6 (8-2) bits per pixel before the compression. Therefore these quality numbers should ranges between 0 (highest quality) and 7 (lowest quality). Visually, this looks like quantized colors/banding.
GZ - using the "gzip" algorithm is slower, but has good compression. The final and transition quality numbers work as in the RLE case.
offscreen
The offscreen option specifies that the render
workers should create offscreen (pbuffer) rendering windows. By default they will be offscreen.
For debugging, change it to onscreen for viewing and confirming the partial results.
Note: One advantage of using offscreen windows is that your render
nodes do not have to run at the same resolution as your main client. If
guicompression = "NONE" and offscreen = "FALSE" then the first
renderer node in the prdist file may not display any image. It is rendering and participating
properly, however.
example
If the master client (where the GUI is) is on the cluster, use "COMP". In all other situations, use "NONE". You can try "NOCOMP", but it is not always a win. In house, we typically use the following pc line in our prdist files:
pc compression="HIGH" guicomposite="COMP" offscreen="TRUE" guicompression="RLE 0 2" (all on one line).
If the master client is not on the cluster, change "COMP" to "NONE". For 99% of the cases, that is the best setup.
See How To Use Resource Management for an example using resources
Trouble-shooting
For trouble-shooting problems like X server access, see Tips for Distributed Rendering.