DIGITAL Open3D Version 4.7 for DIGITAL UNIX Release Notes March 1998 Digital Equipment Corporation Maynard, Massachusetts March 1998 Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Digital or an authorized sublicensor. Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with this description. Copyright c Digital Equipment Corporation 1998. All rights reserved. The following are trademarks of Digital Equipment Corporation: AlphaServer, AlphaStation, DEC, DEC PHIGS, DEC Open3D, DECwindows, Digital, DIGITAL Open3D, DIGITAL PHIGS, OpenVMS, PowerStorm, TURBOchannel and the Digital logo. The following are third-party trademarks: Motif is a registered trademark of Open Software Foundation, Inc. OpenGL is a registered trademark of Silicon Graphics, Inc. PostScript and Display PostScript are registered trademarks of Adobe Systems, Incorporated. UNIX is a registered trademark in the United States and other countries licensed exclusively through X/Open Company Ltd. X Window System is a trademark of the Massachusetts Institute of Technology. 1 CHAPTER 1 PRODUCT INSTALLATION OVERVIEW 1 1.1 REQUIRED LICENSE 2 1.2 PREREQUISITE SOFTWARE 2 1.3 PROBLEM REPORTING 2 1.4 INSTALLING DIGITAL OPEN3D ON DIGITAL UNIX SYSTEMS 2 1.4.1 INSTALLING THE BASE SUBSET 2 1.4.2 MODIFICATIONS TO /USR/VAR/X11/XSERVER.CONF 2 1.5 ALTERNATE CONSOLE 5 2 CHAPTER 2 NEW WITH THIS RELEASE 6 2.1 NEW HARDWARE 6 2.1.1 NEW GRAPHICS OPTIONS 6 2.1.2 NEW WORKSTATIONS SUPPORTED 6 2.1.3 ALPHASERVER 4100 6 2.2 NEW SOFTWARE 6 2.3 INTERNET DISTRIBUTION AND INSTALLATION 6 2.4 PROBLEMS FIXED IN DIGITAL OPEN3D VERSION 4.7 7 2.4.1 LINES DRAWING OUTSIDE OF WINDOW BORDERS 7 2.4.2 ENABLING SAVE UNDERS AND BACKING STORE FOR 4DXXT DEVICES 7 2.4.3 MEMORY LEAK WITH POWERSTORM 4DXXT DEVICES 7 2.5 KNOWN PROBLEMS 7 2.5.1 MAXIMUM RESOLUTION OF THE POWERSTORM 4D60T GRAPHICS BOARDS 7 2.5.2 PROBLEM WITH DISKLESS MANAGEMENT SYSTEM (DMS) SUPPORT 8 2.5.3 INDIRECT RENDERING WITH POWERSTORM 4DXXT DEVICES 8 2.5.4 POLYGON DRAWING PROBLEMS AFTER REPEATED ZOOM WITH POWERSTORM 4DXXT 8 2.5.5 LARGE TEXTURES IN DISPLAY LISTS WITH POWERSTORM 4DXXT DEVICES 8 2.5.6 X SERVER CRASHES WHEN USING OVERLAYS 8 2.5.7 WINDOW MOVEMENT LAGGING MOUSE MOVEMENT IN 4D40T 8 2.5.8 SLOW DRAGGING OF OPAQUE WINDOWS 8 2.5.9 OPENGL SAMPLE AND EXAMPLE PROGRAMS MAY NOT BUILD CORRECTLY 8 2.5.10 FRONT VS. BACK ORIENTATION OF POLYGON FACES (ZLX DEVICES ONLY) 9 2.5.11 MISSING TRIANGLES ON ZLXP-E3 AND POWERSTORM 4D20 9 2.5.12 VGA JUMPER ON POWERSTORM 3D30 AND 4D20 9 2.5.13 CONSOLE DISPLAY ON MULTIHEAD SYSTEMS 9 2.5.14 PEX IVP FAILURE ON ZLX-E1, ZLXP-E1 AND POWERSTORM 3D30 10 2.5.15 MONITOR RESOLUTION AND FREQUENCY 10 2.5.16 SLOW WINDOW DRAGGING ON ZLXP-L OPTIONS 10 2.5.17 CLIPPED EDGES ON ZLX-E AND ZLXP-E 10 3 CHAPTER 3 RELEASE INFORMATION FOR POWERSTORM 4D40T, 4D50T, 4D51T, 4D60T 11 3.1 PRODUCT SUMMARY 11 3.2 PREREQUISITE HARDWARE 11 3.3 AFTER THE INSTALLATION 11 3.4 KNOWN RESTRICTIONS 11 3.4.1 GENERAL RESTRICTIONS 11 3.4.2 OPENGL RESTRICTIONS 12 3.4.3 PERFORMANCE AND SYSTEM CHARACTERISTICS 13 3.4.4 POWERSTORM 4D40T, 4D50T, 4D60T SUPPORTED VIDEO MODES 15 4 CHAPTER 4 CORE SERVER FUNCTIONALITY FOR GRAPHICS ACCELERATORS 17 4.1 3D GRAPHICS ACCELERATION ON ZLX-E1, ZLXP-E1 AND POWERSTORM 3D30 17 4.2 RGB COLOR INTERPOLATION AND DITHERING ON ZLX-E1, ZLXP-E1 AND POWERSTORM 3D30 17 4.2.1 ACCESS THROUGH OPENGL 18 4.2.2 ACCESS THROUGH PEX 18 4.3 3D GRAPHICS ACCELERATION ON ZLX-E2 AND ZLXP-E2 19 4.4 3D GRAPHICS ACCELERATION ON ZLX-E3, ZLXP-E3, AND POWERSTORM 4D20 20 4.5 SELECTING DEFAULT VISUAL TYPES 20 4.5.1 MOTIF WINDOW MANAGER DEFAULT VISUAL TYPES 20 4.5.2 CDE WINDOW MANAGER DEFAULT VISUAL TYPES 21 4.6 ZLX-L SERIES 21 4.7 OVERLAY SUPPORT 21 4.7.1 TECHNICAL BACKGROUND 21 4.7.2 MOTIF WINDOW MANAGER FOR OVERLAYS 22 4.8 MULTIPLE COLORMAPS 22 4.9 DECSTEREO EXTENSION 23 4.9.1 QUERY AND LOAD THE DECSTEREO EXTENSION 23 4.9.2 QUERY THE DECSTEREO EXTENSION VERSION 23 4.9.3 SET THE STEREO MODE 24 4.9.4 QUERY THE STEREO MODE 24 5 CHAPTER 5 KNOWN RESTRICTIONS AND PROBLEMS 25 5.1 OPERATING SYSTEM RESTRICTIONS 25 5.1.1 TURNING BLOCKMODE I/O ON IN TURBOCHANNEL-BASED SYSTEMS 25 5.2 OVERLAY WINDOW MANAGER RESTRICTIONS 25 5.3 X RESTRICTIONS 25 5.3.1 BACKING STORE SUPPORT 25 5.3.2 SAVE UNDER SUPPORT 26 5.3.3 MULTIHEAD SUPPORT 26 5.4 PEX RESTRICTIONS 27 5.4.1 SUPPORT OF MIT PEXLIB FUNCTIONS 27 5.4.2 NO PEX SUPPORT FOR POWERSTORM 3D10, HX OR POWERSTORM 4DXXT GRAPHICS 27 5.4.3 TRANSPARENCY USING PEX 27 5.4.4 PEXQUADMESH COMPATIBILITY 27 5.4.5 EDGE FLAGS AND SHARED EDGES 28 5.5 OPENGL RESTRICTIONS 28 5.5.1 NON-DIGITAL EXAMPLE IMAKEFILES 28 5.5.2 ANTIALIASED OPERATIONS 29 5.6 ZLX-M AND ZLX-L RESTRICTIONS 29 5.6.1 DRAWING CONVEX POLYGONS 29 5.6.2 MULTIBUFFER SUPPORT 29 5.6.3 3D-SPECIFIC DISPLAY AND RENDERING CORRUPTIONS 29 5.6.4 2D SPECIFIC DISPLAY AND RENDERING CORRUPTIONS 31 5.7 ZLX-E, ZLXP-E, POWERSTORM 3D30 AND 4D20 RESTRICTIONS 31 5.7.1 DEC 3000 MODEL 300 SERVER CRASHES 31 5.7.2 3D DISPLAY CORRUPTION AND RENDERING RESTRICTIONS 31 5.8 PXG RESTRICTIONS 32 5.9 MULTIHEAD ZLX CONFIGURATIONS 32 6 CHAPTER 6 APPLICATION NOTES FOR OPENGL STEREO RENDERING FOR POWERSTORM 4D40T, 4D50T, 4D51T AND 4D60T 34 6.1 STEREO SUPPORT 34 6.2 ENABLING STEREO FROM AN APPLICATION 34 6.3 SUPPORTED HARDWARE 35 6.4 SUPPORTED SCREEN RESOLUTIONS AND REFRESH RATES 35 6.5 SUPPORTED VISUALS 37 6.6 BACKING STORE 37 6.7 PERFORMANCE 37 6.8 LEFT AND RIGHT CONSTRUCTION PLANES 37 6.9 COMMON QUESTIONS 38 6.10 APPLICATION EXAMPLE 39 Preface This document contains the release notes for DIGITAL Open3DT Version 4.7 for DIGITAL UNIXT. Release notes are supplied in both ASCII and PostScriptr format and are located, respectively, in the following locations: ú /usr/lib/OPEN3D/open3d470.release_notes ú /usr/lib/OPEN3D/open3d470.release_notes.PS Associated Documents The following hardcopy documentation accompanies this release: DIGITAL Open3D Installation Guide for DIGITAL UNIX Systems DIGITAL Open3D IDL User Guide DIGITAL Open3D PEXlib C Binding Reference Manual Using OpenGL 1 CHAPTER 1 PRODUCT INSTALLATION OVERVIEW DIGITAL Open3DT Version 4.7 for DIGITAL UNIXr supports the following devices: ú PCI-based based PowerStormT series NOTE The ZLX-E, ZLX-M, and ZLX-L devices are no longer supported by DIGITAL Open3D. There is bug-fix support available for current versions of the DIGITAL UNIX operating system. However, no software enhancements are available for these devices. Device support for future versions of UNIX will be shipped for a limited time. The ZLXp-E devices are no longer supported by DIGITAL Open3D. There is bug-fix support available for current versions of the DIGITAL UNIX operating system. However, no software enhancements are available for these devices. Device support for future versions of UNIX will be shipped for a limited time. The Freedom Seriesr devices (3150, 3250 and 3400) are no longer supported by DIGITAL Open3D This release supports the following specific graphics options: ú ZLXp-L Series (ZLXp-L1, ZLXp-L2) ú PowerStorm Series (PowerStorm 3D30, PowerStorm 4D20, PowerStorm 4D40T, PowerStorm 4D50T, PowerStorm 4D60T) ú Software-only OpenGL support for PowerStorm 3D10 This release contains optional support for the following: ú DEC PEXlib API ú MIT PEXlib API ú OpenGLr ú X Multibuffering Extension ú PCM/IDL (dials and buttons) ú DECStereo X Extension ú Overlay Support via Extended Visuals NOTE Beginning with the next release of Open3D, PEX, the DEC PEXlib and the MIT PEXlib will no longer be supported. They will continue to be shipped for one or more future releases. After that time, the libraries and supporting software will only be available from older media, and run with older releases of Open3D. Please see the Software Product Description (SPD) 45.07.22 for exact options supported in this release of DIGITAL Open3D. 1.1 Required License DIGITAL Open3D software requires a DIGITAL Open3D Product Authorization Key (PAK) for 3D server operation. This PAK should come in hardcopy with this software, and should be registered before you install DIGITAL Open3D. If you do not register the PAK before starting the software, the server will run in 2D mode only (no PEX or OpenGL server support). 1.2 Prerequisite Software You can install DIGITAL Open3D Version 4.7 only on systems that are running DIGITAL UNIX Version 4.0d. Before installing DIGITAL Open3D Version 4.7, you must remove all previous versions from the system. After you have installed this version, if you upgrade or reinstall the operating system version, you must first deinstall DIGITAL Open3D. Once the operating system change has been made then reinstall DIGITAL Open3D. In order to use the PowerStorm 4D51T, the workstation or server must have the firmware level of the SRM Console of at least 6.7-250. If newer firmware is necessary, it may be obtained from the following WWW site: ftp://ftp.digital.com/pub/DEC/Alpha/firmware/index.html 1.3 Problem Reporting Problems should be reported using the standard SPR mechanism. 1.4 Installing DIGITAL Open3D on DIGITAL UNIX Systems When installing DIGITAL Open3D, you should note the following: The DIGITAL Open3D Extensions Clause is required for all graphics options supported by DIGITAL Open3D. In multihead configurations you must edit the configuration file and rebuild the kernel manually. Please refer to the installation guide for more details. 1.4.1 Installing the BASE Subset You must install the BASE subset to install any graphics options supported by the DIGITAL Open3D kit. Note that the supported graphics options are enabled only after you install the kit. You may have to edit some server configuration files before rebooting the system. See Section 1.4.2 for more information on editing the configuration files. 1.4.2 Modifications to /usr/var/X11/Xserver.conf The Xserver configuration file /usr/var/X11/Xserver.conf contains startup information for the server. The X server reads and acts on certain options and information in this file. 1.4.2.1 DIGITAL Open3D Extensions Clause The BASE subset installation adds the DIGITAL Open3D extensions clause, which causes the Xserver to load these extensions. If you do not want the installation to load some of the extensions, remove the appropriate lines from the /usr/var/X11/Xserver.conf file. The DIGITAL Open3D extensions clause is as follows: ! Start Open3D Extensions Lis ! extensions < < _dec_PEX lib_dec_PEX.so __PEX_LoadInit < _dec_3dlib lib_dec_3dlib.so ThreeDInitProc > < _dec_x3d_pex lib_dec_x3d_pex.so PexExtensionInit > > < directx libdirectx.so DirectXInit > < _dec_GLX lib_dec_GLX.so __GLX_LoadInit GLX < _dec_opengl lib_dec_opengl.so GLExtensionInit PMAGC-AA > < _dec_opengl lib_dec_opengl.so GLExtensionInit PMAGC-BA > < _dec_opengl lib_dec_opengl.so GLExtensionInit PMAGC-DA > < _dec_opengl lib_dec_opengl.so GLExtensionInit PMAGC-EA > < _dec_opengl lib_dec_opengl.so GLExtensionInit PMAGD-BA > < _dec_opengl lib_dec_opengl.so GLExtensionInit PMAGD-AA > < _dec_opengl lib_dec_opengl.so GLExtensionInit PMAGD > < _dec_opengl lib_dec_opengl.so GLExtensionInit PMAG-BB > < _dec_opengl lib_dec_opengl.so GLExtensionInit PMAGB-BA > < _dec_opengl lib_dec_opengl.so GLExtensionInit ZLXp-L1 > < _dec_opengl lib_dec_opengl.so GLExtensionInit ZLXp-L2 > < _dec_opengl lib_dec_opengl.so GLExtensionInit ZLXp-L1@5 > < _dec_opengl lib_dec_opengl.so GLExtensionInit ZLXp-L2@5 > < _dec_opengl lib_dec_opengl.so GLExtensionInit p00041011 > < _dec_opengl lib_dec_opengl.so GLExtensionInit ZLXp-EV5 > < _dec_opengl lib_dec_opengl.so GLExtensionInit ZLXp2-EV4 > < _dec_opengl lib_dec_opengl.so GLExtensionInit ZLXp2-EV5 > < _dec_sampleGL lib_dec_sampleGL.so __glXExtensionInit p00e01091 > < _dec_sampleGL lib_dec_sampleGL.so __glXExtensionInit p00e11091 > < _dec_sampleGL lib_dec_sampleGL.so __glXExtensionInit p00e21091 > < _dec_sampleGL lib_dec_sampleGL.so __glXExtensionInit p00e31091 > < _dec_sampleGL lib_dec_sampleGL.so __glXExtensionInit p00e41091 > < _dec_sampleGL lib_dec_sampleGL.so __glXExtensionInit p00e51091 > < _dec_sampleGL lib_dec_sampleGL.so __glXExtensionInit p00eb1091 > > < extMultibuf libextMultibuf.so MultibufferExtensionInit > < _dec_glXDECpeer lib_dec_glXDECpeer.so InitglXDECExtension DEC-PEER-GLX > > ! ! End Open3D Extensions List If the extensions clause is not in the file Xserver.conf, the server will not load the 3D extensions. 1.4.2.2 DECStereo Extension Load For the devices which are stereo capable, you must load the DECStereo extension at server initialization. To load this extension, add the following line to the extensions clause of the /usr/var/X11/Xserver.conf file: ! Start O3DDWSSTEREO Extensions List extensions < < _dec_Stereo lib_dec_Stereo.so DECStereoExtensionInit > > ! End O3DDWSSTEREO Extensions List If you do not include this line in the extensions clause, stereo for these graphics options will be disabled. (For some options, this line may already be in the Xserver.conf file.) 1.4.2.3 Using the Software-only Version of OpenGL By default, the DIGITAL Open3D installation modifies the /usr/var/X11/Xserver.conf file to load the hardware-accelerated OpenGL software. You can, however, use a software-only version. You must load a software-only version of the OpenGL server extension to use OpenGL with the PowerStorm 3D10 devices. NOTE The software-only version of OpenGL operates correctly with graphics devices other than the PowerStorm 3D10; however, its OpenGL performance is significantly lower than the OpenGL versions which make direct use of the graphics hardware. Therefore DIGITAL recommends you use the software-only version only with the PowerStorm 3D10. The software-only version of OpenGL cannot be configured to run on PowerStorm 4D40T, 4D50T, and 4D60T. These devices automatically configure the device- specific OpenGL code within the server. As only one version the OpenGL server extension can be loaded at a time, you must modify Xserver.conf before running OpenGL. 1.4.2.3.1 Using the Software-Only Version of OpenGL with PowerStorm 3D10 Devices To use the software-only version of OpenGL with the PowerStorm 3D10, modify the Xserver.conf file to include the following line in the DIGITAL Open3D extensions clause: < _dec_sampleGL lib_dec_sampleGL.so __glXExtensionInit S3TRIO > 1.4.2.3.2 Using the Software-Only Version of OpenGL with Preconfigured Devices other than the PowerStorm 3D10 To use the software-only version of OpenGL with devices that are already preconfigured (devices other than the PowerStorm 3D10), modify Xserver.conf as follows: 1. Delete the following line from the DIGITAL Open3D extensions clause: < _dec_opengl lib_dec_opengl.so __glXExtensionInit p00041011 > 2. Add the following line to the DIGITAL Open3D extensions clause: < _dec_opengl lib_dec_sampleGL.so __glXExtensionInit p00041011 > 1.5 Alternate Console Instead of using the graphics display as the system console, it is possible to attach an external ASCII terminal to serial port 1 and have console interactions take place on that device. This is done at the boot prompt (>>>). To use an external terminal, the commands are: >>> set console serial >>> init To return to the graphics display as console, the commands are: >>> set console graphics >>> init 2 CHAPTER 2 NEW WITH THIS RELEASE This section describes new and changed functionality that is being released for the first time with DIGITAL Open3D Version 4.7. NOTE Beginning with the next release of Open3D, PEX, the DEC PEXlib and the MIT PEXlib will no longer be supported. They will continue to be shipped for one or more future releases. After that time, the libraries and supporting software will only be available from older media, and run with older releases of Open3D. 2.1 New Hardware 2.1.1 New Graphics Options The PowerStorm 4D51T is now supported for additional workstations with this release. See the Software Product Description (SPD) for the machines on which this graphics option is supported. 2.1.2 New Workstations Supported New variations of existing workstation models, involving higher CPU speeds, are now supported. See the Software Product Description (SPD) for the graphics options that are supported on these machine. 2.1.3 AlphaServer 4100 Limited configurations of the PowerStorm 4D20 and PowerStorm 4D51T on an AlphaServer 4100 have been qualified running X and OpenGL software. However, no PEX software has been tested on these machines; no support of this older API is available or planned. 2.2 New Software No new software is included for the first time in this release. 2.3 Internet Distribution and Installation The DIGITAL Open3D software will be made available via the Internet. Please use the following procedure to locate the kit. 1.Using a web browser, access URL http://www.service.digital.com/open3d/. 2.Pick Open3D Version 4.7 for DIGITAL UNIX Kit to ftp the kit. 3.Use tar to extract the files from O3Dxxxx.tar into a directory. 4.Use setld to load the kit. In addition to the released software, this site also contains pointers to these release notes and to later, field-test versions of software. The site http://www.service.digital.com/ also contains pointers to other software and software patches, ECO's to Opend3D.) 2.4 Problems Fixed in DIGITAL Open3D Version 4.7 2.4.1 Lines Drawing Outside of Window Borders There was a problem on the PowerStorm 4DxxT devices with lines drawn outside the windows and wrapping around the screen. This has been fixed. 2.4.2 Enabling Save Unders and Backing Store for 4DxxT Devices The default condition of all graphics devices except the PowerStorm 4DxxT is to enable both backing store and save unders. For the PowerStorm 4DxxT devices, the default condition remains to disable backing store and save unders. In order to enable backing store and save unders, add these arguments to /var/X11/Xserver.conf: " +e3bs +e3su ". The line to edit is near the end of the file, where the arguments ("args") are added, and looks like this: ! you specify command line arguments here args < -pn > Add this string: "-I +e3bs +e3su" to the end of the last line. The resulting "args" lines look like this: ! you specify command line arguments here args < -pn -I +e3bs +e3su > After making this edit, shutdown the machine and re-boot. 2.4.3 Memory Leak with PowerSTorm 4DxxT Devices A memory leak in the X server has been reported for the PowerStorm 4DxxT devices. This has been fixed. 2.5 Known Problems 2.5.1 Maximum Resolution of the PowerStorm 4D60T Graphics Boards In a later section of these Release Notes, the list of supported resolutions for the PowerStorm 4DxxT devices is given. However, the higher resolutions defined for the 4D60T (anything above 1600x1200) cannot actually be set using the parameters -screen[] [x]. This will be fixed in the next release. 2.5.2 Problem with Diskless Management System (DMS) Support The Open3D software installs files in directories that are considered "write only" by the Diskless Management System (DMS) standards. Operation of Open3D devices in a DMS environment may not be correct. This is under review for a change in a future release. 2.5.3 Indirect Rendering with PowerStorm 4DxxT Devices One test in a large test suite has failed when using PowerStorm 4DxxT devices in indirect rendering mode. However, this is not the usual or recommended mode for using these devices because the performance is substantially lower than with direct rendering. This isolated test failure is under investigation. 2.5.4 Polygon Drawing Problems After Repeated Zoom with PowerStorm 4DxxT One customer has reported problems with polygon drawing after repeated zooming of an image. In some cases, the polygons draw outside the window. This will be fixed in the next release. 2.5.5 Large Textures in Display Lists with PowerStorm 4DxxT Devices One customer has reported a problem with large textures (hundreds of megabytes) being used in display lists. The resultant display can be all white, or the X connection can be lost. If the same actions are taken in immediate mode, there is no problem. This is under investigation. 2.5.6 X Server Crashes When Using Overlays One customer has created a new user interface that makes extensive use of overlays. The beta version of this is crashing the X server with several graphics options that provide hardware overlays. This is under investigation. 2.5.7 Window Movement Lagging Mouse Movement in 4D40T A delay of approximately one second has been reported when dragging a window with the PowerStorm 4D40T. This can be improved by inserting this line in the startup file ($HOME/.Xdefaults) for the window manager: *freezeOnConfig: True 2.5.8 Slow Dragging of Opaque Windows There have been reports that dragging opaque windows on PowerStorm 4DxxT systems is slow. This can only be improved by changing window to drag in Outline Mode. 2.5.9 OpenGL Sample and Example Programs May Not Build Correctly The previous Open3D release contained several kitting errors which prevented correct compilation of the OpenGL sample and example programs. While most of these have been fixed, a few remain in this kit and are noted here. 2.5.9.1 Missing Source Files and Directories The location of the glut library routines is incorrectly created as /usr/examples/GL/glut; this should be /usr/examples/GL/libglut. The contents of this directory are incomplete and a new libglut.so cannot be built from them. However, the existing program /usr/shlib/libglut.so will work correctly as- shipped. There is no glx_samples directory. There are missing files in the widgets example directory /usr/examples/GL/widgets, making a build impossible. 2.5.9.2 Incomplete Makefiles The make Makefiles will not build all programs automatically. The ones that do not build automatically can be built by moving to the correct subdirectory and manually invoking the Imake script. 2.5.10 Front vs. Back Orientation of Polygon Faces (ZLX devices only) Under certain conditions, the computation to determine whether an OpenGL polygon is front-facing or back-facing may be incorrect. This usually happens with objects created by a "reflection operation". A fix for this has been included in this release. The previous operation of OpenGL code is unchanged because certain applications have compensated for this error in their software. To take advantage of the newer computation, edit the /usr/lib/X11/Xserver.O3D.conf file and insert the following line: DoFrontBackTestTheOpenGLWay True 2.5.11 Missing Triangles on ZLXp-E3 and PowerStorm 4D20 One of the benchmark applications showed missing triangles on a surface during field testing of the DIGITAL Open3D Version 4.3 software. Other tests showed no such problems. This is under investigation. 2.5.12 VGA Jumper on PowerStorm 3D30 and 4D20 For PowerStorm 3D30 and 4D20 multihead systems, only one of the graphics boards should have the VGA jumper set to the VGA position. 2.5.13 Console Display on Multihead Systems In general, the console display output in multihead systems will appear on the monitor attached to the graphics card installed in the lowest-numbered slot in the workstation. (Refer to the manuals that came with the workstation to determine the slot-numbering order.) For PowerStorm 3D30 and 4D20 multihead systems, console display will appear on the graphics board with the VGA jumper set regardless of the option slot it is in. Once the boot process is complete, however, the login box will appear on "head 0"-the graphics board in the lowest numbered slot. Digital recommends installing the graphics card with the VGA jumper set in the lowest numbered option slot on the workstation. 2.5.14 PEX IVP Failure on ZLX-E1, ZLXp-E1 and PowerStorm 3D30 When using the Common Desktop Environment, the PEX installation verification program (IVP) may fail with a "colormap allocation failure" for ZLX-E1, ZLXp-E1 and PowerStorm 3D30 devices. This does not indicate a problem with the installation. 2.5.15 Monitor Resolution and Frequency The ZLXp-L series displays data at only one resolution and frequency: 1280x1024 at 72Hz. Attempting to use a monitor that is not capable of supporting this resolution and frequency will not work. The ZLXp-L boards are capable of supporting other resolutions and frequencies, but the software necessary to effect the change is not available in this release of DIGITAL Open3D. This software will be available in a later release of DIGITAL Open3D. 2.5.16 Slow Window Dragging on ZLXp-L Options Clicking and dragging an entire window will cause the window to lag behind the cursor movement. The workaround for this problem is to drag windows in outline mode. 2.5.17 Clipped Edges on ZLX-E and ZLXp-E Most primitives with edges enabled (including hollow/line mode) will not be rendered correctly when they are clipped on ZLX-E and ZLXp-E options. 3 CHAPTER 3 RELEASE INFORMATION FOR POWERSTORM 4D40T, 4D50T, 4D51T, 4D60T 3.1 Product Summary DIGITAL Open3D Version 4.7 contains the DIGITAL UNIX graphics support for the AlphaStation PowerStorm models 4D40T, 4D50T, 4D51T and 4D60T. The software has several components: ú Device Dependent Code for the X server 2D graphics support. This piece of code is mainly used for connections over an external network. ú OpenGL Direct Rendered graphics support libraries. These libraries are used by applications written to the OpenGL V1.1 standard. ú Vectored Xlib and Direct Rendered X11. These libraries replace the existing Xlib and increase the performance of X applications when run locally. NOTE There is no PEX support for any of the PowerStorm 4DxxT boards. 3.2 Prerequisite Hardware The AlphaStations which support these devices are listed in the Software Product Description. To get the expected performance from these graphics options, an AlphaStation with a CPU clock-speed of 266 MHz or higher is recommended. 3.3 After the Installation Once the installation of the PowerStorm 4D40T, 4D50T, 4D51T and 4D60T software has been completed, the machine needs to be rebooted. This reboot will enable the PowerStorm 4DxxT graphics devices. 3.4 Known Restrictions This section of the document contains known restrictions with the current software. 3.4.1 General Restrictions These restrictions apply to all applications and graphics interfaces. 3.4.1.1 Applications That Link With Static Libraries Applications which link against the static libraries (.a files) provided in previous releases of DIGITAL Open3D or DIGITAL UNIX, will not work correctly. Applications linking against static libraries should be re-linked to use the shareable object libraries. Future bugfixes and performance optimizations will be automatically available to these applications, without further re-linking. (If an application must be linked against a static library, it must be (re- )linked against a static library from this release of Open3D.) 3.4.1.2 Multihead Support with the PowerStorm 4D40T, 4D50T, 4D51T and 4D60T The PowerStorm 4D40T, 4D50T, 4D51T and 4D60T products are not supported in a system with any other graphics board. However, support is available for two PowerStorm 4D40T graphics boards in the same AlphaStation 600 system. (The PowerStorm boards must be identical, including identical amounts of texture memory.) The default behavior for two PowerStorm 4D40T cards in an AlphaStation 600 is: The console output will go to the monitor attached to the bottom-most card. When the server starts up, screen 0 will be the top-most card. If it is preferable for the console output and screen 0 to be displayed on the same monitor, this can be achieved by disabling the VGA on the bottom-most card via a jumper in the upper left hand corner of the PowerStorm 4D40T graphics card. 3.4.1.3 Backing Store and Save Unders Are Disabled Backing store and save unders are disabled by default. 3.4.2 OpenGL Restrictions This section describes restrictions in the OpenGL software in this release. 3.4.2.1 Applications Coded to Request Indirect Rendering Only The PowerStorm 4D40T, 4D50T, 4D51T and 4D60T graphics boards are specifically optimized to run Direct Rendered OpenGL applications. Some applications have been coded to request Indirect Rendered OpenGL rendering contexts. Those applications will not perform optimally on these graphics boards. By default OpenGL software for PowerStorm 4D40T, 4D50T, 4D51T and 4D60T returns a Direct Rendered OpenGL rendering context whenever the connection is "direct", i.e., when DISPLAY is :0 or direct:0. If necessary, this behavior can be overriden by defining this environment variable: setenv ALLOWINDIRECT 1 3.4.2.2 GLX Pixmap Support No GLXPixmap rendering is supported for contexts marked direct. 3.4.2.3 Texture Image Size Limitation There is a limitation on the Texture Image size is this release: the maximum of either height or width of texture images is 1024. 3.4.2.4 4D Vertex Handling Incorrect in Some Cases There are several cases of 4D vertices that are not handled correctly. 3.4.2.5 MIPMAP Rendering If the range of 1/W (inverse W) values for vertices is very large, then the texture mapping with mipmaps may exhibit some artifacts. 3.4.2.6 GLUT Restrictions The glutIdleFunc(func) call does NOT store the current context along with the function func. When func is called, therefore, the current context is unpredictable. func should always do a glutSetWindow() call before any other drawing operations. 3.4.2.7 Primitives Outside a glBegin/glEnd Block If vertex calls are placed in a display list and executed without first calling glBegin, the server may generate Graphic Engine errors. This can also cause the server to hang, requiring a reinitialization and reboot of the system. This should only happen when there are programming errors, since all drawing is required to be between glBegin and glEnd calls. 3.4.2.8 Antialiasing in Color Index Mode The antialiasing modes (GL_POINT_SMOOTH, GL_LINE_SMOOTH, and GL_POLYGON_SMOOTH) and color index mode do not work correctly together. Flat-shaded lines and polygons do not get drawn. Smooth-shaded objects do get drawn, but they do not use the correct color indicies. 3.4.3 Performance and System Characteristics The PowerStorm 4D40T, 4D50T, 4D51T and 4D60T subsystem is significantly different from other graphics devices provided by Digital. It differs in the following ways: ú Direct Rendering OpenGL. All previous products from Digital only supported indirect rendering. Some applications have been written assuming indirect rendering only. These programs will run on the PowerStorm 4D40T, 4D50T, 4D51T and 4D60T boards, although they will not perform optimally. ú Client Side Display Lists. When OpenGL display lists use direct rendering, these lists are stored in the same address space as the application code and data. When compared with current Digital hardware, the user address space requirements will be higher. However, the overall memory requirements (i.e., the virtual space for the client and the server) should be the same or smaller. The implication is that a larger user virtual address space may be required. ú Direct Rendered X11 2D. Much of the 2D graphics is also direct rendered by default. This gives much better performance when the number of objects provided to xlib routines are small. Some applications have been written to assume a client/server model. These should run without change, although error detection is not provided in the direct rendered X libraries. To get the error detection that the protocol provides, change the DISPLAY environment variable to be 'unix:0' and the application will run without the benefit of direct rendering. For the fastest possible rendering, set the DISPLAY variable to 'local:0' (shared memory transport). 3.4.3.1 Texture Mapping and Performance Many applications use multiple texture maps. It is suggested that applications that require multiple textures be written (or rewritten) to use the OpenGL 1.1 texture object functionality or the Texture Objext Extension. 3.4.3.2 OpenGL Pixmap Performance The OpenGL specification precludes direct rendering to pixmaps. This limits the performance of drawing to GLPixmaps. To use GLPixmaps when running on a local (:0 or direct:0) display, create an indirect rendering conext and set the following environment variable: setenv ALLOWINDIRECT 1 It is recommended that any application that extensively uses GLPixmap drawing be recoded to use drawing to the back buffer. The performance will be significantly better on this and most other OpenGL-based graphics options. 3.4.3.3 RGB Format Previous graphics options from Digital used a non-standard format for 24-plane TrueColor pixel formats call "BGR". In this format, the least significant 8 bits of the pixel correspond to the blue component, while the most significant 8 bits correspond to the red component. The PowerStorm 4D40T, 4D50T, 4D51T and 4D60T graphics option uses the opposite format called "RGB" which allows better performance with OpenGL-based applications. On the PowerStorm 4D60T option, there are two 32-plane RGBA visuals (single and double-buffered) for OpenGL where the most significant 8 bits correspond to the OpenGL "alpha" buffer. In the double-buffered RGBA visual, the color components are double-buffered while the alpha component is single-buffered. Care must be taken to supply the color components of images in the correct order. In particular, the color components of images obtained from other graphics devices may need to be re-ordered. (Applications written to TrueColor that did not specifically look at the visual information to determine the location of the color values may look like red and blue are swapped, i.e., objects that were blue will be red on these graphics options.) NOTE On all PowerStorm 4D40T, 4D50T, 4D51T and 4D60T options running under UNIX, there is also an 8-plane TrueColor visual *not* supported by OpenGL. This visual is in "BGR" format where the least-significant 2 bits are the blue component, the next 3 bits are the green component, and the most significant 3 bits are the red component. 3.4.3.4 Usage of Shared Memory by the PowerStorm 4D40T, 4D50T, 4D51T and 4D60T In order to improve performance, the PowerStorm 4D40T, 4D50T, 4D51T and 4D60T systems make extensive use of shared memory to send information to the server. Shared memory is used for the following types of data: ú X connections when using the DISPLAY :0 ú OpenGL rendering contexts ú Texture map data However, the system imposes a limit on the number of shared memory segments that a process can access concurrently and the total amount of shared memory the system allows. At times, an X client may run up against this limit. If this occurs, client applications will display the following warning: "dxlib warning: server shmget failed" or other errors from applications indicating that they are out of memory when using some of the above types of data. 3.4.4 PowerStorm 4D40T, 4D50T, 4D60T Supported Video Modes The following table lists the supported video modes for the PowerStorm 4D40T, 4D50T, and 4D60T. Supported Video Modes ------------------------------------------------------------ Resolution 4D60T Other 4DxxT (Hor x Ver) Refresh Rate Refresh Rates ----------- --------------- ------------- 1920x1200(a) 60..75; 76* not available 1920x1080(a) 60..75; 60* not available 1600x1280(a) 60..75; 70* not available 1600x1200 60..85; 75* not available 1280x1024 60..85, 66, 72; 75* 60..85, 66, 72; 75* (b) 1152x900 60..110; 76* 60..110; 76* (b) 1024x768 60..115; 75* 60..115; 75* 1024x864 60..140; 60* 60..115; 60* 800x600 60..140, 72; 75* 60..140, 72; 75* 720x400 70 70 640x480 60..150, 72; 75* 60..150, 72; 75* (a) Contrary to some preliminary information, this is currently the highest supported screen resolution of the PowerStorm 4DxxT family of graphics options. Resolutions higher than 1600x1200 are not supported at this time. (b) Supported, but backing store may not be available at this resolution. (See note at end of this section.) Each supported graphics mode can be selected by starting the Xserver with the appropriate command-line arguments. These command line arguments are as follows: ú -screen Selects the desired screen resolution. ú -vsync Selects the desired screen refresh rate. ú -I -e3bpp Selects the desired number of video planes. The `-screen' and `-vsync' options should be used in conjunction with each other. Using the `-vsync' option alone will not work. Using the `-screen' option alone will select the proper screen resolution, but may select an incompatible refresh rate. The `-screen' and `-vsync' options must select one of the supported modes from the above table. Using unsupported combinations of `-screen' and `-vsync' may produce undesirable results. The only possible values that can be used with the `-e3bpp' option are `102' and `128'. Other values are invalid. Note the use of the `-I' argument in conjunction with the `-e3bpp' option. The `- I' argument indicates to the server that all following arguments are device- specific and should be ignored by the device-independent layer of the server. For this reason, device-dependent options, such as `-e3bpp', should come last on the Xserver command line, and should be preceded by a `-I' argument. Only one `- I' argument is neccessary, regardless of the number of device-dependent options. To change the command-line arguments that the Xserver uses, login as root and edit the file /usr/var/X11/Xserver.conf. Search for the following lines in this file, which indicate the command-line arguments: ! Cateye Server args start pn -nice -2 ! Cateye Server args end Append your changes to the arguments already listed, and then restart the server. You may prefer to log in remotely to do this. The default graphics mode for the 4D40T and 4D50T graphics options are 1280x1024 @ 75Hz, in 102-plane mode. This is equivalent to the following command-line options: ! Cateye Server args start pn -nice -2 -screen 1280x1024 -vsync 75 -I -e3bpp 102 ! Cateye Server args end The default graphics mode for the 4D60T graphics option is 1280 x 1024 @ 75Hz, in 128-plane mode. This is equivalent to the following command-line options: ! Cateye Server args start pn -nice -2 -screen 1280x1024 -vsync 75 -I -e3bpp 128 ! Cateye Server args end To run a PowerStorm 4D40T, 4D50T, or 4D60T in 128-plane mode at 1024x768 @ 70Hz, use the following command-line options: ! Cateye Server args start pn -nice -2 -screen 1024x768 -vsync 70 -I -e3bpp 128 ! Cateye Server args end To restore the default graphics mode, simply remove all of the `-screen', `- vsync', and `-e3bpp' options from the command line in `/usr/var/X11/Xserver.conf'. If there are no other device-dependent options, remove the `-I' argument as well. NOTE In order to improve performance, the PowerStorm 4DxxT family of graphics options uses offscreen video memory to provide backing store for certain types of clients. These clients include all OpenGL clients, and X clients that are rendering to the display `:0'. In some graphics modes, there may not be enough offscreen video memory to provide backing store. In cases where backing store is required, switching to a lower resolution or changing from 128-plane mode to 102-plane mode will reserve enough offscreen memory to provide backing store. 4 CHAPTER 4 CORE SERVER FUNCTIONALITY FOR GRAPHICS ACCELERATORS This section describes the functionality available with the ZLX series devices. 4.1 3D Graphics Acceleration on ZLX-E1, ZLXp-E1 and PowerStorm 3D30 The ZLX-E1, ZLXp-E1 and PowerStorm 3D30 options contain a 2 MB frame buffer, of which up to 1280 x 1024 x 8-bit pixels are on-screen memory. These options contain support for z-buffering and color interpolation (with or without dithering). However, this hardware acceleration is only available when corresponding color/z-buffers are resident in off-screen memory. Due to the limited amount of off-screen memory (no more than 0.75 MB - about 880x880 pixels), the availability of this hardware acceleration depends largely on window size. When the buffers cannot be allocated in off-screen memory, the corresponding operation will be performed in software, which may have an effect on the performance. The following table lists the approximate maximum window sizes which permit the various levels of hardware acceleration. Table 1: Maximum Window Sizes for Hardware Acceleration at 1280x1024 Resolution Maximum Window Size Double Buffer Z-Buffer 440x440 pixels Accelerated Accelerated 880x880 pixels Accelerated Software >_880x880_pixels Software Software For the single-buffered case, windows larger than approximately 440x440 will not be able to take advantage of accelerated z-buffering. 4.2 RGB Color Interpolation and Dithering on ZLX-E1, ZLXp-E1 and PowerStorm 3D30 The ZLX-E1, ZLXp-E1 and PowerStorm 3D30 options contain hardware support for PEX and OpenGL RGB color interpolation and dithering, whereby 24-bit RGB colors are interpolated, dithered and mapped into the following 8-bit RGB format: 7 6 5 4 3 2 1 0 +---+---+---+---+---+---+---+---+ | RED | GREEN | BLUE | +---+---+---+---+---+---+---+---+ Note that the ZLX-E1, ZLXp-E1 and PowerStorm 3D30 do not support simultaneous multiple colormaps. Therefore, it must be understood that taking advantage of hardware-accelerated RGB color interpolation and dithering may lead to color map contention and possible "technicolor" situations. In addition, windows larger than approximately 880x880 pixels cannot take advantage of this hardware assist because the back buffer will not fit in off-screen memory. The following sections describe how to gain access to these hardware features via the OpenGL and PEX interfaces. 4.2.1 Access through OpenGL Hardware-accelerated RGB color interpolation is available to 8-bit RGB visuals. By calling glEnable() with the symbolic constant "GL_DITHER", hardware- accelerated dithering can also be requested. 4.2.2 Access through PEX Hardware-accelerated RGB color interpolation and dithering are possible via PEX when a Color Approximation Lookup Table entry with the following characteristics is selected: approxType == ColorSpace approxModel == RGB max1 <= 7 max2 <= 7 max3 <= 3 dither == 1 (if desired, 0 otherwise) mult1 == 32 mult2 == 4 mult3 == 1 basepixel == N*32 (6 <= N <= 0) Note that these color approximation parameters can be used with either 3-channel visuals (TrueColor, DirectColor) or 1-channel visuals (PseudoColor, etc.). For TrueColor or DirectColor visuals, the following values should be used to take advantage of all 256 color cells: max1 == 7 max2 == 7 max3 == 3 basepixel == 0 Note that use of these visual types will cause other windows to "go technicolor" when the focus is received. In order to avoid this situation, it may be possible to use the default colormap or create a new color map which will allow hardware- accelerated color interpolation and dithering, yet still retain the essential (read-only) color cells used by the system (e.g., window manager). This may not always be possible, depending on how the window manager and/or other clients have allocated colors. However, for the case of the Motif window manager and one PEX client, it should be possible to use fast dithering while avoiding technicolor problems. The key to permitting hardware color interpolation and dithering on PseudoColor visuals is finding a basepixel value which is a multiple of 32 and greater than the largest previously-allocated color cell (or read-only color cell, if a new color map is being created). This basepixel value must be be used to lower the maximum red value (max1) such that the red channel cannot overflow. Finding an appropriate basepixel value requires the application to interrogate the colormap and find the first available color cell whose index is a multiple of 32 and that has no cells allocated after it. 4.3 3D Graphics Acceleration on ZLX-E2 and ZLXp-E2 The ZLX-E2 and ZLXp-E2 options contain an 8 MB frame buffer arranged in 32-bit pixels. On-screen video memory holds upto 1280 x 1024 pixels, with a minimum of 0.75M pixels available off-screen. Within the 32-bit pixels, 4-, 8-, 12-, and 24- bit deep visuals are supported. The ZLX-E2 and ZLXp-E2 contain hardware support for color interpolation, with or without dithering for 8- and 12-bit visuals, and z-buffering. However, this hardware acceleration is only available when corresponding color and z-buffers are resident in off-screen memory. Due to the limited amount of off-screen memory (0.75 Mpixels, or roughly 880x880 pixels), the availability of this hardware acceleration depends largely on buffering type (single or double), window size, and visual depth. In those cases where the buffers cannot be allocated in off-screen memory, the corresponding operation will be performed in software, imposing a performance penalty. In the case of 8-bit visuals, this penalty is avoided by the system allocating a 16-bit deep z-buffer in the unused planes of on-screen memory. The following table lists the approximate maximum window sizes which permit the various levels of hardware acceleration. "DB" indicates double-buffering and "SB" indicates single-buffering. Table 2: Window Size Ranges versus Hardware Acceleration at 1280x1024 Resolution Visual Z- Depth __ Window Size Range Color Interpolation Buffer_____ 24 bits smaller than Accelerated Accelerated (DB) 390x390 24 bits 390x390 to Accelerated Software (DB) 880x880 24 bits larger than Software Software (DB) 880x880 24 bits smaller than Accelerated Accelerated (SB) 880x880 24 bits larger than Acclereated Software (SB) 880x880 12 bits (SB 880x880 Accelerated Accelerated or DB) 12 bits (SB larger than Accelerated Software or DB) 880x880 8 bits any size Accelerated Accelerated NOTE The preceding table assumes 1280x1024 on-screen resolution. Selecting a lower resolution (e.g., 1024x768) will directly increase the window size that can be accelerated. Maximum performance of a double-buffered application on a ZLX-E2 or ZLXp-E2 is obtained with a 12/12 visual format. This allows both front- and back-buffers to be stored in the same 32-bit pixel value, saving a copy operation with each swap action. This is effective for window sizes up to 880x880 pixels, when applications use 12/12 double-buffering and z-buffering simultaneously. 4.4 3D Graphics Acceleration on ZLX-E3, ZLXp-E3, and PowerStorm 4D20 The ZLX-E3, ZLXp-E3 and PowerStorm 4D20 options contain a 16 MB frame buffer arranged in 32-bit pixels. On-screen video memory holds 1280 x 1024 pixels, with 2.75M pixels available off-screen. (The PowerStorm 4D20 can have up to 1600 x 1200 pixels on-screen, with correspondingly less off-screen memory available.) Within the 32-bit pixels, 4-, 8-, 12-, and 24-bit deep visuals are supported. Maximum performance of a double-buffered application on a these options is obtained with a 12/12 visual format. This allows both front- and back-buffers to be stored in the same 32-bit pixel value, saving a copy operation with each swap action. This is effective for window sizes up to 1280x1024 pixels, when applications use 12/12 double-buffering and z-buffering simultaneously. Due to the increased frame buffer size, these options permit full hardware acceleration of color interpolation and z-buffering of 1280 x 1024 (or smaller) windows. 4.5 Selecting Default Visual Types Selecting default visual types is dependent on editing a file used by the program starting the X server. The location, name and syntax of this file is dependent on the windowing system being used. 4.5.1 Motif Window Manager Default Visual Types Default visual types can be set by editing the /usr/lib/X11/xdm/Xservers file and adding the appropriate visual class switch settings as shown below. For ZLX-L and ZLX-M: # for 24-bit TrueColor (No -vclass option) :0 local /usr/bin/X11/X -nice -2 # for 8-bit PseudoColor :0 local /usr/bin/X11/X -nice -2 -vclass PseudoColor # for 4-bit Overlay :0 local /usr/bin/X11/X -nice -2 -forceDepth 4 For ZLX-E: # for 12-bit TrueColor -I -ffbforceDepth 12 # for 4-bit Overlay -I -ffbforceDepth 4 4.5.2 CDE Window Manager Default Visual Types Default visual types under CDE can be set by editing the /usr/dt/config/Xservers.con file and adding the appropriate visual class switch settings as shown below. For ZLX-L and ZLX-M: # for 24-bit TrueColor (No -vclass option) :0 Local local@console /usr/bin/X11/X :0 # for 8-bit PseudoColor :0 Local local@console /usr/bin/X11/X :0 -vclass PseudoColor # for 4-bit Overlay :0 Local local@console /usr/bin/X11/X :0 -forceDepth 4 For ZLX-E: # for 12-bit TrueColor -I -ffbforceDepth 12 # for 4-bit Overlay -I -ffbforceDepth 4 4.6 ZLX-L series The ZLX-L1 amd ZLX-L2 are cost-reduced versions of the ZLX-M1 and ZLX-M2 options, respectively. Unless noted otherwise, the ZLX-L option provides the same features, functionality and restrictions as the corresponding ZLX-M option. 4.7 Overlay Support The following discussion of overlay support applies to all graphics options except the ZLX-E1, ZLXp-E1, PowerStorm 3D10 and PowerStorm 3D30. Overlays are not supported on the those options. 4.7.1 Technical Background The overlay window is a 4-plane PseudoColor visual. A colormap created with that visual would have 15 entries available to the user. Pixel 0 is always the transparent pixel. To get the visualID of the overlay visual, you need to get the SERVER_OVERLAY_VISUALS property from the root window. To retrieve the property and interpret the data associated with it, consider the following example: property_name: SERVER_OVERLAY_VISUALS property_type: SERVER_OVERLAY_VISUALS format: 32 The contents of the property is a LIST of the following data structure: SERVER_OVERLAY_VISUALS { overlay_visual: VISUALID transparent_type: {None, TransparentPixel, TransparentMask} value: CARD32 layer: CARD32 } For the devices with overlay planes, the server returns a list that contains one element. The element consists of four long-words, as described above. You would typically receive the following information: 0x00000027 /* VisualID */ 0x00000001 /* Indicates that the transparent_type is TransparentPixel */ 0x00000000 /* The transparent pixel's value is 0 */ 0x00000001 /* The layer is 1 */ Once you have the VisualID, you can retrieve the rest of the information about the overlay visual and colormap by calling the routine XGetVisualInfo. Overlay windows and regular windows are in different layers, so drawing in an overlay window will not disturb the pixels of the regular window, and vice versa. If you draw an invisible pixel into an overlay window, the pixel of the nonoverlay window beneath that window will show through. 4.7.2 Motif Window Manager for Overlays DIGITAL UNIX Version 4.0a or 4.0b supplies a Motif window manager with an option to support overlays. This is located in /usr/bin/X11. This window manager option (mwm -Overlay) will take advantage of the extra planes of memory available on many 3D graphics accelerators, particularly the ZLX-M1, ZLX-M2, ZLX-L1, ZLX-L2, ZLX-E2, ZLX-E3, ZLXp-E2, ZLXp-E3, ZLXp-L1, ZLXp-L2 and the PowerStorm 4D20. The new window manager will put all the window borders and banners in the overlay planes. If you currently have an application that was written to use overlays without this window manager, you will need to modify the application to avoid colormap problems. The best way to do this is to share the overlay colormap with the window manager. This can be done by querying the server property name SERVER_OVERLAY_COLORMAPS. This property will return the 32-bit value that is the overlay colormap ID. It is strongly suggested that you share colormaps with the window manager, as the hardware supports only one colormap for the overlay planes. If you create and install your own colormap, then you will have colormaps flashing on the screen and will change the colors of the window manager's borders and banners. 4.8 Multiple Colormaps The following discussion of multiple color maps applies to all supported graphics options except the ZLX-E1, the ZLXp-E1, the PowerStorm 3D10 and the PowerStorm 3D30. Options with multiple colormaps support multiple, simultaneously-installed colormaps. Applications should not install or deinstall colormaps themselves. The window manager should perform these actions. However, the application is responsible for providing the window manager with hints as to which colormaps to install or deinstall. You provide this information using the Xlib function XSetWMColormapWindows(). This function sets the WM_COLORMAP_ WINDOWS property for a given window. For information on how to use this function and how the window manager interprets the property, see The X Window System by Scheifler and Gettys, 3rdrd Edition (Section 14.1.11, Setting and Reading the WM_COLORMAP_WINDOWS Property, pages 425-426, and Section 4.1.8, Colormaps, page 649-651). Applications written and debugged on systems with only one colormap may appear incorrect on a system with multiple colormaps. There are several application errors that can cause this, but the most prevalent is not having the correct colormap associated with all the windows that require it. To correct this problem, use XChangeWindowAttributes to set the colormap for all windows in the application that require the colormap. 4.9 DECStereo Extension All members of the ZLX and ZLXp series, as well as the PowerStorm 3D30 and PowerStorm 4D20, have stereo capabilities. To enable this functionality, DIGITAL Open3D includes the DECStereo X Extension. This extension consists of a set of library routines that perform the following actions: ú Query and load the extension (XDECStereoQueryExtension) ú Query the extension version (XDECStereoQueryVersion) ú Set the stereo mode (XDECStereoSetMode) ú Query the current stereo mode (XDECStereoQueryMode) The constant, structure, and function prototype definitions are defined in the following files: ú /usr/include/DECStereo/DECStereo.h ú /usr/include/DECStereo/DECStereostr.h The client side library is in /usr/lib/libDECStereo.a. The shareable image version of this library is in /usr/shlib/libDECStereo.so. A helper program is supplied in /usr/bin/X11/xstereo, which exercises the functions of the DECStereo extension. DIGITAL Open3D also supplies a man page for xstereo. To use the stereo extension with any supported option, you must modify the file /usr/var/X11/Xserver.conf. See Section 1.4.2.2 for more information on modifying this file. 4.9.1 Query and Load the DECStereo Extension To query the X server and load the DECStereo extension, call the following routine: Bool XDECStereoQueryExtension(display, event_base, error_base) Display *display; int *event_base; int *error_base; This routine returns False if it cannot load the extension. If successful, the routine returns True and the event_base and error_base codes. 4.9.2 Query the DECStereo Extension Version To query the version number of the DECStereo extension, call the following routine: Status XDECStereoQueryVersion(display, major_version, minor_version) Display *display; int *major_version; int *minor_version; If the routine fails, it returns the value 0. If successful, the routine returns the value 1, and the major and minor version number of the DECStereo protocol. 4.9.3 Set the Stereo Mode To set the stereo mode of the server and the stereo-capable hardware, call the following routine: void XDECStereoSetMode(display, drawable, mode) Display *display; Drawable drawable; int mode; In this routine, mode can be either StereoOn or StereoOff. 4.9.4 Query the Stereo Mode To query the stereo mode of the server and stereo-capable hardware, call the following routine: Status XDECStereoQueryMode(display, drawable, mode, stereoCapable) Display *display; Drawable drawable; int *mode; int *stereoCapable; If the query fails, the routine returns the value 0. If successful, the routine returns the value 1 and the mode (StereoOn or StereoOff). The routine also sets the stereoCapable flag to the value 1, whether the screen for this drawable is capable of stereo or not. 5 CHAPTER 5 KNOWN RESTRICTIONS AND PROBLEMS This section describes the known restrictions with the 4.x versions of DIGITAL Open3D. 5.1 Operating System Restrictions This section describes restrictions related to the operating system software. 5.1.1 Turning BLOCKMODE I/O on in TURBOchannel-Based Systems Turning BLOCKMODE I/O on in TURBOchannel-based systems improves performance in most cases. To turn BLOCKMODE I/O on in DIGITAL UNIX Version 3.0 and higher, add the following lines at the end of the /etc/sysconfigtab file: sfbp: sfbp_enable_blockmode=1 A system reboot is required for the Block Mode I/O to take effect. To turn BLOCKMODE off, remove these lines from the file and reboot the system. When turning BLOCKMODE I/O on to improve performance, you should note the following: ú This is only applicable to TURBOchannel machines whose module Rev is J and above, for DEC 3000 Model 400 and Model 500. ú Should this be done on a machine whose Rev level is lower than Rev J, a machine check crash will probably occur. 5.2 Overlay Window Manager Restrictions You should be aware of the following overlay window manager restrictions: ú The window manager currently supports only single-screen systems; it does not work correctly with multiple graphics devices (multihead). ú If you select "Show Feedback when moving or resizing windows", the window with the feedback information will cause expose events. ú When you move windows around by just showing the outline of the window, the outline will appear to go below the window borders and banners. 5.3 X Restrictions This section describes restrictions related to the X Window System. 5.3.1 Backing Store Support Backing store, which is enabled by default, requires significant amounts of off- screen memory. If a small piece of a window is occluded, the off-screen memory requirements for the window depend on the size of the window, not on the occluded fragment. (This is the design of backing store as supplied by the X Consortium.) This memory requirement can cause problems when you use ZLX and ZLXp devices, which have a limited amount of off-screen memory. When this memory is used up, the performance is degraded. For example, if you see unacceptable pauses in the windowing system when pulling down menus or changing window focus, these are probably caused by backing store. Therefore, Digital recommends that you use backing store sparingly, and try to have only one window on the screen that requests backing store. This allows extra room in off-screen memory for pixmaps. If you continue to have problems that you suspect are caused by backing store, you can disable this option and try the operation again. To turn off backing store and save unders, add the following lines to the end of the /usr/var/X11/Xserver.conf file: args < bs -su > NOTE You should save the original /usr/var/X11/Xserver.conf file before editing it. If an args command already exists in the file /usr/var/X11/Xserver.conf, add "- bs -su" to the list of arguments. To have your edits taken into account, you must stop and restart the server. To stop the server, enter the command: # /sbin/init.d/xlogin stop The server will exit. Then, log in to the system as root and enter the following command to restart the server: # /sbin/init.d/xlogin start # exit 5.3.2 Save Under Support Save unders are enabled by default. The X Consortium implementation of save unders turns on backing store for occluded windows, however, which potentially uses large amounts of off-screen memory and causes performance to degrade. For example, when save unders are enabled, you may see pauses in menu and windowing operations as backing store is enabled and disabled on windows that are under menus. 5.3.3 Multihead Support The following rules apply to multihead support: ú Only one (1) PowerStorm 3D10 may be used in any PCI machine. It cannot be combined with any other options, including another PowerStorm 3D10. ú All ZLX options work with the HX option included with DEC 3000 Models 300 and 500 ú All options (except PowerStorm 3D10) support homogeneous 3D/3D multihead. This means that you can have more than one head of ZLX-M or ZLX-E, or ZLX-L on a workstation and 3D is supported on each of the heads. ú The ZLX-M and ZLX-L support heterogeneous 3D/2D multihead only with the ZLX- E1 option. This means that the ZLX-M or ZLX-L running 3D will work with ZLX-E1 running 2D. ú The ZLX-E2 and ZLX-E3 do not currently support heterogeneous multihead with any other ZLX options. ú Homogeneous multihead is supported for ZLXp-E, PowerStorm 3D30, and PowerStorm 4D20 on the PCI systems. ú There is no multihead support of ZLXp-L1 or ZLXp-L2 options. 5.4 PEX Restrictions This section describes restrictions of PEX library functions. NOTE Beginning with the next release of Open3D, PEX, the DEC PEXlib and the MIT PEXlib will no longer be supported. They will continue to be shipped for one or more future releases. After that time, the libraries and supporting software will only be available from older media, and run with older releases of Open3D. 5.4.1 Support of MIT PEXlib Functions As is documented in the SPD for DIGITAL Open3D, there is limited support for MIT PEXlib functions. In particular, there is no support for "PEX picking" from the MIT PEX library. PEX picking is only available through the Digital PEX library. 5.4.2 No PEX Support for PowerStorm 3D10, HX or PowerStorm 4DxxT Graphics There is no PEX support for any embedded or add-on HX devices, for the PowerStorm 3D10, or for any PowerStorm 4DxxT devices. If the PEX subset is loaded during installation, the PEX extension will be present at run time. However, a client attempting to render PEX to the non-supported device(s) will receive an X error. 5.4.3 Transparency Using PEX The method used to render transparent primitives in this implementation of PEX uses a two-pass algorithm. The first pass renders opaque primitives updating the z-buffer, while the second pass renders the transparent objects without updating the z-buffer. A limitation of this algorithm is that the transparent primitives are blended in the order that they are rendered, not necessarily in back-to- front order. This could cause some undesirable effects that would appear as if transparent objects were incorrectly z-buffered. 5.4.4 PEXQuadMesh Compatibility There was an incompatible change to the PEXQuadMesh primitive between DEC PEX Version 5.0 and DEC PEX Version 5.1. Both the PEX Version 5.0 Protocol Specification and the PEX Version 5.0 Protocol Encoding documents specify the following: "numPointsM is the number of vertices in the quadrilateral mesh in the M direction, and numPointsN is the number of vertices in the quadrilateral mesh in the N direction." Digital's PEX server (OSF/1 and OpenVMS systems) interpreted numPointsM as the number of rows in the quadrilateral vertex array, and numPointsN as the number of columns. The PEX Protocol Specification Version 5.1 (31-August-1992), however, specifies numPointsM as the number of columns and numPointsN as the number of rows. To resolve this problem, DIGITAL PHIGS and Digital's PEX Version 5.1 servers used the following scheme: ú Digital's OpenVMS and DIGITAL UNIX Version 5.1 servers check whether MPEXNRAClearZ is used. (MPEXNRAClearZ is a Digital PEX extension in DEC PEXlib.) This request causes the PEX Version 5.1 servers to interpret the row and column data for subsequent PEXQuadMESH primitives using the PEX Version 5.0 specification. If MPEXNRAClearZ is not used, DEC PEX uses the row and column interpretation defined by the PEX Version 5.1 specification. ú The change is transparent to DIGITAL PHIGS programs. A PHIGS program with QuadMesh running on DEC PHIGST Version 2.3 (Digital PEXlib Version 5.0) can display correctly on both DEC PEX Version 5.0 and DEC PEX Version 5.1 servers. The same program running on DEC PHIGS Version 2.4 or later (Digital PEXlib Version 5.1) also displays correctly on both Digital PEX Version 5.0 and Version 5.1 servers. 5.4.5 Edge Flags and Shared Edges If two surfaces turn on the edge flag for a shared edge, the edge will be drawn twice. Because the pixels for an edge are completely inside the surface, the shared edge will appear to be double width. If the sharing surfaces use different edge colors, the edge colors may appear to be tangled. 5.5 OpenGL Restrictions This section describes restrictions on using OpenGL software. 5.5.1 Non-Digital Example Imakefiles Digital has included in this release a modified version of the OpenGL example code available via anonymous ftp from SGI. Although the source code from SGI should compile and run unaltered on a Digital system, it may not. Digital has corrected problems with 64-bit integers and pointers that are not apparent on a 32-bit SGI system. In addition, the Imakefiles from SGI are not portable. If you want to build the example code, we strongly recommend that you use the sources provided by Digital in /usr/examples/GL. Because the Imakefiles and Makefiles provided by SGI will not work correctly on a DIGITAL UNIX system, you must at least use the Digital- supplied Imakefiles to produce a Makefile. To make a Makefile from an Imakefile, use the xmkmf command in the directory containing the Imakefile. 5.5.2 Antialiased Operations The following restrictions apply to antialiased operations: ú Antialiased polygons for OpenGL are not supported. The primitives are rendered, but not antialiased. ú OpenGL antialiased lines may not be rendered completely within the OpenGL specifications. 5.6 ZLX-M and ZLX-L Restrictions This section describes known restrictions and problems with the ZLX-M and ZLX-L options. 5.6.1 Drawing Convex Polygons If a convex polygon has multiple points that are coincident, then the X server may draw the polygon incorrectly or not at all. A simple workaround is to change the XfillPolygon call to pass Complex as the polygon type. This will be corrected in a future release of DIGITAL Open3D. 5.6.2 Multibuffer Support The server will crash (segmentation fault) if you try to create a multibuffer that has more than 20 buffers. 5.6.2.1 -screenOrder Option A graphics device used as a system console appears as screen 0 by default. To change this, use the SET CONSOLE command at the ">>>" prompt before booting the system (for example, SET CONSOLE 13 or SET CONSOLE 83.) The other head will be screen 1, accessed through display :0.1. Screen 0 will be the left logical screen. If you attempt to bring a multihead system up with the HX as physical screen 0 and the ZLX as physical screen 1, you must supply the -screenOrder0 or - screenOrder1 parameter when starting the server. This prevents a server crash during 3D clipping. For information on other multihead screen configuration options, enter the "- help" qualifier on the server command line. 5.6.2.2 -forceDepth 4 option present If you use the -forceDepth 4 option on a multiscreen configura-tion with both ZLX-M1/ZLX-M2 and ZLX-E1 options, the -forceDepth option will take effect on all ZLX-M1/ZLX-M2 screens; however, the ZLX-E1 option will not be configured. Note that the HX options will not be affected. 5.6.3 3D-Specific Display and Rendering Corruptions This section describes display and rendering corruptions on 3D systems. 5.6.3.1 Z-buffer precision Z-buffered surfaces that are extremely close yet not exactly on top of one another may generate a vertical striping effect. 5.6.3.2 8-Plane Colorspace DIGITAL Open3D does not support 8-plane colorspace shading and will generate anomalies. Instead, DIGITAL Open3D uses flat-shading on the primitives that were to be interpolated, usually using the color of the first vertex of the primitive being rendered. This limitation applies only to PEX shading, not to OpenGL. NOTE Color range applications will be interpolated correctly. 5.6.3.3 Lighting Restrictions Exponents associated with lighting formula (specular and spot light concentration) are truncated and clamped to a value between 0 and 63. This restriction applies only to the ZLX-M, not to the ZLX-L. 5.6.3.4 Homogeneous Coordinates Digital OpenGL does not process clipping primitives with the -w component. That is, the viewing frustum on the -w side is not visible. When w = 0.0 in NPC space, the result of processing each vertex of a primitive is unspecified and depends on corresponding x, y, and z values. 5.6.3.5 Antialiased Operations The interpolation of line mode polygons in color index mode is incorrect. 5.6.3.6 Surface Primitives Rendered Non-sequentially Certain conditions could cause some primitives to be rendered non-sequentially. This could have an effect if operations such as depth test equal, for example, are selected. This problem may be exacerbated by a combination of no culling, distinguish option turned on, and different front and back facing attributes, or complex OpenGL per-fragment operations. 5.6.3.7 OpenGL Repeat Factor and Stippled Lines The repeat factor is ignored if a stippled line is being antialiased. 5.6.3.8 OpenGL Stencil Buffer Update When the stencil failure update mode is GL_INCR or GL_DECR, the alpha test will be ignored. 5.6.3.9 OpenGL Accumulation Buffer If the contents of the accumulation buffer are negative, the results of GL_MULT operations may be incorrect. If the result of a GL_MULT operation is negative, the value stored in the accumulation buffer will be incorrect. Computations are truncated rather than rounded, which may reduce precision. Intermediate computations are performed in a limited and fixed precision, which may also reduce the precision of very large and very small parameter values. 5.6.3.10 OpenGL Silhouette Polygons Silhouette, or edge-on, polygons are treated as front-facing entities. This conflicts with the OpenGL specification, which states that these polygons should be processed as back-facing entities. 5.6.3.11 OpenGL NORMALIZE Mode In certain conditions, normals in OpenGL are normalized after transformation, regardless of the setting of the NORMALIZE state bit. Therefore, operations which depend on the NORMALIZE state being disabled (i.e., normals not normalized) should be avoided. NOTE This restriction applies only to the ZLX-M device, not to the ZLX-L device. 5.6.4 2D Specific Display and Rendering Corruptions This section describes display and rendering corruptions with 2D software. 5.6.4.1 Pseudocolor Support Use the -forceDepth 8 command to select 8-bit pseudocolor as the server's default visual, and -forceDepth 4 to select the 4-bit overlay plane pseudocolor visual as the server's default visual. The -vclass PseudoColor option is also supported in this release. However, if you require 4-bit overlays, you need to use forceDepth 4. 5.7 ZLX-E, ZLXp-E, PowerStorm 3D30 and 4D20 Restrictions This section describes the known restrictions for the ZLX-E, ZLXp-E, PowerStorm 3D30 and 4D20 devices. 5.7.1 DEC 3000 Model 300 Server Crashes If there is a server crash when popping windows on a DEC 3000 Model 300, modify the file /usr/lib/X11/xdm/Xservers to include the following at the end of the /X line: I -ffbDoDMA 0 This will reduce the performance of shared memory put image, but should eliminate the crashes. In a future release of DIGITAL Open3D this problem will be fixed with no significant performance impact. 5.7.2 3D Display Corruption and Rendering Restrictions This section describes display and rendering corruptions on 3D systems. 5.7.2.1 Resizing OpenGL Client Window Resizing an OpenGL client window sometimes corrupts the display for the first frame after a resize. 5.8 PXG Restrictions PXG devices are not supported in DIGITAL Open3D beyond Version 2.6. 5.9 Multihead ZLX Configurations DIGITAL Open3D supports multihead configurations for certain ZLX options. Multihead configurations require modification to the system configuration file and a rebuilding of the kernel. For example, to create a kernel that adds a ZLX-E1 device to an existing ZLX-M1 device, perform the following steps: 1. Login as root. 2. Enter the following command: # cd /sys/conf 3. Using an appropriate editor, modify the HOSTNAME file. where HOSTNAME is the name of your system configuration file. Before editing, the file will look something like this: # # Config file fragment. Supports one ZLX-M1. # controller pv0 at tc0 slot ? vector pvintr # # Force graphics devices into kernel # pseudo-device xcons pseudo-device ws After the line containing "pv0", add the following line: controller fb0 at tc0 slot ? vector fbint 4. Rebuild the kernel using the doconfig command: # doconfig -c HOSTNAME Saving /sys/conf/HOSTNAME as /sys/conf/HOSTNAME.bck Do you want to edit the configuration file? (y/n) [n]: n *** PERFORMING KERNEL BUILD *** The new kernel is /sys/HOSTNAME/vmunix. 5. Rename the current kernel so you can use it if problems arise: # mv /vmunix /vmunix.original 6. Move the newly created kernel to the root area: # mv /sys/HOSTNAME/vmunix /vmunix 7. Shut down the system: # shutdown -h now 8. When the machine returns to the console prompt (>>>), you may power down the system to install the new ZLX-E1 module. After installation, power up the system and boot the new kernel. 9. If problems occur, examine the text in the file config.file for errors, and rebuild the kernel after making any corrections. If necessary, you can boot the original kernel directly from the console prompt, using the following command: >>> b -fi "vmunix.original" 6 CHAPTER 6 Application Notes for OpenGL Stereo Rendering for PowerStorm 4D40T, 4D50T, 4D51T and 4D60T This section is intended to give a brief overview of the stereo implementation that is available for the PowerStorm 4DT family of graphics adapters. In some cases, information in a section of this document may apply only to OpenGL implementations layered on a particular operating system (DIGITAL UNIX or Windows NT). In such cases, the text is preceded by a bracketed [ ] disclaimer. OpenGL stereo as described in this document is currently only supported on DIGITAL UNIX . This document does not discuss algorithms for generating stereo views from a 3D scene, and it does not discuss how to write a stereo application using OpenGL. (Although an example of a simple stereo application is given at the end of this document). The OpenGL stereo implementation for the PowerStorm 4DxxT family was intended to be as transparent as possible, and thus take advantage of pre- existing (and well-documented) API's. This version of this document describes the stereo capabilities of the PowerStorm 4DT series of graphics adapters, as implemented in DIGITAL Open3D Version 4.7. Customers using beta or field test versions of software that include stereo support for this series of graphics adapters are encouraged to upgrade, as this release contains numerous bug fixes and improvements. ---------------------------------------------------------------------------- 6.1 Stereo Support Stereo support for the Powerstorm 4DxxT family of graphics adapters conforms to the model defined by the OpenGL standard. An application can render a stereoscopic scene by simply drawing to the appropriate left or right buffers. The hardware mechanics of rendering in stereo mode are completely transparent to the applications developer. The form of stereo rendering that has been implemented is commonly referred to as 'stereo-in-a-window'. A stereo scene can be rendered into a normal window on the screen. Pixels that are displayed in a stereo window will have a normal aspect ratio. Other monoscopic applications can displayed on the same screen, and will appear normal. Multiple stereo windows and monoscopic windows can be displayed simultaneously, can overlap and can be managed by a standard window manager. ---------------------------------------------------------------------------- 6.2 Enabling Stereo from an Application To enable stereo rendering, two things must be done. The graphics adapter must be using a screen resolution that supports stereo, and an application must select a visual or pixel format that supports stereo. To determine if your current configuration will support stereo, use a program such as xglinfo to list all of the visuals that GL supports. If you see visuals that have the 'STEREO' attribute, then stereo will be available to applications that request it. If you only see visuals with the 'MONO' attribute, then either your software is not correctly installed or you have selected a screen resolution that does not support stereo. See the section titled Supported Screen Resolutions and Refresh Rates to make sure that you have selected a resolution that supports stereo. From a user program, you can determine if the system is stereo capable by calling glXGetConfig() with the requested attribute set to GLX_STEREO. For an OpenGL implementation layered on the X Window System, simply use glXChooseVisual() to select an appropriate stereo visual. Use glXCreateContext() to create a new GLX rendering context using the visual that was selected. When the application calls glXMakeCurrent() with this context, the screen will be switched into stereo mode, and rendering can proceed as normal. The same effect can be achieved using a GL toolkit that supports stereo. For example, when using the OpenGL Utility Toolkit (GLUT), simply OR in the GLUT_STEREO bit to the mode argument when calling glutInitDisplayMode(). Selecting the left or right stereo buffer is accomplished through the standard call to glDrawBuffer(). When the context or window used for stereo rendering is destroyed, the screen is switched back out of stereo mode. If multiple contexts are being used for stereo rendering, the screen is not switched out of stereo mode until the last of these contexts is destroyed. ---------------------------------------------------------------------------- 6.3 Supported Hardware This stereo implementation requires a PowerStorm 4D40T, 4D50T, or 4D60T graphics adapter and compatible MultiSync monitor, such as Digital's VRC15, VRC17, or VRC21 series monitors. StereoGraphics and NuVision stereo hardware are both supported by this implementation. Note that the stereo connector on the back of the PowerStorm 4DT cards is different from the stereo connector on the back of other Digital graphics adapters. Contact the manufacturer of your stereo hardware to obtain the proper cables to connect your stereo hardware to your PowerStorm 4DxxT card. The cable should match the mini-DIN connector on the back of the PowerStorm card. -------- -------------------------------------------------------------------- 6.4 Supported Screen Resolutions and Refresh Rates In order to support normal aspect ratio pixels in stereo mode, the frame buffer is divided into two full height left and right buffers. Because of the increased memory requirements associated with maintaining separate left and right buffers, the maximum screen resolution for each graphics adapter will be slightly smaller than in non-stereo mode. Maximum Stereo Resolutions PowerStorm Model Planes Per Max Pixel Resolution -------------------------------------------- 4D60T 102 1280x1024 128 1152x900 4D50T/4D40T 102 800x600 128 800x600 [NOTE: the following information applies only to OpenGL implementations layered on the X Window System.] To select a particular screen resolution and vertical refresh rate, use the '- screen' and '-vsync' command line options in the X server configuration file. To select an additional vertical refresh rate to be used when the screen is in stereo mode, use the '-I -e3stereo ' command line arguments in the Xserver configuration file. Replace by one of the vertical refresh rates in the table below. Note that the maximum refresh rates indicated may not be supported by all hardware. If you omit the '-I -e3stereo ' arguments in the Xserver configuration file, the server will continue to use the same refresh rate that it was using when the screen was in monoscopic mode. This will be the value that was specified with the '-vsync' parameter, or the default refresh rate for this resolution. The first time that the screen is switched into stereo mode, the Xserver will print out the refresh rate that is being used for stereo. If no '-vsync' or '- e3stereo' arguments were given, the Xserver will note that stereo mode is using the default refresh rate. This information can be found in the Xserver error log (/var/dt/Xerrors or /var/X11/xdm/xdm-errors). See your system administrator or refer to your documentation and release notes for more information on configuring the Xserver via the configuration file. The following table lists all of the resolutions and corresponding vertical refresh rates supported by PowerStorm 4DT graphics adapters. Note that not all of these resolutions are supported in all configurations. (For example, only the 4D60T is capable of the highest resolutions, and the very highest require a 4D60T operating in 102 bpp mode). To determine the maximum possible stereo resolution for a given configuration, consult the previous table. There are no real restrictions on the refresh frequency that is used at a given resolution. You may pick any of the available frequencies for the resolution you have chosen, within the limits of your display hardware. Note also that these refresh rates are per frame, so in stereo mode, divide by two to get the effective refresh rate per eye. In the comment column, The asterisk ('*') indicates the default refresh rate for a particular resolution. This is the value that you should get if you select this resolution and do not use the '-vsync' option. A frequency range of "xx..yy" indicates that the entire range is supported, in 5 Hz intervals. Supported Video Modes ------------------------------------------------------------ Resolution 4D60T Other 4DxxT (Hor x Ver) Refresh Rate Refresh Rates ----------- --------------- ------------- 1920x1200 60..75; 76* not available 1920x1080 60..75; 60* not available 1600x1280 60..75; 70* not available 1600x1200 60..85; 75* not available 1280x1024 60..85, 66, 72; 75* 60..85, 66, 72; 75* 1152x900 60..110; 76* 60..110; 76* 1024x768 60..115; 75* 60..115; 75* 1024x864 60..140; 60* 60..115; 60* 800x600 60..140, 72; 75* 60..140, 72; 75* 720x400 70 70 640x480 60..150, 72; 75* 60..150, 72; 75* 6.5 Supported Visuals [NOTE: the following information applies only to OpenGL implementations layered on the X Window System.] GL stereo is currently supported on single and double buffered TrueColor-24 and PseudoColor-8 visuals. Future support will include DirectColor visuals. ---------------------------------------------------------------------------- 6.6 Backing Store [NOTE: the following information applies only to OpenGL implementations layered on the X Window System.] Backing store is currently not supported when rendering in stereo mode. Windows that have their backing store attribute set will have backing store turned off while the screen is in stereo mode and will receive exposure events. When the screen returns to monoscopic mode, these windows will have backing store re-enabled. Backing store for any obscured regions will have been lost, but will be available for subsequent window operations. ---------------------------------------------------------------------------- 6.7 Performance When the graphics adapter is in stereo mode, the rendering performance of monoscopic applications will be lower than normal. Because of this, it is recommended that when stereoscopic rendering is no longer required, the adapter be switched out of stereo mode. This reduction in performance is most apparent in applications that draw large, simple primitives. Large rectangle fills are the best example of this. Rendering complex three-dimensional scenes with many polygons or textured polygons should not suffer significant performance degradation. Switching between normal and stereo modes is fairly expensive, so switching back to normal mode is only required when it is unlikely that stereo rendering will be performed in the near future. An application that renders in both mono and stereo should remain in stereo mode for as long as stereo rendering is required. ---------------------------------------------------------------------------- 6.8 Left and Right Construction Planes [NOTE: the following information applies only to OpenGL implementations layered on the X Window System.] As described above, in this stereo implementation, the frame buffer is divided into separate full-height left and right buffers. This means that when the screen is in stereo mode, the left and right buffers use separate portions of the frame buffer for the construction planes. (Depth buffer, alpha buffer, and stencil buffer). This does not cause problems in normal rendering, but it can cause unexpected results when an application reads and writes to these buffers. OpenGL implicitly assumes that there is only one of each of these construction buffers. In the case of an application that reads from these planes (via glReadPixels), data will always be fetched from the buffer associated with the left stereo buffer. When an application writes to these buffers (via glDrawPixels) the data is replicated and sent to both the left and right buffers. Note that having separate depth, stencil, and alpha buffers for the left and right stereo buffers will not cause problems for monoscopic applications that are running when the screen is in stereo mode. For these applications, the same information is rendered in both the left and right buffers, so both sets of construction planes will be identical. ---------------------------------------------------------------------------- 6.9 Common Questions Q: I don't seem to have a proper cable to attach my stereo glasses to my PowerStorm 4DxxT. How do I hook things up right? A: See the section titled Supported Hardware. [NOTE: the following information applies only to OpenGL implementations layered on the X Window System.] Q: I tried to start a stereo application, but it couldn't find an appropriate visual. What gives? A: (See the previous question). In later versions of the stereo software, if the Xserver is running at a resolution that does not support stereo, then no GL visuals that support stereo will be available. Again, check to make sure that you are using a resolution that supports stereo. (You can use the program 'xglinfo' to see what GL visuals are available). Q: When I am running an application in stereo mode, why don't certain things always get redrawn properly? A: If your application does not handle expose events, or relies on backing store to handle redraws of obscured areas, you may experience problems when running in stereo mode, since backing store is turned off. Q: I have an application that uses DECstereo. Will it work with a PowerStorm 4DxxT card? A: No. DECstereo is not supported on these cards. Q: When I run 'xstereo -i', it says that the display is not stereo capable. A: (See the previous question). xstereo works with the older DECstereo, and is not supported on the PowerStorm 4DxxT series cards. Q: I need to have my X-only application render in stereo. How do I do this? A: Right now, stereo is only supported for GL applications. Q: Why can't I get overlays or pseudocolor to work in stereo mode? A: Beta versions of the stereo kit had problems when switching in and out of stereo mode when using visuals that required a dynamic colormap. (Overlays, PseudoColor, DirectColor). The colormap would get trashed, resulting in improperly colored or invisible drawing. This has been fixed in the Open3D 4.3 release. ---------------------------------------------------------------------------- 6.10 Application Example Demonstration of a simple stereo application in OpenGL and GLUT. This application puts a crude stereo image of a paper airplane on the screen, rotating about its center. This program uses perspective depth, which draws things in the distance smaller. The only correct way to do this in gl is with the "window" subroutine made to perform asymmetric projection by the use of parallel cameras. It is incorrect to angle the cameras inward so that their lines of gaze intersect at a point in space. For orthographic display (no perspective -- things in the distance drawn the same size as things up close) it is correct to angle the cameras inward. The gl "perspective" may be used in this case if one wishes. For proposed standards for stereoscopic display see "Stereo Image Display on Microcomputers" by Dennis J. Adams and Albert F. G. Xthona, available free from: StereoGraphics Corporation 2171 East Francisco Blvd. San Rafael, CA 94901 (415) 459-4500 The original version of the program before modification, was by Robert Akka published in The CrystalEyes Handbook, distributed by StereoGraphics. Richard Bradley at StereoGraphics states that the original program is in the public domain. Permission to use, copy, modify, and distribute this software for any purpose and without fee is hereby granted, provided that this permission notice appears on all copies of the software. The name of IBM Corporation may not be used in any advertising or publicity pertaining to the use of the software. IBM makes no warranty or representations about the suitability of the software for any purpose. It is provided "AS IS" without any express or implied warranty, including the implied warranties of merchantability, fitness for a particular purpose and non-infringement. IBM Shall not be liable for any direct, indirect, special, or consequential damages resulting from the loss of use, data, or projects, whether in an action of contract or tort, arising out of or in connection with the use or performance of this software. Permission to use, copy, modify, and distribute this software for any purpose and without fee is hereby granted, provided that this permission notice appears on all copies of the software. The software is provided "AS IS" without any express or implied warranty, including the implied warranties of merchantability, fitness for a particular purpose and non-infringement. Digital Equipment Corporation (DEC) shall not be liable for any direct, indirect, special, or consequential damages resulting from the loss of use, data, or projects, whether in an action of contract or tort, arising out of or in connection with the use or performance of this software. Except as contained in this notice, the name of DEC shall not be used in advertising or otherwise to promote the sale, use or other dealings in this software without prior written authorization from DEC. /* * * plane.c (OpenGL version) * Draws rotating paper airplane in stereo. * * Converted to use OpenGL Utility Toolkit * Rick Hammerstone, Digital, December 1996. * * Converted to OpenGL by Silicon Graphics Corp. 4Dgifts program toogl. * Further modified by James S. Lipscomb and Keh-Shin Cheng, IBM Research, * March 1995. Uses Motif. * * Original program in GL by Robert Akka * StereoGraphics Corporation * April 2, 1991 * * Compile with: * cc -o plane plane.c -lglut -lGLU -lGL -lXmu -lXi -lXext -lX11 -lm * * Hit to stop program. */ #include #include #include #include /* * Speed of rotation in degrees per update. */ #define VELOCITY -0.2 float yAngle = 0; GLenum rgb, doubleBuffer; void Reshape(int width, int height) { glViewport(0, 0, width, height); } void Key(unsigned char key, int x, int y) { if (key == 27) exit(0); } void Init() { glMatrixMode(GL_PROJECTION); } void DrawAirplane() { static float airplane[9][3] = { { 0.0, 0.5, -4.5}, { 3.0, 0.5, -4.5}, { 3.0, 0.5, -3.5}, { 0.0, 0.5, 0.5}, { 0.0, 0.5, 3.25}, { 0.0, -0.5, 5.5}, {-3.0, 0.5, -3.5}, {-3.0, 0.5, -4.5}, { 0.0, -0.5, -4.5} }; glColor3f(1.00, 0.19, 0.69); /* violet: r=1, g=.19, b=.69 */ glBegin(GL_LINE_LOOP); glVertex3fv(airplane[6]); glVertex3fv(airplane[7]); glVertex3fv(airplane[1]); glVertex3fv(airplane[2]); glVertex3fv(airplane[4]); glEnd(); glBegin(GL_LINE_LOOP); glVertex3fv(airplane[0]); glVertex3fv(airplane[4]); glVertex3fv(airplane[5]); glVertex3fv(airplane[8]); glEnd(); glBegin(GL_LINE_LOOP); glVertex3fv(airplane[6]); glVertex3fv(airplane[3]); glVertex3fv(airplane[2]); glEnd(); } void Plane(float yAngle) { glRotatef(yAngle, 0, 1, 0); glRotatef(-10, 1, 0, 0); DrawAirplane(); } void StereoProjection(float left, float right, float bottom, float top, float near, float far, float zero_plane, float dist, float eye) /* Perform the perspective projection for one eye's subfield. The projection is in the direction of the negative z axis. -6.0, 6.0, -4.8, 4.8, left, right, bottom, top = the coordinate range, in the plane of zero parallax setting, which will be displayed on the screen. The ratio between (right-left) and (top-bottom) should equal the aspect ratio of the display. 6.0, -6.0, near, far = the z-coordinate values of the clipping planes. 0.0, zero_plane = the z-coordinate of the plane of zero parallax setting. 14.5, dist = the distance from the center of projection to the plane of zero parallax. -0.31 eye = half the eye separation; positive for the right eye subfield, negative for the left eye subfield. */ { float xmid, ymid, clip_near, clip_far, topw, bottomw, leftw, rightw, dx, dy, n_over_d; dx = right - left; dy = top - bottom; xmid = (right + left) / 2.0; ymid = (top + bottom) / 2.0; clip_near = dist + zero_plane - near; clip_far = dist + zero_plane - far; n_over_d = clip_near / dist; topw = n_over_d * dy / 2.0; bottomw = -topw; rightw = n_over_d * (dx / 2.0 - eye); leftw = n_over_d *(-dx / 2.0 - eye); /* Need to be in projection mode for this. */ glLoadIdentity(); glFrustum(leftw, rightw, bottomw, topw, clip_near, clip_far); glTranslatef(-xmid - eye, -ymid, -zero_plane - dist); } void DrawScene(void) { glDrawBuffer(doubleBuffer ? GL_BACK : GL_FRONT); glClearColor(0.0, 0.0, 0.0, 0.0); glClear(GL_COLOR_BUFFER_BIT); glDrawBuffer(doubleBuffer ? GL_BACK_LEFT : GL_FRONT_LEFT); glPushMatrix(); StereoProjection(-6.0, 6.0, -4.8, 4.8, 6.0, -6.0, 0.0, 14.5, -0.31); Plane(yAngle); glPopMatrix(); glDrawBuffer(doubleBuffer ? GL_BACK_RIGHT : GL_FRONT_RIGHT); glPushMatrix(); StereoProjection(-6.0, 6.0, -4.8, 4.8, 6.0, -6.0, 0.0, 14.5, 0.31); Plane(yAngle); glPopMatrix(); if (doubleBuffer) glutSwapBuffers(); else glFlush(); yAngle -= VELOCITY; if (yAngle < 0) yAngle = 360.0 + yAngle; /* degrees */ } GLenum Args(int argc, char **argv) { GLint i; rgb = GL_TRUE; doubleBuffer = GL_TRUE; for (i = 1; i < argc; i++) { if (strcmp(argv[i], "-ci") == 0) { rgb = GL_FALSE; } else if (strcmp(argv[i], "-rgb") == 0) { rgb = GL_TRUE; } else if (strcmp(argv[i], "-sb") == 0) { doubleBuffer = GL_FALSE; } else if (strcmp(argv[i], "-db") == 0) { doubleBuffer = GL_TRUE; } else { printf("%s (Bad option).\n", argv[i]); return GL_FALSE; } } return GL_TRUE; } main(int argc, char **argv) { GLenum type; glutInit(&argc, argv); Args(argc, argv); type = GLUT_STEREO; type |= (rgb) ? GLUT_RGB : GLUT_INDEX; type |= (doubleBuffer) ? GLUT_DOUBLE : GLUT_SINGLE; glutInitDisplayMode(type); glutInitWindowSize(300, 300); glutCreateWindow("Airplane"); Init(); glutReshapeFunc(Reshape); glutKeyboardFunc(Key); glutIdleFunc(DrawScene); glutDisplayFunc(DrawScene); glutMainLoop(); }