To initialize DMX, do the following:

After DMX has initialized, you will see a new session covering all the screens. At this point, you can start using OpenGL Multipipe by running applications with omprun (see “Running Applications with OpenGL Multipipe”).

Differences between the IRIX and Linux Versions of ompstartdmx

This section lists differences (and one noteworthy similarity) in the behavior and command-line options of the ompstartdmx script between IRIX and Linux:

DMX Limitations on Linux

When using a GNOME session with an aware window manager, the session will not be saved; the default session will be used at each login. This happens because the gnome-wm script does not pass the session ID parameter to any aware window manager, only to those which are supported by the GNOME environment (sawfish, metacity, twm, and their like). When using a KDE or GNOME session without aware window management, the session will be saved and restord at the next login.

A DMX configuration file is simply a text file that describes the configuration of a virtual display, the real displays it manages, and the geometry of the virtual screen. This section provides some short examples of configuration files. These and other example configuration files may be found in the directory /usr/share/omp/examples/dmx .

To start DMX with one of these configurations, do the following:

The following example configuration file specifies a vertical layout:

virtual updown 1280x2048 {
    display :0.0 1280x1024;
    display :0.1 1280x1024 @0x1024;
}

This configuration file defines a virtual screen configuration named updown of size 1280x2048. The virtual screen includes the following two real back-end displays:

You may also define some overlap between each of the screens, as in the following horizontal layout:

virtual overlap 2460x1024 {
    display :0.0 1280x1024;
    display :0.1 1280x1024 @1180x0;
}

This configuration file defines two screens of 1280x1024, each with 100 pixels of overlap, resulting in a virtual screen size of 2460x1024.

The display value specified can be any valid display value, including a display value that specifies a remote machine, as in the following example:

virtual remote 2560x1024 {
    display localhost:0.0 1280x1024;
    display remotehost:0.1 1280x1024 @1280x0;
}

There is also a graphical tool to create and edit configuration files. You can find documentation for this tool in /usr/share/omp/doc/user/xdmxconfig.1.html. The tool is installed in /usr/share/omp/X11/bin/xdmxconfig.

More information about the configuration file format can be found in the file /usr/share/omp/doc/user/Xdmx.1.html.

To configure OpenGL Multipipe with SGI Xinerama as the X proxy layer, perform the following steps:

After the X server is started with SGI Xinerama enabled and you have logged in to the system, you can start using OpenGL Multipipe by running applications with omprun (see “Running Applications with OpenGL Multipipe”).

Reality Center environments with multiple projectors and multiple graphics pipes often have overlapping screens. To allow seamless alignment of these screens, projectors typically have edge blending capability.

You control the amount of overlap or gap space between screens by specifying the xoffset and yoffset arguments (in units of pixels) of the –hw parameters in the file /var/X11/xdm/Xservers. For example, if you have three pipes, each with a resolution of 1280 x 1024 and a horizontal overlap of 256 pixels between each screen, you would place the following –hw arguments together on one line in the /var/X11/xdm/Xservers file:

:0 secure /usr/bin/X11/X
-boards 4,5,6
-hw board=4,right=1
-hw board=5,left=0,right=2,xoffset=-256
-hw board=6,left=1,xoffset=-256
... other X server arguments ...

Notes:

See the Xsgi(1) and xdm(1) man pages for more information.

The full name of each OpenGL Multipipe resource has the following format:

OMP.app_name.resource_name

The app_name field is the application name, defined to be the last component in the running executable path name. The resource_name is one of the available OpenGL Multipipe resources.

You can specify a resource with loose binding—that is, matching the resource for all applications—by using an asterisk in the following manner:

OMP*resource_name

For more information on the X11 resources and their scope, see the X(1) and XrmInitialize(3) man pages.

The following ordered list of resource files indicates the search path OpenGL Multipipe uses to assign values to the resources:

The first match found will be used. However, resources set with the full-name format will always precede resources set with loose binding even if the full-name format is found later in the search path. Resources set with the omprun command always have precedence. For information of the use of the omprun command, see section “Setting Run-Time Options”.

If a resource is not specified in the preceding search path, then the defined default value for that resource will be used.

When you set the environment variable SGIOMP_PRINT_CONFIG to 1, OpenGL Multipipe prints the configuration values it uses to stdout when an application runs through OpenGL Multipipe. This is useful to ensure that any overrides you have specified are being honored.

Each resource value can have one of the following types:

Table 3-1 lists all resources with their default values.

Notes:

This section briefly describes each of the OpenGL Multipipe tunable resources:

