Because of the single-system-image design of UltimateVision graphics systems, developing multiprocessor and multipipe applications on these platforms is similar to developing on a single-CPU , single-GPU system. A single executable can access all data in memory at once and render to all GPUs at the same time with multiple draw threads. A single debugger can attach to the executable to view the whole application state. This dramatically differs from code development on a cluster, where each executable is a different process on a different node, which needs a separate debugger to determine program faults. This is not to mention resolving inter-process timing issues, which are a challenge on a shared memory machine but next to impossible to fix on distributed systems.
Multiple pipes allow a visualization application to scale many different aspects of its performance:
Rendering speed
Display resolution
Data size
The dimension most apparent is rendering performance. More GPUs directly translate into more polygon transform and fill performance to view larger data sets at interactive rates. As data sets grow, more graphics bricks can be added with the SGI systems growing along with the data. In addition to polygon transform and fill performance, scalability also includes pixel scalability to provide large-scale display surfaces for theatres, caves, or just a single wall of a conference room. Equally important, more GPUs adds increased pixel shader and vertex shader performance; over time this will become the most relevant and important measure of performance.
Pixel scalability provides the capability of moving beyond 1M–9M pixel desktop displays to tens or hundreds of Mpixel display walls to provide high resolution across almost any size display surface. Scalability also does not have a limit to a single dimension. A single display surface might need polygon and fill scalability with multiple GPUs to achieve the desired frame rate. At the same time, the number of pixels can be scaled to make a 4x4 display wall, where each of the 16 display surfaces on the wall have multiple GPUs driving it.
By adding GPUs, GPU local memory is scaled. This can allow larger 3D textures to be cached in a distributed fashion and re-assembled after rendering (Monster Mode). Likewise, it allows more polygons to be cached in the GPU, where performance is highest. Adding GPUs also adds bandwidth, which enables the GPU cached data to be updated more rapidly overall. This paradigm of viewing GPU memory as a local cache will become increasingly important and widely used, particularly as vertex and pixel shaders allow more complex and higher-level algorithms to be applied to the data.
There are many techniques for scaling visual computing problems, each having different benefits for different problem domains. The following are the most common ways to combine GPUs:
Note that any of these techniques can be arbitrarily combined with others. For example, four sets of eight GPUs could be grouped in a 2D tile of four quadrants with each quadrant using data subdivision.
As SGI has developed expertise in building scalable compute and visualization architectures, it has been clear that tools to enable developers to build applications easily leveraging the power of scalability were critical. Over the past 10 years, SGI has been developing and improving on these toolkits to the point that there is a full range of toolkits that enable scalable applications. The choice of which toolkit to use depends on many factors including the following:
Application architecture
Target platform
Level of scalability desired
Amount of control you are willing to give to the toolkit
In general, supporting multiple pipes is a data management problem. Leveraging multiple processes running on multiple processors feeding multiple OpenGL streams on multiple GPUs is critical to getting true scaling of performance or image quality. The following items are required:
Multiple processes for dedicated processors to feed the graphics pipes
Data culled into chunks that are appropriate for a given GPU
Multiple rendering streams provided by the application
Database paging processes that potentially run asynchronously to keep the rendering pipeline filled
This section describes some tools provided by SGI to aid in this effort.
At the simplest level, SGI offers the OpenGL Multipipe product, which is designed to run a traditional single-pipe application across multipipe outputs. This level of API gives you moderate scalability with very little impact to the design and architecture of the existing application. Any single-pipe application will see moderate scalability when run with OpenGL Multipipe. To increase scalability, there are some simple guidelines to follow that allow OpenGL Multipipe to further increase application scalability. These guidelines entail some OpenGL coding idioms that generally do not affect single-pipe performance but allow OpenGL Multipipe to run more efficiently. For example, using smaller localized display lists allows OpenGL Multipipe to cull out many of the display lists on a pipe that will not be visible on that pipe. For more details on additional scalability optimizations, see the OpenGL Multipipe website (http://www.sgi.com/software/multipipe/).
A step further beyond OpenGL Multipipe is to have your application directly address all the graphics pipes in the system rather than leaving this up to OpenGL Multipipe. This will provide a boost in performance and scalability by sending multiple streams of OpenGL to the graphics pipes rather than a single OpenGL stream that is characteristic of a single-pipe application. The OpenGL Multipipe SDK toolkit provides a framework for you to manage multiple draw threads rendering to multiple pipes or GPUs. The OpenGL Multipipe SDK framework determines when and which GPU to render to while handling all the details necessary to manage graphics contexts and matrix stacks. The application is still responsible for all rendering, but many of the complexities of multipipe rendering are offloaded to OpenGL Multipipe SDK. For more details on scaling applications with OpenGL Multipipe SDK, see the OpenGL Multipipe SDK website (http://www.sgi.com/software/multipipe/sdk/).
While OpenGL Multipipe SDK can allow an application to linearly scale over many GPUs, there are still many details that need to be considered to achieve the highest level of scalability. OpenGL Performer, which is a scene-graph based API, is designed to enable this ultimate level of scalability and performance. OpenGL Performer offloads all rendering responsibility from the application. An application describes the scene to be visualized to OpenGL Performer and OpenGL Performer decides the most efficient way to render that scene across all the available CPUs and GPUs in the system. For more details on scaling applications with OpenGL Performer, see the OpenGL Performer website (http://www.sgi.com/software/performer/).