Digital Open3D Version 4.5 for Digital UNIX Release Notes September 1997 Digital Equipment Corporation Maynard, Massachusetts September 1997 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 1997. All rights reserved. The following are trademarks of Digital Equipment Corporation: 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. Freedom Series is a registered trademark of Evans & Sutherland Computer Corporation. 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.4.2.1 Digital Open3D Extensions Clause 3 1.4.2.2 DECStereo Extension Load 4 1.4.2.3 Using the Software-only Version of OpenGL 4 1.4.2.3.1 Using the Software-Only Version of OpenGL with PowerStorm 3D10 Devices 5 1.4.2.3.2 Using the Software-Only Version of OpenGL with Preconfigured Devices other than the PowerStorm 3D10 5 1.5 Alternate Console 5 2. CHAPTER 2 NEW WITH THIS RELEASE 7 2.1 New Hardware 7 2.1.1 New Graphics Options 7 2.1.2 New Workstations Supported 7 2.1.3 AlphaServer 4100 7 2.2 New Software 7 2.2.1 Updated Advanced Developer's Kit 7 2.3 Internet Distribution and Installation 7 2.4 Problems Fixed in Digital Open3D Version 4.5 8 2.4.1 Visual Errors with PowerStorm 4DxxT 8 2.5 Known Problems 8 2.5.1 Systems With More Than One Gigabyte (1GB) of Memory 8 2.5.2 Window Movement Lagging Mouse Movement in 4D40T 8 2.5.3 OpenGL Sample and Example Programs May Not Build Correctly 8 2.5.3.1 Missing Source Files and Directories 9 2.5.3.2 Incomplete Makefiles 9 2.5.4 Front vs. Back Orientation of Polygon Faces 9 2.5.5 Missing Triangles on ZLXp-E3 and PowerStorm 4D20 9 2.5.6 VGA Jumper on PowerStorm 3D30 and 4D20 9 2.5.7 Console Display on Multihead Systems 9 2.5.8 PEX IVP Failure on ZLX-E1, ZLXp-E1 and PowerStorm 3D30 10 2.5.9 Monitor Resolution and Frequency 10 2.5.10 Slow Window Dragging on ZLXp-L Options 10 2.5.11 Clipped Edges on ZLX-E and ZLXp-E 10 3. CHAPTER 3 RELEASE INFORMATION FOR POWERSTORM 4D40T, 4D50T, 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.1.1 Applications That Link With Static Libraries 12 3.4.1.2 Multihead Support with the PowerStorm 4D40T, 4D50T, and 4D60T 12 3.4.1.3 Backing Store and Save Unders Are Disabled 12 3.4.2 OpenGL Restrictions 13 3.4.2.1 Applications Coded to Request Indirect Rendering Only 13 3.4.2.2 GLX Pixmap Support 13 3.4.2.3 Texture Image Size Limitation 13 3.4.2.4 4D Vertex Handling Incorrect in Some Cases 13 3.4.2.5 MIPMAP Rendering 13 3.4.2.6 GLUT Restrictions 13 3.4.2.7 Primitives Outside a glBegin/glEnd Block 14 3.4.2.8 Antialiasing in Color Index Mode 14 3.4.3 Performance and System Characteristics 14 3.4.3.1 Texture Mapping and Performance 15 3.4.3.2 OpenGL Pixmap Performance 15 3.4.3.3 RGB Format 15 3.4.3.4 Usage of Shared Memory by the PowerStorm 4D40T, 4D50T and 4D60T 16 3.4.4 PowerStorm 4D40T, 4D50T, 4D60T Supported Video Modes 18 4. CHAPTER 4 CORE SERVER FUNCTIONALITY FOR GRAPHICS ACCELERATORS 21 4.1 3D Graphics Acceleration on ZLX-E1, ZLXp-E1 and PowerStorm 3D30 21 4.2 RGB Color Interpolation and Dithering on ZLX-E1, ZLXp-E1 and PowerStorm 3D30 21 4.2.1 Access through OpenGL 22 4.2.2 Access through PEX 22 4.3 3D Graphics Acceleration on ZLX-E2 and ZLXp-E2 23 4.4 3D Graphics Acceleration on ZLX-E3, ZLXp-E3, and PowerStorm 4D20 24 4.5 Selecting Default Visual Types 25 4.5.1 Motif Window Manager Default Visual Types 25 4.5.2 CDE Window Manager Default Visual Types 25 4.6 ZLX-L series 26 4.7 Overlay Support 26 4.7.1 Technical Background 26 4.7.2 Motif Window Manager for Overlays 27 4.8 Multiple Colormaps 27 4.9 DECStereo Extension 28 4.9.1 Query and Load the DECStereo Extension 29 4.9.2 Query the DECStereo Extension Version 29 4.9.3 Set the Stereo Mode 29 4.9.4 Query the Stereo Mode 29 5. CHAPTER 5 KNOWN RESTRICTIONS AND PROBLEMS 31 5.1 Operating System Restrictions 31 5.1.1 Firmware Revision Level for Freedom Series 31 5.1.2 Freedom Series Screen Not Cleared Upon Reboot 31 5.1.3 Turning BLOCKMODE I/O on in TURBOchannel-Based Systems 31 5.2 Overlay Window Manager Restrictions 31 5.3 X Restrictions 32 5.3.1 Freedom Series Error Messages in xdm-errors File 32 5.3.2 X and OpenGL Interaction Hang on Freedom Series 32 5.3.3 Vertical Lines of Dots on Freedom Series 32 5.3.4 Backing Store Support 33 5.3.5 Save Under Support 33 5.3.6 Multihead Support 34 5.4 PEX Restrictions 34 5.4.1 Support of MIT PEXlib Functions 34 5.4.2 No PEX Support for Freedom Series, PowerStorm 3D10, or HX Graphics 34 5.4.3 Transparency Using PEX 35 5.4.4 PEXQuadMesh Compatibility 35 5.4.5 Edge Flags and Shared Edges 36 5.5 OpenGL Restrictions 36 5.5.1 Freedom Series-only Restrictions 36 5.5.1.1 Direct Rendering in OpenGL 36 5.5.1.2 Pixmap Rendering Not Supported 36 5.5.1.3 Texture Boundary Limitiations 36 5.5.1.4 Texture Interpolation for Large Polygons 36 5.5.1.5 3D Line Drawing Not Identical in Opposite Directions 36 5.5.1.6 Linelists Sometimes Drop Vertices 37 5.5.1.7 Polygon Stipple Limitations 37 5.5.1.8 Multiple Contexts Limitation 37 5.5.1.9 3D Textures 37 5.5.1.10 MIPmapping Limitations 37 5.5.1.11 Perspective Correction and Depth Values 37 5.5.2 Non-Digital Example Imakefiles 37 5.5.3 Antialiased Operations 38 5.6 ZLX-M and ZLX-L Restrictions 38 5.6.1 Drawing Convex Polygons 38 5.6.2 Multibuffer Support 38 5.6.2.1 -screenOrder Option 38 5.6.2.2 -forceDepth 4 option present 39 5.6.3 3D-Specific Display and Rendering Corruptions 39 5.6.3.1 Z-buffer precision 39 5.6.3.2 8-Plane Colorspace 39 5.6.3.3 Lighting Restrictions 39 5.6.3.4 Homogeneous Coordinates 39 5.6.3.5 Antialiased Operations 40 5.6.3.6 Surface Primitives Rendered Non-sequentially 40 5.6.3.7 OpenGL Repeat Factor and Stippled Lines 40 5.6.3.8 OpenGL Stencil Buffer Update 40 5.6.3.9 OpenGL Accumulation Buffer 40 5.6.3.10 OpenGL Silhouette Polygons 40 5.6.3.11 OpenGL NORMALIZE Mode 40 5.6.4 2D Specific Display and Rendering Corruptions 41 5.6.4.1 Pseudocolor Support 41 5.7 ZLX-E, ZLXp-E, PowerStorm 3D30 and 4D20 Restrictions 41 5.7.1 DEC 3000 Model 300 Server Crashes 41 5.7.2 3D Display Corruption and Rendering Restrictions 41 5.7.2.1 Resizing OpenGL Client Window 41 5.8 PXG Restrictions 41 5.9 Multihead ZLX Configurations 42 6. CHAPTER 6 APPLICATION NOTES FOR OPENGL STEREO RENDERING FOR POWERSTORM 4D40T, 4D50T AND 4D60T 44 6.1 Stereo Support 44 6.2 Enabling Stereo from an Application 45 6.3 Supported Hardware 45 6.4 Supported Screen Resolutions and Refresh Rates 46 6.5 Supported Visuals 47 6.6 Backing Store 48 6.7 Left and Right Construction Planes 48 6.8 Common Questions 49 6.9 Application Example 50 Preface This document contains the release notes for Digital Open3DT Version 4.5 for Digital UNIXT. Release notes are supplied in both ASCII and PostScriptr format and are located, respectively, in the following locations: ? /usr/lib/OPEN3D/open3d450.release_notes ? /usr/lib/OPEN3D/open3d450.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.5 for Digital UNIXr supports the following devices: ? PCI-based graphics options: ZLXp-L series and 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 Please see the Software Product Description (SPD) 45.07.20 for exact options supported. 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.5 only on systems that are running Digital UNIX Version 4.0a, 4.0b or 4.0c. Before installing Digital Open3D Version 4.5, 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. 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 and Section 1.4.2.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 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 > > < 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 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 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.5. 2.1 New Hardware 2.1.1 New Graphics Options There is no new graphics hardware supported for the first time in this release. 2.1.2 New Workstations Supported No new workstations are supported for this release. Workstations with higher clock frequencies are now being supported. 2.1.3 AlphaServer 4100 Limited qualification of the PowerStorm 4D20 on an AlphaServer 4100 has shown no errors running X and OpenGL software. However, no PEX software has been tested on these machines, and to support of this older API is planned. 2.2 New Software 2.2.1 Updated Advanced Developer's Kit This release contains an update to the "Shared3D (Shared Desktop)" Advanced Development Kit (ADK). Documentation and software for this updated ADK are located in /usr/var/X11/shr3d and /usr/bin/X11/shr3d respectively. 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.5 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.5 2.4.1 Visual Errors with PowerStorm 4DxxT There have been several reports of OpenGL errors when using the PowerStorm 4DxxT boards. All of the reported problems have been fixed. 2.5 Known Problems 2.5.1 Systems With More Than One Gigabyte (1GB) of Memory In earlier releases there was a limitation on putting the PowerStorm 3D30 and 4D20 into systems with more than one gigabyte (1GB) of memory. This restriction has been removed. However, it requires that the kernel be rebuilt to include the new driver before increasing the memory to more than 1GB. With the updated driver in place, the memory can be increased beyond 1GB. (If the older driver is in the kernel when the memory is increased, the system will not boot. Reduce the memory to less than 1GB, rebuild the kernel with the updated driver, then increase the memory.) PowerStorm 4DxxT devices will not work reliably in systems with more than one gigabyte of memory. This will be fixed in a later release. 2.5.2 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.3 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.3.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.3.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.4 Front vs. Back Orientation of Polygon Faces 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.5 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.6 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.7 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.8 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.9 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.10 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.11 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, 4D60T 3.1 Product Summary Digital Open3D Version 4.5 contains the Digital UNIX graphics support for the AlphaStation PowerStorm models 4D40T, 4D50T 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, and 4D60T software has been completed, the machine needs to be rebooted. This reboot will enable the PowerStorm 4D40T, 4D50T, and 4D60T 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, and 4D60T The PowerStorm 4D40T, 4D50T, 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. They can be enabled by modifying the command-line arguments to the Xserver. To change the command-line arguments that the Xserver uses, login as root and edit the file /var/X11/Xserver.conf. Search for the following lines in this file: ! Cateye Server args start pn -nice -2 -bs -su ! Cateye Server args end To enable backing store and save unders, remove -bs -su from the command line. Backing store is restricted on some screen resolutions. For further information see section "PowerStorm 4D40T, 4D50T, 4D60T Supported Video Modes". 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, 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, 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 height and width of texture images are 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, 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, 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 the client, server and any pvrm process) 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. 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 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 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 and 4D60T In order to improve performance, the PowerStorm 4D40T, 4D50T and 4D60T system makes 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. There are two system limits that affect how much shared memory can be used at a time. There is a system-wide limit of 128 shared memory handles. There is a per-process limit of 32 handles that may be attached at a time. The Open3D kit for the PowerStorm 4D40T, 4D50T and 4D60T increases these values to 256 and 64 respectively. Digital recommends that you configure the system with at least the limits described in the following steps. This should be done when logged in as root: 1) Save the ipc subsystem parameters to a file using the following command: sysconfigdb -l ipc > /tmp/ipc.config 2) Edit the saved ipc.config in /tmp/ipc.config and set the shared memory parameters to the desired values. shm-mni is the number of shared memory segments available on the system. shm-seg is the number of shared memory segments available to any individual process. The shm-seg value should be fairly high as the Xserver process needs to connect to most shared memory segments. shm-max is the amount of shared memory available on the system. This needs to include the maximum amount of the above items you expect to use on this system. 3) Update ipc subsystem in sysconfigtab. # sysconfigdb -f /tmp/ipc.config -u ipc # sysconfigdb -l ipc ipc: shm-mni = 1024 shm-seg = 256 shm-max = 67108864 4) Save the vm subsystem parameters to a file using the following command: # sysconfigdb -l vm > /tmp/vm.config If this command gives an error indicating that there is no vm subsystem, then create a file called /tmp/vm.config with the following contents vm: vm-mapentries=1000000 Then issue the following command # sysconfigdb -f /tmp/vm.config -a vm Go to step 6) 5) If there is an existing vm subsystem, then edit /tmp/vm.config and add the following line: vm-mapentries=1000000 If there is already an entry for vm-mapentries, add 1000000 to the current value. Then issue the following command: # sysconfigdb -f /tmp/vm.config -u vm 6) Reboot the machine. You can verify that the new parameter values are in effect by issuing the following commands: sysconfig -q ipc shm-mni | grep shm-mni sysconfig -q ipc shm-seg | grep shm-seg sysconfig -q ipc shm-max | grep shm-ma # sysconfig -q ipc shm-mni | grep shm-mni shm-mni = 1024 # sysconfig -q ipc shm-seg | grep shm-seg shm-seg = 256 # sysconfig -q ipc shm-max | grep shm-max shm-max = 67108864 Note that each time Open3D is installed shm-mni is reset to 256, shm-seq is reset to 64 and shm-max is removed from the configuration. These values must be updated manually after every installation of Open3D. 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. | |Ref. | 102 Plane Mode | 128 Plane Mode | Width |Height |Rate | 4D40T 4D50T 4D60T | 4D40T 4D50T 4D60T | ---------------------------------------------------------------------- 1600 1200(a) 75 No No Yes No No Yes ---------------------------------------------------------------------- 1600 1200(a) 65 No No Yes No No Yes ---------------------------------------------------------------------- 1280 1024 75 Yes(b) Yes(b) Yes No No Yes ---------------------------------------------------------------------- 1280 1024 72 Yes(b) Yes(b) Yes No No Yes ---------------------------------------------------------------------- 1280 1024 66 Yes(b) Yes(b) Yes No No Yes ---------------------------------------------------------------------- 1280 1024 60 Yes(b) Yes(b) Yes No No Yes ---------------------------------------------------------------------- 1152 900 76 Yes Yes Yes Yes(b) Yes(b) Yes(b) ---------------------------------------------------------------------- 1024 768 75 Yes Yes Yes Yes Yes Yes ---------------------------------------------------------------------- 1024 768 70 Yes Yes Yes Yes Yes Yes ---------------------------------------------------------------------- 1024 864 60 Yes Yes Yes Yes Yes Yes ---------------------------------------------------------------------- 800 600 75 Yes Yes Yes Yes Yes Yes ---------------------------------------------------------------------- 800 600 72 Yes Yes Yes Yes Yes Yes ---------------------------------------------------------------------- 800 600 60 Yes Yes Yes Yes Yes Yes ---------------------------------------------------------------------- 720 400 70 Yes Yes Yes Yes Yes Yes ---------------------------------------------------------------------- 640 480 75 Yes Yes Yes Yes Yes Yes ---------------------------------------------------------------------- 640 480 72 Yes Yes Yes Yes Yes Yes ---------------------------------------------------------------------- 640 480 60 Yes Yes Yes Yes Yes Yes ---------------------------------------------------------------------- (a) Contrary to some preliminary information, this is currently the highest supported screen resolution of the PowerStorm 4DT family of graphics options. 1600x1280 is 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 /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 -bs -su ! 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 -bs -su -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 -bs -su -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 -bs -su -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 `Xserver.conf'. If there are no other device-dependent options, remove the `-I' argument as well. NOTE In order to improve performance, the PowerStorm 4DT 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 Enable() with the symbolic constant "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 Depth Window Size Range Color Interpolation Z-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, PowerStorm 3D30 and the Freedom Series. 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, PowerStorm 4D20 and Freedom Series, 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 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 Firmware Revision Level for Freedom Series The Freedom Series require Version 3.0 or higher of the AlphaStation 600 SRM firmware. 5.1.2 Freedom Series Screen Not Cleared Upon Reboot The screen does not clear its prior image on reboot. Therefore, just before the server is activated, the image on the screen is the last image prior to the last reboot. This problem will not be fixed. 5.1.3 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 Freedom Series Error Messages in xdm-errors File The following error messages may appear in the /usr/lib/X11/xdm/xdm-errors file: Cannot load library _dec_3dlib: 3D supported graphics device not available Library _dec_3dlib will not be an available extension. Cannot load library _dec_x3d_pex: 3D supported graphics device not available Library _dec_x3d_pex will not be an available extension. Cannot load library _dec_opengl: 3D supported graphics device not available Library _dec_opengl will not be an available extension. MultibufferExtensionInit: Drawlib not loaded. EXTENSION: cannot find extension library for BIG-REQUESTS These errors do not affect the functionality of the server and should be ignored. 5.3.2 X and OpenGL Interaction Hang on Freedom Series The server may hang if some combination of X and OpenGL programs is left running for an extended period. The time it takes the system to hang depends on the CPU speed and can occur from 7 to 38 hours of continous use. There may be a message denoting "Fifo Timeout!" displayed in the error log or as a console message. The only recovery at this point is to restart the server. This problem will be fixed in a later release. 5.3.3 Vertical Lines of Dots on Freedom Series Under heavy graphics output usage, 2-3 vertical lines of dots may permanently appear on the left side of the screen. Once they appear, these dots will remain on the screen, regardless of the windowing activity, until the server is restarted. This problem will not be fixed. 5.3.4 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/lib/X11/Xserver.conf file: args < bs -su > NOTE You should save the original Xserver.conf file before editing it. If an args command already exists in the file 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.5 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.6 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. ? Multiple Freedom Series options are not supported. A single Freedom Series option will work with a single PowerStorm 3D30 or 4D20, and the non-Freedom Series device is restricted to 2D operations only. 5.4 PEX Restrictions This section describes restrictions of PEX library functions. 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 Freedom Series, PowerStorm 3D10, or HX Graphics There is no PEX support for any embedded or add-on HX devices, for the PowerStorm 3D10, or for an Freedom Series device. 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 Freedom Series-only Restrictions 5.5.1.1 Direct Rendering in OpenGL OpenGL direct rendering is not supported in this release. 5.5.1.2 Pixmap Rendering Not Supported Pixmap rendering is not supported in this release, and it is not planned for support in any in future releases. 5.5.1.3 Texture Boundary Limitiations When GL_TEXTURE_WRAP or GL_TEXTURE_WRAP_T is set to GL_CLAMP, and the texture coordinates go beyond the boundaries of the texture (0, 1), and there are no borders defined for the texture, then the hardware produces the texture border color rather than the edge of the texture blended with the texture border color. Textures with boundaries do work correctly. An example of this problem can be seen by running the OpenGL example program chess.c. If the effect is not desired, you can avoid it by keeping texture coordinates within the range 0 to 1. 5.5.1.4 Texture Interpolation for Large Polygons The hardware does not have enough precision to correctly interpolate texture coordinates across large polygons. Therefore when the filter mode is GL_NEAREST, single pixel jags can occur, like those shown in the OpenGL example program checker2. Changing the filter mode to GL_LINEAR eliminates this problem. 5.5.1.5 3D Line Drawing Not Identical in Opposite Directions When two lines are drawn from the same end points, but in opposite directions, they may not have exactly the same z values. One line may be slightly behind the other. 5.5.1.6 Linelists Sometimes Drop Vertices Shared vertices sometimes get dropped in programs using linelists. This is only noticeable when antialiasing is turned off. To avoid this problem, turn antialiasing on. 5.5.1.7 Polygon Stipple Limitations When polygon stipple is active, the front-facing polygon mode is used for both front- and back-facing polygons. To avoid this problem, use polygon cull and render the scene twice. 5.5.1.8 Multiple Contexts Limitation Client programs that use multiple contexts and a single drawable are not supported. 5.5.1.9 3D Textures OpenGL 1.0 does not implement 3D textures, but does allow you to specify 3D texture coordinates (looking to the future when 3D textures are standard). The OpenGL for Freedom Series software discards the third coordinate (because it is not used). Therefore, the feedback render mode always reports a value of 0.0 for the third texture coordinate. 5.5.1.10 MIPmapping Limitations The Freedom Series uses a different MIPmapping equation from the one in the OpenGL specification. The Freedom Series implementation is invariant with respect to rotations (that is, it produces the same MIPmap level regardless of the orientation of the polygon in the xy-plane). When MIPmaps are used properly (as smaller, filtered samplings of one image), the difference is hardly noticeable. The artifacts inherent in MIPmapping (due to compressing the coordinates non-uniformly) overshadow any problems from the MIPmap level interpolation. The difference is noticeable in a program like the OpenGL example program mipmap.c: the color banding does not appear. If you change the coordinates in the program, you can get an image that shows the results of linear interpolation better. 5.5.1.11 Perspective Correction and Depth Values Putting perspective correction into the OpenGL model matrix produces incorrect depth values. 5.5.2 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.3 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 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 4DT 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.5. 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 4DT 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 4DT 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, 'Default' 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. Supported Video Modes (* = Default) Resolution Refresh Rate (HxV) (HZ; *=Default) 1920x1200 76*,75,70,65,60 1920x1080 75,70,65,60* 1600x1280 75,70*,65,60 1600x1200 85,80,75*,70,65,60 1280x1024 85,80,75*,72,70,66,65,60 1152x900 110,105,100,95,90,85,80,76*,75,70,65,60 1024x768 115,110,105,100,95,90,85,80,75*,70,65,60 1024x864 140,135,130,125,120,115,110,105,100,95,90,85,80,75,70, 65,60* 800x600 140,135,130,125,120,115,110,105,100,95,90,85,80,75*,72, 70,65,60 640x480 150,145,140,135,130,125,120,115,110,105,100,95,90,85, 80,75*,72,70,65,60 ---------------------------------------------------------------------------- 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. ---------------------------------------------------------------------------- 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.7 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 DrawPixels) 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.8 Common Questions Q: I don't seem to have a proper cable to attach my stereo glasses to my PowerStorm 4DT. 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 the server exited. What happened? A: With the original version of the stereo kit, if an application attempted to use stereo when the server was running at a resolution that did not support stereo, the server would exit. If you suspect that this might be the case, check the Xserver error logs (/var/dt/Xerrors or /var/X11/xdm/xdm-errors). There should be a line indicating that a 'SET_VIDEO_MODE' call failed. If this is the case, check to make sure that the resolution you are using supports stereo. Note that stereo is not supported at the default resolutions on any card. This is fixed in the Open3D 4.3 release. 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 4DT card? A: No. DECstereo is not currently 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 4DT 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.9 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(); }