aa2Jitter.X and aa2Jitter.Y
Controls the jittering offset for each input pipe when the hardware compositor configured for pixel averaging with two pipes. The value must include two values for both X and Y to specify the frustum offset in pixels on the x and y axes to be applied for the first and second pipe participating in the pixel averaging.

aa4Jitter.X and aa4Jitter.Y
Controls the jittering offset for each input pipe when the hardware compositor configured for pixel averaging with four pipes. The value must include four values for both X and Y to specify the frustum offset in pixels on the x and y axes to be applied for the first, second, third, and fourth pipes participating in the pixel averaging.

activeScreens
Specifies the back-end screens to be active. OpenGL Multipipe will render OpenGL primitives only on those pipes. For example, when Xdmx (or SGI Xinerama) manages three physical screens (pipes), setting the activeScreens resource to 0,1 will make OpenGL rendering to be visible on screens 0 and 1 only. On screens 2 and 3, the OpenGL part of the application windows will be either black or garbage. By default, all managed screens will be active with respect to OpenGL.

culling
Specifies the enable switch for the geometry culling feature of OpenGL Multipipe. It can be either off or on. When this resource is enabled OpenGL Multipipe will draw to each pipe only the geometry primitives that are visible on that pipe. The default value for this switch is off. For more information, see section “Geometry Culling” in Chapter 4.

culling.cullUserClipPlanes
Enables culling against user-defined clip planes when one of GL_CLIP_PLANEi is enabled. The default value is off, in which case OpenGL Multipipe will cull only against the viewing frustum.

culling.minPixels
Specifies approximate culling—that is, the minimum object size in pixels that should be drawn. All objects smaller than this size will be culled. For more information, see section “Small Object Culling” in Chapter 4.

culling.showStat
Enables the drawing of culling statistics. The following are the possible values:

culling.texCulling
Enables or disables texture culling. When texture culling is enabled, texture loads will be postponed until the texture is really viewable on each specified pipe. In that case only, the relevent part from the texture will be downloaded to the pipe. The resource OMP*culling should be turned on for this feature. For more information and current limitations of this feature, see the release notes.

dlSplit
Allows OpenGL Multipipe to split a display list into smaller display lists based on a geometry spatial sort to acheive better culling. The smaller display lists can be distributed among the rendering pipes. This feature is usually used when culling is turned on. The valid values for dlSplit are on and off; the default is off. For more information, see section “Display List Partitioning” in Chapter 4.

dlSplit.maxDepth
Limits the number of recursive subdivisions by the dlSplit algorithm, which is an adaptive subdivision algorithm. After the specified number of recursive subdivisions are made, the process will end even if it does not meet the dlSplit.maxTris criterion. The default value is 8.

dlSplit.maxTotalTris
Limits the number of triangles that will be considered by the dlSplit algorithm at each iteration. If a display list contains more triangles than the specified number, then the splitting algorithm will be applied multiple times, once for each group that contains the specified number of triangles. The default value is 400000.

dlSplit.maxTris
Limits the number of triangles to the specified maximum for each bounding box of subordinate display lists. Display lists that have fewer triangles (or other primitives) than the specified number will not be split by the dlSplit algorithm. The default value is 800.

dlSplit.showRandomColors
Allows OpenGL Multipipe to randomly assign a different color for each divided geometry partition. For testing and debugging purposes, this coloring allows you to better see the divisions made by the dlSplit algorithm. This may not work for all applications as it simply uses glColor() to set the color for each partition. The default is off.

drawPixelsClipping
Controls whether the glDrawPixels() operation will be clipped such that only the viewable rectangle of pixels will be sent to each pipe.

masterMode
Specifies if and how the master process needs to use one of the graphics pipes. The following are the valid values:

masterScreen
Specifies which managed screen (pipe) will be used by the master application for either rendering or state tracking when running OpenGL Multipipe in master mode render or track (available only when using the omprun command). By default, it will be the first managed screen of the Xdmx or SGI Xinerama server.

maxFramesLatency
Specifies the maximum latency (in frames) allowed between the application and rendering slaves. The application process might pack a few frames ahead in the framebuffer while the slave processes are still drawing the previous frames. This introduces some latency between the application and the real drawing by the slave but helps overall throughput of master and slaves. The latency is always 0 when using masterMode render and is undefined if swapSyncMode is set to none. The default value for this resource is 4. For more information, see section “Frame Latency Control” in Chapter 4.

pbuffers.disable
Disables pbuffers support. When this resource is enabled, all pbuffer-capable framebuffer configurations will be filtered out and will not be exposed to the application. The default value is off.

pbuffers.layout
Controls how the rendering into a pbuffer is split among the rendering slaves. Each rendering slave can be configured to draw only to a sub-region of each pbuffer. The following are the valid values:

