supercomputers, DGL, FDDI (longish)

[Gary Tarolli]

I thought I would shed some light on some of the recent DGL discussions...


In article <1991Mar20.193615.2846 at eagle.lerc.nasa.gov>, tttron at escher.lerc.nasa.gov (William Krauss) writes:
> In article <1991Mar20.163153 at anusf.anu.edu.au> drw900 at anusf.anu.edu.au writes:
> >
> >	I'm interested in hearing peoples (SG people included)
> >experiences using SG's directly from supercomputers via thinks like
> >DGL.  How do I go about getting DGL for a new machine (Fujitsu VP 2200
> >and CM-2) ?  What are peoples experiences with faster than ethernet
> >networks for SG's (eg fddi). 
> >							Thanks,
> >							Drew.
> >
> 
> 
> - When calling the DGL from C:
> 
>                         dglopen(Hostname, ConnectionType);
>                                 ...
>                                 GL CODE                 
>                                 ...
>                         dglclose(serverid);
> 
> After compiling the application on the CLIENT, one starts the HOST-SGI DGL 
> daemon to "listen" for DGL requests and runs the CLIENT application. 
> I believe >ALL< SGI's are shipped with the DGL daemon,so "installing" the DGL 
> is only necessary on the CLIENT.
> 

First, although you can call dglopen() and dglclose() you do not HAVE to.
Calling dglclose() is nice and certainly good citizenship, but dglclose()
is like gexit() - its optional. As for dglclose, you can also omit it.
On UNIX machines that support getenv(), the DGL will try to translate some
environment variables (similar to what X does for DISPLAY).  See the manuals
for details.  But basically, you can just set one environment variable and
the program will work without dglopen().  Unless of course you want to
open up windows on multiple graphic servers...

Second, starting the DGL daemon (called dgld) on the graphics server involves
a one-time change to /usr/etc/inetd.conf.  The only installing on the
CLIENT is to make sure the service called sgi-dgl is defined (in /etc/services
unless you are running YP).
> 
> The Ethernet performance is subjected to the usual traffic (so when there is 
> motion - rotation, etc., there is usually intermittent behavior as opposed to 
> the smooth double-buffered motion of native GL graphics).  
> 
> The UltraNet performance is superb. Since it can handle all of the data 
> being sent from the CLIENT (and then some!) the rotation, etc., is smooth like
> the native - but slightly slower. This makes sense when you realize that there
> are other users on the CLIENT competing for precious CPU/swapping/etc. 
> 

Ethernet performance for rotations etc. and real time motion can be quite good
if one uses display lists.  To achieve 30 frames per second motion based on
mouse input requires about 100 packets a second between the client-server.
This is not impossible on Ethernet.  However, if you attempt to use immediate
mode graphics and the DGL, then you will be limited by the bandwidth of
the network.  The wiser option is to use display lists if possible, when
using the DGL.  That way the network traffic to redisplay an image can
be reduced by orders of magnitude.  We (SGI) made sure that display lists
were fast and also supported all the new bgn/v/end commands, so that
you could take full advantage of all of our new graphics (eg. VGX) and still
use display lists.  I wrote up a very long and technical chapter regarding
DGL performance and how to measure and tune it.  See the 4Sight Pgmers Guide,
Version 3.0, Chapter 6 and Appendix B for more details.


--------------------
	Gary Tarolli