WireGL A Scalable Graphics System for Clusters Greg Humphreys Matthew Eldridge Ian Buck Gordon Stoll Matthew Everett and Pat Hanrahan Presented by Bruce Johnson Motivation for WireGL Data sets for scientific computation applications are enormous Visualization of these datasets on single workstations is difficult or impossible Therefore we need a scalable parallel graphics rendering system What is WireGL Provides a parallel interface to a cluster based virtual graphics system Extends OpenGL API Allows flexible assignment of tiles to graphics accelerators Can perform final image reassembly in software using a general purpose cluster interconnect Can bring rendering power of cluster to displays ranging from a single monitor to a multi projector wall sized display WireGL Illustrated Parallel Graphics Architecture Classification Classify by the point in the graphics pipeline at which data are redistributed Redistribution or sorting is the transition from object parallelism to image parallelism Sort location has tremendous implications for the architecture s communication needs Advantage of WireGL s Communication Infrastructure WireGL uses commodity parts As opposed to highly specialized components found in SGI s Infinite Reality Therefore the hardware or the network may be upgraded at any time without redesigning the system Points of Communication in Graphics Pipeline Commodity parts restricts choices of communication because individual graphics accelerators cannot be modified Therefore there are only two points in the graphics pipeline to induce communication Immediately after the application stage Immediately before the final display stage If communication is used after the application stage this is the traditional sort first graphics architecture WireGL is a Sort first Renderer WireGL s Implementation From a High Level WireGL consists of one or more clients submitting OpenGL commands simultaneously to one or more graphics servers known as pipeservers Pipeservers are organized as a sort first parallel graphics pipeline and together serve to render a single output image Each pipeserver has its own graphics accelerator and a high speed network connecting it to all of its clients Compute Graphics Interface and Resolution Limited Compute limited means that the simulation generates data more slowly than the graphics system can accept it Graphics limited Geometry Limited means that a single client occupies multiple servers keeping each server it occupies busy due to its long rendering time Interface limited means that an application is limited by the rate at which it issues geometry to the graphics system Resolution limited Field Limited means that the visualization of the data is hampered because of a lack of display resolution How does WireGL Deal With These Limitations WireGL has no inherent restriction on the number of clients and servers it can accommodate For compute limited applications one needs more clients than servers For graphics limited applications one needs more servers than clients For interface limited applications one needs an equal number of clients and servers For resolution limited applications WireGL affords one the capacity to use larger display devices Client Implementation WireGL replaces OpenGL on Windows Linux and IRIX machines As the program makes calls to the OpenGL API WireGL will classify them into three categories Geometry State Special Geometry Commands Geometry commands are those that appear between glBegin and glEnd These commands are packed into a global geometry buffer The buffer contains a copy of the arguments to the function and an opcode These opcodes and data are sent directly to the networking library as a single function call Commands like glNormal3f do not create graphical fragments State effects are recorded in the buffer State Commands State commands directly affect the graphics state such as glRotatef glBlendFunc or glTexImage2D Each state has n bits associated indicate whether that state element is out of sync with each of its n servers When a state command is executed the bits are all set to 1 indicating that each server might need a new copy of that element Geometry Buffer Transmission Two circumstances can trigger the transmission of the geometry buffer If the buffer fills up it must be flushed to make room for subsequent commands If a state command is called while the geometry buffer is not empty since OpenGL has such strict ordering semantics The geometry buffer cannot be sent to overlapped servers immediately since they may not have the correct OpenGL state The application s current state must be sent prior to any transmission of geometry WireGL currently has no automatic mechanism for determining the best time to partition geometry Parallel Graphics Considerations When running a parallel application each client node performs a sort first distribution of geometry and state to all pipeservers When multiple OpenGL graphics contexts wish to render a single image ordering must be performed via semaphores Synchronization functions are added to WireGL glBarrierExec name causes a graphics context to enter a barrier glSemaphoreP wait for a signal glSemaphoreV means to issue a signal These ordering commands are broadcast because the same ordering restrictions must be observed by all servers Special Commands Examples of special commands would be SwapBuffers glFinish and glClear glClear has a barrier immediately after its call to ensure that the frame buffer is clear before any drawing may take place SwapBuffers has consequences on synchronization because only one client may execute it per frame SwapBuffers marks the end of a frame and causes a buffer swap to be executed by all servers Pipeserver Implementation A pipeserver maintains a queue of pending commands for each client As the new commands arrive over the network they are placed at the end of the client s queue These queues are stored in a circular run queue of contexts A pipeserver continues executing a client s commands until it runs out of work or the context blocks on a barrier with a semaphore operation Blocked contexts are placed on wait queues associated with the semaphore or barrier they are waiting on Portrait of a Pipeserver Context Switching Since each client has an associated graphics context a context switch must be performed each time a client s stream blocks This context switching time is limited by the hardware The context switching time is slow enough to limit the
View Full Document
Unlocking...