duplicate
All slaves renders to all regions of the pbuffer, That makes the content of the pbuffer to be duplicated on all rendering pipes. Use this configuration when your application uses glCopy*() to copy the pixels from the pbuffer to some other pixel buffer on the pipe. The other options might be better if you are using glReadPixels() to read back the pbuffer content into your process memory. This is the default value.

horizSplit
The area of the pbuffer is split into N horizontal strips, where N is the number of pipes. Each slave then limits the rendering to only one strip.

vertSplit
The area of the pbuffer is split into N vertical strips, where N is the number of pipes. Each slave then limits the rendering to only one strip.

rectSplit
The area of the pbuffer is split into N even rectangular areas as much as possible. For example, for a four-pipe configuration, it will be split into 2x2 tiles, where each tile is of size (w/2)x(h/2) and w and h are the pbuffer width and height, respectively. Each pipe then renders to only one tile.

shmQueueSize
Sets the size in bytes for the shared memory block that will be used for master-to-slaves communication. When this resource is not specified, the default value depends on the overall resolution of the meta display as determined by the following:

( DisplayWidth * DisplayHeight * 4 ) + 32

This allows a single full-screen glDrawPixels() command to fit in the shared memory since one single OpenGL command cannot be split into multiple packets. Depending on your application, you may want to set this value to be smaller or larger. When a shared memory size larger than the default or the specified size is needed, the application will exit with an error message specifiying the minimum shared memory size needed for that application.

slaveCPUs
Specifies the CPUs to assign to the draw slave processes for each of the active screens. If there are more active screens than the size of the specified CPU list, then the remaining draw processes will not be assigned to any particular CPU. By default, the draw processes will not be assigned to any particular CPU.

swapSyncMode
Specifies what method OpenGL Multipipe will use to synchronize swap buffers on all pipes. The following are the valid values:

texShm
Controls the caching of textures in shared memory. When this switch is turned on, OpenGL Multipipe will cache a copy of each texture in shared memory that remains valid until the texture is used by all pipes. Once the texture has been downloaded to driver memory of all pipes, the shared memory cache is purged. This feature works together with texture culling (see the culling.texCulling resource). When culling.texCulling is turned on, the texShm resource is implicitly turned on. The default for the texShm resource is off.

viewportClippingMode
Specifies viewport clipping mode. Each rendering slave may limit the rendering region to only the portion of the window that is visible on its rendering pipe. This is required to support large viewport areas, which are allowed by a single pipe, and it also helps to scale fill rate performance. The viewportClippingMode resource selects the method OpenGL Multipipe uses to limit this rendering region. The following are the valid values:

In IRIX 6.5.20 or later, you enable duplicate cursors by adding the –phantomcursors flag to the X server command line in the /var/X11/xdm/Xservers file. For more information about the –phantomcursors option, see the Xsgi(1) man page.

There are two ways to enable duplicate cursors under DMX:

Managing Screen Subregions with DMX

You can use a DMX configuration file to cause DMX to manage less than a whole backend screen. When the subregions of each screen are visually assembled using a congruent static compositor tiling, the resulting logical screen will look and behave identically to the DMX or SGI Xinerama displays with fully overlapping screens described previously. The following configuration file entry illustrates this feature:

virtual quadtilesubregions 1280x1024 {
    display :0.0 640x512+0+0     @0x0;
    display :0.1 640x512+640+0   @640x0;
    display :0.2 640x512+0+512   @0x512;
    display :0.3 640x512+640+512 @640x512;
}

---

Note: The SGIOMP_SCREEN_RECTS environment variable, described in section “Specifying Static Composited Regions for Fully Overlapped Screens”, is not necessary here and should not be used with a DMX configuration that manages screen subregions.

---

Managing Multiple Backend X Servers with DMX

The X mouse cursor can be made visible in the partially or fully overlapped screen regions needed for edge-blended or composited displays. As long as the logically overlapping areas of the DMX display are composed by screens of different backend X servers, DMX can utilize the mouse cursor that is available on each backend X server.

Instead of having DMX manage multiple screens of a single backend X server, you can start multiple backend X servers and specify a DMX configuration that logically overlaps areas from different backend X servers, as shown in the following:

virtual totaloverlapmulti 1280x1024 {
   display :0.0 1280x1024;
   display :1.0 1280x1024;
   display :2.0 1280x1024;
   display :3.0 1280x1024;
}

---

Note: The multiserver technique can be combined with the technique of managing screen subregions to create a logical display on which mouse cursors are visible in all overlapped and composited regions.

---