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.
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.
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.
Per-screen visual attributes and capabilities can be adjusted by modifying the file /etc/X11/XF86Config.
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 are 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 API.
Recent versions of these APIs may be integrated with 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.
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.
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 uses the LD_PRELOAD environment variable to force an application to load the OpenGL Multipipe library libOMPmaster.so instead of the standard OpenGL library, libGL.so.
For security reasons, Linux may ignore this environment variable for set-user-ID programs. Therefore, OpenGL Multipipe is not able to intercept and distribute OpenGL calls to all pipes. As a workaround, you can run the application using the GLX indirect rendering support in DMX. This, of course, has a performance price. To do so, set the GLFORCEDIRECT environment variable to n before running the application.
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.
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.
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.
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 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.
X extensions supported on Silicon Graphics Prism systems but not by DMX include the following:
DOUBLE-BUFFER ReadDisplay FontCache SGI-SCREEN-CAPTURE MIT-SCREEN_SAVER SGI-VIDEO-CONTROL MIT-SHM TOG-CUP MIT-SUNDRY-NONSTANDARD X-Resource RANDR XFree86-Misc READDISPLAY XFree86-VidModeExtension RENDER XVideo |
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.
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.
This occurs as a result of the lack of overlay visual support in DMX. See “Overlay Windows Support in DMX” in Chapter 6.
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. 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.
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.
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).