EnSight Rendering Performance (DR)

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 
DISPLAY = hostname:0.0, this can cause indirect rendering and 
degrade EnSight performance. In these cases it is preferable to set 

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 

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 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request