What issues affect performance of Distributed Rendering (DR)?
1. If your rendering seems slow, verify that the problem is outside of EnSight. Determine your performance (frame rate) baseline performance by checking the frame rate with nothing but the axis triad visible. If this is poor then you certainly have a problem external to EnSight that is degrading your performance.
What performance should you expect? Multiply your resolution by your bit depth and divide that by your network speed to get a frame rate. For example, suppose you have an image size of 800x700 pixels. With 32-bit pixels (RGBA), the number of bits per frame is 17.92Mbit. Transmission over a 10Mbit network will take 1.5-2 seconds per frame (with no compresssion).
Then, try testing the frame rate by varying the number of rendering nodes (say 1, 2,and 4 nodes) and then varying the image size.
2.Verify that the distributed clients are using OpenGL by logging onto each of them and type glxinfo -display:0.0 If the response contains any reference to Mesa, you are going to have problems.
3. Distributed Rendering (DR), by nature, causes a large amount of network traffic. Network traffic efficiency becomes paramount. For example, it is important that the network node names be resolved locally to IPs on the same network, avoiding routing them onto the net and back and wasting time. Also it is important that the names resolve to IPs on the fastest network.
4.One potential cause for rendering slowdown is the use of indirect rendering. On some platforms and X11 server configurations, including a hostname in the DISPLAY environmental variable can cause EnSight to use indirect rendering. For example if the distributed clients have DISPLAY = hostname:0.0, this can cause indirect rendering and degrade EnSight performance. In these cases it is preferable to set DISPLAY=:0.0.
5. Display Lists affect rendering speed as well. The display list is a optimized format of the geometry received from the server or SOS. The format is optimized for use by the graphics card and in many cases physically located in graphics card memory. The preferred format is an OpenGL display list. The generation of display lists can take some time as data are copied and reformatted. Additionally, if the graphics card runs out of memory for the lists, it will begin to "swap" to main host memory and performance of both rendering and the display list generation can drop precipitously. When EnSight goes into shaded surface display mode, it must recompute these display lists and it must compute surface normals for all of the nodes. This operation can take time and the display lists in shaded mode are a bit larger than in line more, increasing the possibility of swapping on the graphics card.
In base EnSight, one can disable the use of OpenGL display lists (-no_display_list). This avoids the overhead of the list generation, but not the normal computations. Rendering the geometry this way is not as optimal for a graphics card, but avoiding display list swapping can overall be a win. Note that other options (e.g. -no_multi_sampling) can also help as they can increase the amount of memory available on the graphics card for display lists on some cards.
EnSight DR addresses these issues by performing the display list construction and normal computations in parallel on the various distributed rendering nodes. In addition, the display lists on the individual nodes tend to be much smaller than if all the geometry were on one node. Thus, it becomes less probable that the graphics card will "swap". As a result, it is possible to get super-linear speedups in the display list construction operations.