This chapter describes some problems you might encounter and what to do to solve them. For additional considerations, see the OpenGL Multipipe release notes, /usr/share/omp/release_notes/user/relnotes.html.
This chapter documents the following problems:
You will see a cannot-connect-to-daemon error if the ompslave or ompcull daemon is disabled or missing. OpenGL Multipipe installs and enables these daemons by default; therefore, this error could indicate an installation problem. If reinstalling OpenGL Multipipe does not solve the problem, the following instructions demonstrate how to manually correct the configuration problem.
On IRIX, the following commands should produce the output displayed:
$ grep sgi-omp /etc/services sgi-ompslave 60000/tcp sgi-ompswapready 60001/tcp sgi-ompcull 60002/tcp $ grep sgi-omp /etc/inetd.conf sgi-ompslave stream tcp nowait root /usr/bin/ompslave ompslave sgi-ompcull stream tcp nowait root /usr/bin/ompcull ompcull sgi-ompswapready stream tcp wait root /usr/bin/ompswapready ompswapready |
If the preceding commands do not produce the expected output, either reinstall the omp_eoe images or edit the /etc/services and /etc/initd.conf files to make the corrections.
If the preceding commands produce the expected output and the slaves still fail to run, restart the inetd daemon with the following command and look for any error messages in the file /var/adm/SYSLOG:
$ killall -HUP inetd |
On Linux, the following commands should produce the output displayed:
$ chkconfig --list | grep sgi-omp sgi-ompcull: on sgi-ompslave: on |
If either of the services is labeled off, turn them on by running the following command as root:
# chkconfig sgi-ompcull on # chkconfig sgi-ompslave on # killall -HUP xinetd |
If the services do not exist, then the sgi-omp RPM needs to be reinstalled. Remove the installed RPM using the command rpm -e sgi-omp and re-install the package from the SGI ProPack CD.
On systems having only one graphics pipe or in the case where the X server is directed to handle only one pipe (see the Xsgi(1) man page), enabling SGI Xinerama has no effect. In these cases, SGI Xinerama will be disabled, regardless of the value of the xinerama flag supplied on the chkconfig command.
 | Note: SGI Xinerama is not available on Onyx4 and Silicon Graphics Prism platforms. Only the DMX proxy layer is supported on these platforms. |
