Render serving with GLR is a new application market for Onyx machines with InfiniteReality and RealityEngine graphics. GLR makes it possible to amoritize the cost of an Onyx across a group of users on a network by providing OpenGL rendering as a networked service. Here are set of frequently asked questions about GLR:
Q1: What is a rendering service?
A render service schedules concurrent access to fast, high-quality hardware rendering engines to multiple users and mulitple applications. A render service is generally accessed via a network.
The idea of a render server is to make available the power of a high-performance rendering engine available to classes of users and applications that previously found the dedicated nature of a high-end graphics workstation difficult to share and amortize.
A render service has a client/server model. A GLR client is an entity that requests access to high-quality rendering, while the GLR server is the entity that manages and schedules that access.
GLR is an OpenGL-based and network-extensible render server for Silicon Graphics Onyx machines with InfiniteReality or RealityEngine graphics.
Q3: What are some applications for GLR?
GLR makes sense for applications that require the fast and high-quality generation and manipulation of images and 3D data, but where real-time, immediate display is not a critical requirement. GLR is approriate when dedicating an Onyx to the application is not a viable solution. For example, a flight simulator that requires a 30 or 60 frames/sec update rate is not appropriate for using GLR.
Here are some applications for which GLR is well-suited:
Q4: How would different markets use GLR?
Here are some ways different markets could use GLR render serving:
Q6: What is a render interval?
GLR uses render intervals for scheduling access to the Onyx graphics hardware. A GLR client wanting access to the rendering hardware request a render interval. A render interval request include the height and width in pixels or the requested frame buffer region for rendering and the number of milliseconds within which to render.
When the GLR server scheduleds a render interval, the client gets at least the requested number of milliseconds of rendering time to a frame buffer rectangle of the requested size. If the GLR client takes more than its requested interval of time and if there are other render intervals to be scheduled, the GLR server may expire the render interval. The GLR client determines if the render interval was expired by checking the status of the render interval when its completes the render interval. If the interval was successful, any frame buffer state retreived during the interval is assured to be valid. If the interval was expired, frame buffer state is likely invalid. A GLR client will need to "redo" the render interval to get correct results. In either case, the actual time in milliseconds used during the interval is returned so that next render interval can be more accurately scheduled.
During a render interval, arbitrary OpenGL rendering can be performed. It is up to the GLR client to retrieve any rendered frame buffer state (for example, the rendered interval) before the interval is expired. Frame buffer state (pixels) is only retained within a render interval. OpenGL rendering state (like if lighting is enabled) is retained across render intervals. Typically, a GLR client uses a render interval to draw a single frame of 3D rendering and read back the results.
You can think of a render interval as a specilized type of transaction processing. In most cases, the render interval succeeds and the client gets back the correct results. When the interval is expired, the client must repeat the interval. This is like re-submitting a transaction until it can be successfully commited. Render intervals help make the GLR service robust. A GLR client cannot "lock up" access to the render service by other GLR clients in the case of faulty clients or an unreliably slow network. The expiration time lets the GLR server "unlock" the pipe after a resonable amount of time has passed.
Render intervals virtualize access to the graphics hardware in both space (the rectangle of pixels allocated) and time (the length of the interval).
Q7: What is the connection between OpenGL and GLR?
GLR uses OpenGL as the rendering system. GLR provides now rendering capabilities of its own. GLR just schedules and manages access to the graphics subsystem. All GLR programs use OpenGL for their rendering.
GLR is network-extensible, meaning the GLR client can be running on a different machine from the GLR server. The GLR and OpenGL requests can be relayed via the network when the client and server reside on different machines.
"Under the covers", GLR uses the X Window System and the GLX extension for supporting OpenGL, in particular, for its network extensibility. This means the same vendor interoperable protocol for using OpenGL across the network is used by GLR.
Q8: How do I get the GLR software?
Currently (May 9, 1996), an alpha version of GLR exists as installable SGI images. The software includes an execution-only environment, development option, and demos. You can install it from:
su inst -f rendering.asd:/dist/glr/latest
This software can also be distributed to prospective customers. Please check with Mark Kilgard before doing so to coordinate the efforts.
The digital VCR is a buzzword. It describes a method of using GLR where the results are computer movie files (QuickTime, MPEG, SGI Movie format) that capture the results of high-quality OpenGL rendering.
There is often a need for users of 3D to "isolate" a particular 3D sequence from their application so that the experience can be more easily shared with others. For example, a researcher and expert at a particular 3D visualization application may be able to visualize a key insight about a data set, but to share that result with others, the researcher needs an effective way to capture the animation. A GLR-enabled application can very quickly render the researcher's animation sequence and store it an a computer genated movie.
The resulting movie can then be viewed by others. Movies have distinct advantages for distributing animated results because they support a simple user interface for viewing (a VCR remote control), provide compression, and because common formats are supported by workstations, PCs, and Macs. In addition, editing tools exist to add voice annotation and edit and combine computer movie files.
GLR is very well-suited for the generation of computer movie files. High-performance graphics subsystems can generate the animations faster and with higher-quality than other methods.
Q10: What is a hybrid GLR application?
GLR applications can combine GLR rendering results from an Onyx with the rendering capabilities of current desktop workstations to improve the level of interactivity. This is known as a hybrid GLR application since it combines fast desktop rendering for interactivity with GLR rendering for high-quality.
For example, you can render dynamic scenes interactively on the desktop workstation, but re-rendering the scene at substantially higher quality with GLR when the scene becomes static.
glrduckpond is an example of a hybrid GLR program.
RGLX is a early prototype of render serving. RGLX was implemented by Brian Cabral, Todd Kulick, and Norman Chin. RGLX was the inspiration for GLR.
Yes. GLR requires no changes to the Silicon Graphics X server, graphics hardware, or operating system to operate. GLR is constructed atop OpenGL and the X Window System. In particular, GLR uses OpenGL's GLX extension to X to operate over a network.
Q13: On what machine does a GLR-enabled application run?
A GLR-enabled application can run either on your desktop workstation (performing OpenGL rendering over the network with GLX) or on your Onyx. Practically, you want to run a GLR-enabled application on the machine results in the best overall.
For example, a volume rendering program that requires large amounts of data and frequent texture downloading runs better on the Onyx where the program can directly render to the Onyx graphics hardware.
On the other hand, consider a typical desktop application like a 3D modeler that includes a feature allowing the user to request a static scene re-render at a higher-quality with GLR. Except for the GLR re-render capability, the application runs fine on the desktop workstation. In this case (since most rendering can be done by the desktop workstation), the application makes the most sense running on the desktop workstation.
Q14: Can I use GLR with an X terminal or a PC?
GLR requires the X Window System and OpenGL's GLX extension to X.
Keep in mind that if you plan to display GLR-rendered images on a X terminal, PC, or a low-end workstation, that GLR-rendered images tend to have high color resolution. Just as it makes little sense to buy and expensive stereo and connect lousy speakers to it, using GLR from a desktop machine generally requires a machine with 24-bit graphics or better.
If you use GLR for computer movie file generation, it is generally true that those movies can be played on low-end PCs, X terminals, and workstations with reasonable quality. Movies provide an excellent way to share GLR-rendered animations with users of PCs, Macs, and X terminals.
Q15: What is volume rendering?
Volume rendering is a technique for rendering data best represented as a cube of data values. For example, the type of data common in medical imaging or seismic analysis. The idea is to treat your cube of data as a virtual cube of jello where you can control the opacity of the data or slice through it arbitrarily. Volume rendering can provide powerful insights into volumetric data.
OpenGL's extension for 3D texture mapping provides hardware acceleration for the task of volume rendering. Even so, interactive rendering of large volumes consumes large amounts of texture memory. Onyx systems provide the ability to render such large volumes.
Volume rendering is a prime application for GLR render serving.
Q16: What does it take to GLR-enable an application?
To use GLR, the application must be written to use the GLR library. The GLR programming interface provides a means to execute GLR render intervals. An existing program must be modified to use GLR. For many programs, this involves boiler-plate changes to the program.
The first step is to initialize GLR for use. Here is some pseudo-code for the steps involved:
call glrOpenSession() to connect to a GLR server
call glrGetCanvasType() to find a suitable frame buffer configuration
call glrCreateCanvas() to request a canvas
call glrEstablishRenderState() before executing OpenGL commands to
initialize the state of the canvas
An application that uses GLR to interactively display GLR-rendered scenes on a desktop workstation would use code like this each time it redraws the scene:
do {
call glrBeginRenderInterval
execute OpenGL commands to draw the scene
call glReadPixels to read back the scene
call glrEndRenderInterval
} while render interval is expired
call glXMakeCurrent to bind to desktop window
call glDrawPixels to render image read by glReadPixels
The GLR development option includes source code for the GLR demo programs to help you develop GLR-enabled applications.
Q17: What at SGI is involved in GLR?
Mark Kilgard, Engineering.
HB Seigel, Director of Core Rendering, Engineering.
Brian Cabral, Engineering.
Trina Roy, Applied Engineering.
A GLR session is a connection to the GLR server. A GLR session is set up by calling glrOpenSession.
Q19: What does the GLR_SERVER environment variable control?
Unless glrOpenSession is given an explicit hostname, glrOpenSession uses the name supplied by your GLR_SERVER environment variable to decide what GLR server machine to connect to. If GLR_SERVER is not set, GLR uses the local machine.
Q20: What is a GLR canvas type?
A GLR canvas type is an object describing a frame buffer configuration supported by the GLR server. You can request a cavas type for a specified configuration with glrGetCanvasType.
Q21: What is a GLR canvas?
A GLR canvas is an object that encapsulates an OpenGL state machine instance for use with GLR. A canvas has the frame buffer capabilities determined by the canvas type used to create it. You can create a canvas with glrCreateCanvas.
Q22: Does the GLR server take over the machine?
No. An Onyx running the GLR server can still be used as a file server or compute server, but because GLR schedules access to the graphics hardware, using GLR means not running the standard interactive window system.
Q23: What do you mean by the "GLR server"?
The GLR server is actually two distinct programs working together. A program called glrmanager enforces GLR's scheduling policy; the standard Silicion Graphics X server is used to control the access to the graphics hardware and networked OpenGL requests.
GLR uses the glrmanager program to start the X server for use with GLR and to actually do the scheduling of GLR render intervals. glrmanager serves as an X window manager, but instead of overlapping windows to simulate a desktop, glrmanager schedules the mapping of windows on the screen according to GLR's policy designed for render serving.
GLR promises that multiple applications and users can share access Onyx graphics hardware, thereby amortizing the cost of the hardware. Obviously, GLR can only provide the rendering performance available from the hardware. Multiple simultaneous GLR users must split the hardware resources among themselves.
There is some overhead for scheduling access to the graphics hardware through GLR, but GLR is implemented to have as low an overhead as possible. To help, this:
In practice, a single GLR user on a RealityEngine can obtain 6-8 frames of animated volume rendering with GLR-enabled volren on a 10Mb/sec Ethernet. Two GLR-enabled volren users each get 2-3 frames of animated volume rendering on a 10Mb/sec Ethernet. More than two simultaneous users makes difficult to interactively use GLR-enabled volren. Note that the performance limitations come from multiple simultaneous sessions. Two users that occasionally manipulate their volumes, but not simultaneously, obtain the performance of a single user. Note that volume rendering is a particularly expensive application since context switching large textures is particularly expensive.
For other applications like GLR-enabled desktop CAD applications that only render scenes with GLR occasionally, much better scaling of GLR can be achieved largely because fewer renders are simultaneously requested since most interactive rendering is done by the desktop workstation.
Q26: Contrast GLR with other possible alternatives.
GLR is one fairly general approach to sharing an Onyx among multiple users. Here are some others:
Because GLR is a service, you can GLR for non-interactive tasks like movie generation and batch image processing.
Q27: Why now for render serving?
Render serving becomes a viable means to share a high-end graphics subsystem when:
Q28: What demos of GLR are available?
Currently (May 9, 1996), a small set of demos of GLR are available as a set of installable images (glr_demos). They include:
To run these demos, you'll need to install them and the glr_eoe (GLR execution-only environmet) on an Onyx running IRIX 5.3 or 6.2. See the instructions for running the demos at /usr/demos/GLR/bin/README
A machine named rendering.asd is available for use as a render server. If you are interested in a demonstration, find Mark Kilgard.
Q29: Is there a technical paper on GLR?
Yes. It is titled "GLR, an OpenGL render server facility." (PostScript)
Q30: Are there Showcase slides on GLR?
Yes.
Showcase slides from the X Technical Conference presentation (PostScript).