If there is a problem starting the DMX proxy server, you may see output such as the following after running ompstartdmx:
ompstartdmx fatal: An error occured when starting Xdmx Check the Xdmx log file for details: /tmp/Xdmx.log.xxxxx |
This can result from a number of conditions, some of which have workarounds that are described in the following paragraphs. Inspect the Xdmx.log.xxxxx file, especially toward the end of the log, for messages that indicate one of the following conditions:
Incompatible screens, no common visuals
DMX will not create a logical display from graphics pipes with differing graphics capabilities. If the DMX proxy server detects that there are no common X visuals on the backend screens it tries to manage, DMX will abort with an error to this effect.
Only one screen on display
On systems having only one graphics pipe or in the case where the X server is directed to handle only one pipe, ompstartdmx will exit with an error such as the following:
ompstartdmx fatal: Display :0.0 has only one screen. DMX was not started
In these cases, it does not make sense to start DMX since there is only one pipe. However, specifying a configuration file with the ompstartdmx –cfgfile option will not prevent DMX from running on a single backend screen. Use the ompstartdmx –help option for more information.
ompstartdmx fails to start or hangs with a GLX error.
If a GLX BadMatch error occurs when starting DMX, the back-end screens may not have matching sets of GLX visuals. This is not a supported configuration and may be caused by a misconfiguration of the underlying X server(s), whose screens DMX manages.
The configuration of each screen DMX manages should be identical. To verify that all screens have identical sets of visuals, inspect the output of the glxinfo command for each of the back-end screen(s) managed by DMX, as shown in the following:
$ env DISPLAY=:0.0 glxinfo $ env DISPLAY=:0.1 glxinfo
Piping the output through wc provides a quick comparison.
For XFree86 servers, per-screen visual attributes and capabilities can be adjusted by modifying the file /etc/X11/XF86Config-4 on Onyx4 systems and the file /etc/X11/XF86Config on Silicon Graphics Prism systems. On IRIX systems other than Onyx4 systems, per-screen visual attributes are configured with the xsetmon application.
If an application will not start when using the omprun command, one likely scenario is that the DISPLAY environment variable does not point to a meta display. If the DISPLAY environment variable does not point to a meta display, ensure that the following conditions true (check them in the order listed):
The DISPLAY environment variable points to the correct display.
An X proxy layer is enabled.
See the section “Verifying That the OpenGL Multipipe Environment is Enabled” in Chapter 3. An X proxy layer must be enabled or when you invoke an application with omprun, the application will exit with the following error:
SGIomp fatal: “:0.0” is not a meta display
The application was not run from a shell that was started with the omprun –aware command or from a script that used the omprun –aware command to start the application.
The omprun –aware command effectively disables the X proxy layer for any programs it invokes.
Your application does not use either the OpenGL Multipipe SDK or OpenGL Performer multipipe API.
Recent versions of these APIs may have integrated with SGI Xinerama or DMX and may not run under OpenGL Multipipe. The solution is to run these applications as is or to simply ensure that they are run in aware mode (with omprun –aware). Another alternative is to use older versions of these APIs that do not contain the X proxy aware code.
If you have made changes to an X resource file but the changes do not appear to be having an effect, set the environment variable SGIOMP_PRINT_CONFIG to 1 so that OpenGL Multipipe prints the configuration values it uses to stdout when an application runs through OpenGL Multipipe.
Changing resources in an X resource file does not have an effect until the resources are merged into the active database in the X server with the xrdb command. For more information, see the xrdb(1) man page or use the command xrdb --help.
You might see a shared memory failure if the slave processes cannot open a connection to a back-end display server (for example, :0.0). Look in the file /tmp/ompslave.log to verify that this is the problem. A message indicating the connection was refused may indicate you need to set the XAUTHORITY environment variable or, otherwise, run xhost + on the X server.
If you run the application from within the DMX session, then XAUTHORITY will be set correctly for you. If you are running a command from a remote shell, you might have to set the XAUTHORITY environment variable to point to the correct X authority file before running the application. Otherwise, you will not have permission to open a connection to :1 or :0.
In some X sessions, the XAUTHORITY variable will point to a temporary X authority file, but in sessions where XAUTHORITY is not set, xauth defaults to $HOME/.Xauthority. If XAUTHORITY is not defined in your session, set it to the following before running your application with omprun:
$ setenv XAUTHORITY $HOME/.Xauthority |
For more information, see the xauth(1) man page.
OpenGL Multipipe does not support IRIS GL applications. In some cases (when the application started with the omprun script is an executable and not a script), omprun can determine if the application is based on IRIS GL. In such a case, a warning message is generated and the application will not be started, as shown in the following example:
$ omprun clock omprun warning: clock is an IRIS GL application OMP Library does not support IRIS GL applications |
For information about how to run an IRIS GL application when an X proxy layer is enabled, see the section “Running IRIS GL Applications” in Chapter 3.
OpenGL Multipipe does not support o32 applications. In some cases (when the application started with the omprun script is an executable and not a script), omprun can determine if the application was built using the o32 application binary interface (ABI). In such a case, a warning message is generated and the application will not be started, as shown in the following example:
$ omprun showcase omprun warning: showcase is an O32 application OMP Library does not support O32 applications |
For information about how to run an o32 application when an X proxy layer is enabled, see the section “Running IRIX o32 Applications” in Chapter 3.
If a graphics window displays correctly on some screens only, there are several likely scenarios, which are described in the following subsections:
If you are using the omprun –cull feature and you resize or move the application window to different screens, some applications may not draw an image properly on all screens. This can occur if an application does not call glClear() at the beginning of each frame (that is, it “builds up” an image, relying on a sort of rendering history from past frames). When culling is enabled, applications that do not call glClear() at the beginning of each new frame may have unusual rendering artifacts when they are moved from their initial window position. The culling feature by nature eliminates drawing commands that would otherwise be rendered into an off-screen region. To avoid this behavior, do not use the –cull option.
| Note: This section pertains to you only if you use the SGI Xinerama X proxy layer. |
If a graphics window displays correctly on one screen only (usually screen 0), ensure that you start the application with the omprun script. If the same behavior persists when you invoke the application using the omprun script, ensure that one of the other conditions described in the following subsections does not exist.
| Note: This section pertains to you only if you use the SGI Xinerama X proxy layer. |
The omprun script cannot detect IRIS GL or o32 applications if it starts another script that in turn starts the target application. The following shell session illustrates this case:
$ cd /usr/demos/General_Demos/atlantis $ omprun ./atlantis omprun warning: ./atlantis is an IRIS GL application OMP Library does not support IRIS GL applications $ omprun ./RUN |
In the preceding session, RUN is a script that invokes Atlantis. RUN does start the application, but it will be displayed correctly on one screen only.
If you start an application by using a user-defined script, ensure that the application is not an IRIS GL or o32 application. The following session shows how to test for an application that uses IRIS GL:
$ elfdump -Dl /usr/sbin/clock | grep libgl.so [1] Oct 20 20:39:53 2000 0xe5383809 ----- libgl.so sgi1.0 |
If there is no output, the application does not use IRIS GL.
The following demonstrates how to test for an application that uses the o32 ABI:
$ file /usr/sbin/iconsmith | grep `32-bit' /usr/sbin/iconsmith: ELF 32-bit MSB mips-2 dynamic executable MIPS - version 1 |
If there is no output, the application does not use the o32 ABI.
If you started an application in aware mode (that is, by running the script omprun –aware app_name... ), the application running in aware mode only draws to one screen. If you are running an aware window manager, it is possible that the window manager may position the window on a screen other than the one on which the application is drawing. To see the window rendered correctly, move the application's window to the correct screen.
If the omprun command is required to utilize the full OpenGL Multipipe environment on your platform, set-user-ID applications may not be able to utilize the full master-slave environment of OpenGL Multipipe. This is because the omprun script makes use of the following environment variable(s) to force an application to load the OpenGL Multipipe library libOMPmaster.so instead of the standard OpenGL library, libGL.so:
_RLDN32_LIST and _RLD64_LIST (on IRIX)
LD_PRELOAD (on Linux)
For security reasons, IRIX and Linux may ignore these environment variables for set-user-ID programs. Therefore, OpenGL Multipipe is not able to intercept and distribute OpenGL calls to all pipes. As a workaround, you may run the application under the DMX proxy layer to use its native support for GLX indirect rendering. To do so, simply run the application under DMX without using the omprun command. If this is not feasible, the application should run under omprun if you invoke the application while logged in as the user that owns or created the executable (or as root if administrative access is available).
| Note: This section pertains to you only if you use the SGI Xinerama X proxy layer. |
If logical pipe 0 is not in the top left screen position, mouse events (such as clicks) are offset by one screen. Logical pipe 0 can be any physical pipe; it is the physical pipe specified by the first -hw argument in the X server configuration file, /var/X11/xdm/Xservers.
To work around this problem, list the graphics pipe of the monitor that is in the top left position first in the list of -hw arguments in the Xservers file. For example, in a configuration where pipes 5, 3, and 4 are in a linear array in that order, you would use the following –boards and –hw parameters together on one line in the /var/X11/xdm/Xservers file:
:0 secure /usr/bin/X11/X -boards 5,3,4 -hw board=5,right=1 -hw board=3,left=0,right=2 -hw board=4,left=1 ... other X server args .... |
Notes:
The –boards numbers are physical pipe numbers, but the indexes given to the right, left, above, and below parameters refer to the logical order of the –hw parameters.
The first –hw parameter is that of the top, leftmost pipe and should never have a left or top neighbor.
The lines are separated in the example only for readability.
See the Xsgi(1) and xdm(1) man pages for more information about the -hw options and the Xservers file.
This condition may occur when the DMX screen configuration differs from the screen connectivity of the back-end X server(s) and the mouse cursor is moved quickly from one screen to another.
When a back-end X server is configured so that some of its screens are neighbors, the DMX configuration for these screens should match the back-end neighbor topology for proper mouse cursor movement. Otherwise, the mouse cursor could jump or move to unexpected locations when it crosses a screen boundary where the backend screen layout does not match the DMX screen layout.
To avoid this condition for XFree86 backend X servers, make sure the screen arrangement in the /etc/X11/XF86Config file matches the screen arrangement in the DMX configuration file. By default, DMX and XFree86 manage screens left-to-right in a horizontal row. For more information about configuring XFree86, see the XF86Config(5x) man page.
Applications—such as ircombine, sgcombine, xsetmon, setmon, and gamma— which are designed to manage graphics hardware pipes individually, are inherently multipipe applications. Therefore, they should be started in multipipe-aware mode, as shown in the following examples:
$ setenv DISPLAY :0.0 $ omprun -aware gamma $ setenv DISPLAY :0.0 $ omprun -aware sgcombine |
This allows the application to run as if the X proxy layer were disabled. Applications with a GUI—such as sgcombine, ircombine, and xsetmon—will not be under window manager control unless an aware window manager is active.
Windows of applications that are run in aware mode are not handled by ordinary window managers. This can cause some problems on screen 0 for keyboard events.
Moving away all the windows that are overlapping the aware window (even if these windows are displayed behind the aware window) will set the correct focus. The aware window will then receive the keyboard events.
Alternately, running the aware window manager will also fix the focus problem.
If you start an OpenGL application with omprun and it does not display anything or the graphic stalls or even hangs, the source of the problem might be one of the following:
You may see a blank display or experience stalls or hangs for OpenGL applications that do not call glFlush(), glFinish(), or glXSwapBuffers() at the end of each frame. This causes OpenGL Multipipe to draw only when its internal buffer overflows. It can happen that the buffer never fills, in the case of an event-driven application—that is, the application draws one frame and waits for an event before drawing the next frame. Unfortunately, there is no workaround for applications that are not frame-based because OpenGL Multipipe relies on regular calls to the functions just cited.
| Note: This section pertains to you only if you use the SGI Xinerama X proxy layer. |
If the size of a window with OpenGL content is larger than the maximum width or height allowed by the graphics hardware, undefined drawing behavior will result. Although this limit can vary depending on the graphics configuration, it is typically around 4000 pixels. Logical screen configurations with a width or height larger than the maximum OpenGL window size are particularly susceptible to this behavior. As long as an OpenGL window is smaller than the maximum size, it may be placed anywhere within the total area managed by the X server. Only the size of the region into which OpenGL renders is restricted. For more information, see “OpenGL Window Size Constraints” in Chapter 5.
If you are experiencing long delays between frames of an OpenGL application (whether or not it was started with omprun), the condition may have resulted from using the omprun –swapready option with improperly configured or improperly wired Genlock or Swap Ready cables.
For more information about this problem and a workaround, see the OpenGL Multipipe release notes.
While there could be many reasons for slow rendering, ensure that you used the omprun command to start your OpenGL application, in particular, if you are using the DMX X proxy layer. Failure to use the omprun command under DMX will cause the application to draw to all screens using the slower GLX indirect rendering support in DMX instead of the OpenGL direct rendering provided through the omprun command. Use the omprun command to achieve the best rendering performance for single pipe (“multipipe-unaware”) applications under DMX.
For other performance optimization suggestions, see Chapter 4, “Optimizing Performance”.
To achieve the best performance with multipipe applications, see the section “Running Multipipe Applications in Multipipe-Aware Mode” in Chapter 3.
If X applications are not behaving correctly or fail to start, consider the cases described in the following subsections:
Verify that the application is not using unsupported X extensions. Unfortunately, there is no way to accurately list the extensions an application uses. However, the following examples using the nm command give some hints about the extensions used. If an application is using an X extension, this can usually be detected by searching for occurrences of the string extension or for the name of a particular extension. The xdpyinfo command lists the names of extensions supported by the X server.
Indicating the use of the DOUBLE-BUFFER extension (DBE), the following example shows that command gmemusage calls XdbeQueryExtension:
# nm /usr/sbin/gmemusage | grep -i extension [116] |2143299120| 436|FUNC |GLOB |DEFAULT |UNDEF| XdbeQueryExtension |
For a list of X extensions supported by SGI Xinerama, see the Xinerama(3X11) man page. For a list of X extensions supported by DMX, see the Xdmx(1) man page in the directory /usr/share/omp/doc/user. Applications that use unsupported X extensions may be run in aware mode by running them with the omprun –aware option so that they bypass the X proxy layer.
The SGI Xinerama versions in IRIX 6.5.11 and earlier use a protocol that is incompatible with versions of SGI Xinerama released in IRIX 6.5.12 and later. If an application links (dynamically at run time or statically at compile time) with X client libraries that came with IRIX 6.5.11 and earlier and then attempts to make SGI Xinerama calls to an X server from IRIX 6.5.12 or later, the behavior will be undefined. Similarly, linking with X client libraries from IRIX 6.5.12 or later and connecting to an X server from IRIX 6.5.11 or earlier will also yield undefined behavior.
Since the OpenGL Multipipe layer calls XineramaQueryVersion, it is able to reliably detect and report this server-client version incompatibility.
If you encounter this protocol incompatibility, the workaround is to use a client library and server that both support the same SGI Xinerama version—that is, use a client library and X server from the same IRIX version. More simply stated, if you are connecting to a remote display that has SGI Xinerma enabled, ensure that both the local and remote hosts are running the same version of IRIX.
See the Xinerama(3X11) and XineramaQueryVersion(3X11) man pages for more details.
| Note: This section pertains to you only if you use the DMX X proxy layer. |
This can occur if you start an application on one of DMX's backend displays without using omprun –aware—for example, if your DISPLAY environment variable is set to :0.0 and the DMX proxy is managing display :1. The application will run on :0.0, a backend (“aware”) display, but because it was not started properly in aware mode (using omprun –aware), the window will not be managed by the window manager running under DMX. Consequently, it may be “pushed” behind the DMX root window. Exiting the DMX session will reveal the application window. To avoid this problem, open the application in aware mode using omprun –aware app_name.
| Note: This section pertains to you only if you use the DMX X proxy layer. |
This problem can manifest itself in many ways:
An apparent X error may appear in the output of the application.
A window may suddenly disappear behind the DMX root window.
The command omprun may output the following message:
DISPLAY does not point to a meta display.
This problem originates from a program explicitly requesting an X display connection to :0.0 even if the DISPLAY environment variable contains a different default display string, which is usually the case when running DMX.
The workaround is for DMX to run as display :0 and to have the backend X servers use other display numbers so that when the application tries to open :0.0, it correctly connects to the DMX meta display on :0 instead of a backend display by accident. To have other X servers use other display numbers so that :0 is available for DMX, do the following:
Open file /var/X11/xdm/Xservers.
Replace the instance of :0 with another display number (for example, :1 or :5).
Restart graphics.
Remove the /tmp/.X11-unix/X0 Unix socket file if it exists.
The existence of this file will cause ompstartdmx to start DMX on a display other than :0.
Now when you run ompstartdmx, by default it will use the first available X display number, which should now be :0.
To run X servers with SGI Xinerama enabled simultaneously with regular X servers (that is, with SGI Xinerama disabled) on the same machine, add +xinerama or –xinerama to the existing arguments in the file /var/X11/xdm/Xservers. This allows you to override the chkconfig xinerama flag. Refer to the Xsgi(1) and xdm(1) man pages for more information.
| Note: This section pertains to you only if you use the IRIX window manager 4Dwm. |
Setting a large image as the root window background image will result in having a tile image displayed across the screens. You can overcome this problem by the using 4Dwm desktop features as follows:
Set the following line in the $HOME/.Sgiresources file:
4Dwm*SG_useBackgrounds: True
Create the background image in the xpm (X Pixmap) file format. The fewer colors used in that image, the less impact it will have on the colormaps used by other applications.
Copy the /usr/lib/X11/system.backgrounds file to $HOME/.backgrounds.
Edit $HOME/.backgrounds and, using the syntax of /usr/lib/X11/system.backgrounds as a template, add a new setting for your image.
Select your background from the GUI background program.
See the 4Dwm(1X) man page for more information.
| Note: This section pertains to you only if you use the DMX X proxy layer. |
This occurs as a result of the lack of overlay visual support in DMX. See “Overlay Windows Support in DMX” in Chapter 5.
When an X proxy layer is used to overlap screen regions on an edge-blended display or a compositor-based system, the cursor will seem to disappear when it enters the overlapped or uncomposited regions of the display. In X, a mouse belongs to one screen of the X server at a time. Therefore, it is normally not possible to draw the mouse multiple times (on different screens) in the overlap region.
To prevent the cursor from disappearing in these cases, you need to create additional or duplicate cursor images (not real cursors) where two or more screens overlap. There is still just one real cursor position on the display. The way you do this depends on your X proxy layer, SGI Xinerama or DMX. See the section “Enabling Duplicate Cursor Images in Overlap Regions” in Chapter 3.
If the application supports the use of POSIX threads (pthreads), use the pthread threading model with OpenGL Multipipe.
To force the use of the pthread threading model, use the -pthread option when starting the application, as shown in the following:
$ omprun -pthread app_name |
With no arguments, ompstartdmx starts only an xterm on Linux. To start GNOME or KDE under DMX, use the ompstartdmx –session option. OpenGL Multipipe also installs some special GNOME and KDE login options that will appear in the gdm login screen. See ompstartdmx –help and section “Initializing DMX” in Chapter 3.
The following subsections detail problems with aware window management and workarounds:
For windows of aware applications to be managed, first start the aware window manager, then start the desired application in aware mode. If the reverse is done, the windows will not be able to be manipulated.
| Note: This section pertains to you only if you use the IRIX window manager 4Dwm or its Xinerama-aware variant omp4Dwm. |
Under SGI Xinerama, if desktop background images do not appear when the start_ompwm script is used to start omp4Dwm, you must enable the SG_UseBackgrounds resource for 4Dwm. This can be done through an X resource file or on the start_ompwm command line, as shown in the following command entries:
$ tellwm quit $ start_ompwm -xrm “*SG_UseBackgrounds: True” |
If you started DMX as the X proxy layer using ompstartdmx, 4Dwm is started by default. If you need to explicitly start 4Dwm with proper background images under DMX, you may do so by entering the following:
$ tellwm quit $ ompwrapwm 4Dwm -xrm “*SG_UseBackgrounds: True” |
| Note: This section pertains to you only if you use the SGI Xinerama X proxy layer. |
A number of known mouse pointer and keyboard focus issues arise with aware windows that reside on screens other than physical screen 0—that is, on any of the physical screens 1.. n that SGI Xinerama is managing. Events (mouse clicks, keyboard strokes, etc.) are sometimes generated as though the mouse were on screen 0 instead of on the correct screen (1.. n). This frequently occurs when a popup menu of an aware window is open and the mouse is clicked outside the menu.
To avoid this particular problem, close the popup menu first (for example, by using a keyboard shortcut to close the menu) then click the mouse.
Aware windows bypass the X proxy layer and are only created on one physical screen, but when an aware window manager manages an aware window, it creates window frames on each screen. The frames are multipipe-transparent—that is, drawn on every screen. However, the application window within the frame is multipipe-aware—that is, drawn only on one screen.
Since an aware application window is not drawn on every screen, the multipipe-transparent frame behind the application window will “show through” in screen-overlap regions on an edge-blended display.
To work around this problem, you may want to run your application in a window of a size and position such that it does not overlap any of the screen-overlap regions of the display. Alternatively, you may want to temporarily quit the aware window manager.
If you are using DMX as your proxy X layer, note that the ompstartdmx script sets the environment variable SGIOMP_META_DISPLAY, which is important for running applications in aware mode under DMX. If you are starting an application in aware mode from a remote shell or other login shell, this variable will not be set. If unexpected results occur when you try to run an application in aware mode, ensure that the SGIOMP_META_DISPLAY variable is set to the DMX display (often :1).