IRIS Development Option 6.2

home *** CD-ROM | disk | FTP | other *** search

/ IRIS Development Option 6.2 / IRIS_Development_Option_6.2_814-0478-001.iso / dist / gl_dev.idb / usr / relnotes / gl_dev / ch6.z / ch6

Wrap

Text File | 1996-03-14 | 36KB | 859 lines

- 1 - 6. _O_p_e_n_G_L OpenGL is supported on all graphics adaptors. Here is the complete list: Indy - XL 8/24 bits Indigo - Starter, XS, XS24, XZ, Elan IndigoII - XL, XZ, Extreme, Solid Impact, Maximum Impact, High Impact Crimson - Starter, XS, XS24, Elan, Extreme, VGX, VGXT, RealityEngine Onyx - InfiniteReality, RealityEngine2, RealityEngine, VTX These implementations pass Level 0 of the conformance tests (i.e., the "mustpass" test suite). Also, all the adaptors except VGX, and VGXT pass most of the balance of the conformance tests. The VGX, and VGXT use a rendering pipeline that is more like IrisGL and therefore fail most of the lighting conformance tests in addition to other tests. (Please see the conformance reports for details.) 6.1 _D_o_c_u_m_e_n_t_a_t_i_o_n The following documentation is available for OpenGL: +o The _O_p_e_n_G_L _P_r_o_g_r_a_m_m_i_n_g _G_u_i_d_e (Addison-Wesley, 1993) is a comprehensive guide to programming with OpenGL. +o The _O_p_e_n_G_L _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l (Addison-Wesley, 1992) contains an overview of OpenGL and man pages for all OpenGL, GLX and GLU functions. +o _O_p_e_n_G_L _o_n _S_i_l_i_c_o_n _G_r_a_p_h_i_c_s _S_y_s_t_e_m_s provides information that is essential for writing OpenGL applications in the X11 and IRIS IM environments, describes major SGI extensions to OpenGL, and gives advice for tuning OpenGL application performance. +o _T_h_e _O_p_e_n_G_L _P_o_r_t_i_n_g _G_u_i_d_e describes how to port programs that were written for IRIS GL. (Some of this information has been superseded by the material in _O_p_e_n_G_L _o_n _S_i_l_i_c_o_n _G_r_a_p_h_i_c_s _S_y_s_t_e_m_s.) +o The _I_R_I_S _P_r_o_g_r_a_m_m_i_n_g _N_o_t_e_s include documentation for X11, GL/GLX, Font Manager and mixed model programming in IRIS GL. The IRIS Development Option documentation includes online copies of _T_h_e _O_p_e_n_G_L _P_o_r_t_i_n_g _G_u_i_d_e, _O_p_e_n_G_L _o_n _S_i_l_i_c_o_n _G_r_a_p_h_i_c_s _S_y_s_t_e_m_s, the _I_R_I_S _P_r_o_g_r_a_m_m_i_n_g _N_o_t_e_s, the _O_p_e_n_G_L _P_r_o_g_r_a_m_m_i_n_g _G_u_i_d_e, the _O_p_e_n_G_L _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l and reference - 2 - pages (commonly known as ``man pages'') for all OpenGL, GLX and GLU functions. It includes a hardcopy of the _O_p_e_n_G_L _P_r_o_g_r_a_m_m_i_n_g _G_u_i_d_e. You may also order a hardcopy of the porting guide (part number M4-OGLPort-5.1) and the _O_p_e_n_G_L _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l (part number M4-OGLMAN-1.0). The reference pages for OpenGL commands have been updated with the latest information on machine-dependencies for each of the supported graphics adaptors. This includes performance tuning hints as well as known bugs and functionality subsetting warnings. If you're porting from IRIS GL to OpenGL, the best approach is to convert your program to a mixed-model program first (see the _I_R_I_S _P_r_o_g_r_a_m_m_i_n_g _N_o_t_e_s) and then consult _O_p_e_n_G_L _o_n _S_i_l_i_c_o_n _G_r_a_p_h_i_c_s _S_y_s_t_e_m_s followed by _T_h_e _O_p_e_n_G_L _P_o_r_t_i_n_g _G_u_i_d_e for more information. 6.2 _E_x_t_e_n_s_i_o_n_s The following OpenGL extensions are available in IRIX 6.2. For more information, please consult the _g_l_i_n_t_r_o reference page. +o _E_X_T__a_b_g_r extends the list of host-memory color formats. Specifically, it provides a reverse-order alternative to image format RGBA. The ABGR component order matches the cpack Iris GL format on big-endian machines. +o _E_X_T__b_l_e_n_d__c_o_l_o_r allows a constant to be used as a factor in the blending equation. A typical use is to blend two RGB images. Without the constant blend factor, one image must have an alpha channel with each pixel set to the desired blend factor. +o _E_X_T__b_l_e_n_d__l_o_g_i_c__o_p defines an additional blending equation for _g_l_B_l_e_n_d_E_q_u_a_t_i_o_n_E_X_T. This equation is a simple logical combination of the source and destination colors. +o _E_X_T__b_l_e_n_d__m_i_n_m_a_x allows the blend equation to be changed using _g_l_B_l_e_n_d_E_q_u_a_t_i_o_n_E_X_T and introduces two new blend equations, one to produce the minimum color components of the source and destination colors and one to produce the maximum. +o _E_X_T__b_l_e_n_d__s_u_b_t_r_a_c_t defines two additional blending equations for use with _g_l_B_l_e_n_d_E_q_u_a_t_i_o_n_E_X_T. These new equations are similar to the default blending equation, but produce the difference of its terms, rather than the sum. Image differences are useful in many image - 3 - processing applications. +o _S_G_I_X__c_l_i_p_m_a_p introduces new filtering and memory management techniques for handling extraordinarily large textures. Clipmaps provide many of the features of mipmaps, while using a small fraction of the texture memory required for mipmaps of equivalent size. They are especially useful for rendering terrain and roaming over large images. Clipmaps are supported on InfiniteReality systems. +o _S_G_I__c_o_l_o_r__m_a_t_r_i_x adds a 4x4 matrix stack and matrix multiplication to the pixel transfer path. The color matrix operates on RGBA pixel components. It can be used to reorder or duplicate color components, and to implement simple color-space conversions. +o _S_G_I__c_o_l_o_r__t_a_b_l_e defines a new RGBA-format color lookup table mechanism, and several new lookup tables in the OpenGL pixel path. The new lookup tables are treated as one-dimensional images with internal formats, like texture images and convolution filter images. This allows the tables to operate on a subset of the components of passing pixels. (For example, a table with internal format GL_ALPHA modifies only the A component of each passing pixel, leaving the R, G, and B components untouched.) A small subset of this extension is supported on RealityEngine, RealityEngine2, and VTX systems; because of this, the extension is not listed in the extensions string returned by _g_l_G_e_t_S_t_r_i_n_g. The full extension is supported on all other systems. +o _E_X_T__c_o_n_v_o_l_u_t_i_o_n adds 1- or 2-dimensional convolution operations to the pixel transfer process. Pixel drawing, reading, and copying, as well as texture image definition, are candidates for convolution. The convolution kernels are themselves treated as 1- and 2-dimensional images, which can be loaded from application memory or from the framebuffer. A subset of this extension is supported on RealityEngine, RealityEngine2, and VTX systems; the full extension is supported on all other systems. +o _E_X_T__c_o_p_y__t_e_x_t_u_r_e provides the ability to copy pixels directly from the framebuffer into texture memory. At present only a small subset of this extension has been implemented on RealityEngine, RealityEngine2, and VTX systems, so the extension name is not listed in the extensions string returned by _g_l_G_e_t_S_t_r_i_n_g. It is fully supported on all other systems. - 4 - +o _S_G_I_S__d_e_t_a_i_l__t_e_x_t_u_r_e introduces texture magnification filters that blend between the level 0 image and a separately defined "detail" image. This detail blending can be enabled for all color channels, for the alpha channel only, or for the red, green, and blue channels only. It is available only for 2D textures. Supported on RealityEngine, RealityEngine2, and VTX systems and on InfiniteReality systems. +o _S_G_I_S__f_o_g__f_u_n_c Standard OpenGL defines three fog modes: GL_LINEAR, GL_EXP (exponential), and GL_EXP2 (exponential squared). Visual simulation systems can benefit from more sophisticated atmospheric effects. This extension provides the ability to define a custom fog blending function by specifying a set of control points that will be interpolated by the function. Supported on InfiniteReality systems. +o _S_G_I_X__f_o_g__o_f_f_s_e_t In highly-fogged environments, emissive objects (like simulated automobile headlights or runway landing lights) can appear unrealistically dim. This extension brightens fogged objects by offsetting the Z value used in fog computations. Supported on InfiniteReality systems. +o _E_X_T__h_i_s_t_o_g_r_a_m defines pixel operations that count occurrences of specific color component values (histogram) and track the minimum and maximum color component values (minmax). An optional mode allows pixel data to be discarded after the histogram and/or minmax operations are completed. Otherwise the pixel data continue on to the next operation unaffected. +o _S_G_I_X__i_n_t_e_r_l_a_c_e modifies the behavior of _g_l_D_r_a_w_P_i_x_e_l_s, _g_l_C_o_p_y_P_i_x_e_l_s, _g_l_T_e_x_I_m_a_g_e_2_D, _g_l_T_e_x_S_u_b_I_m_a_g_e_2_D_E_X_T, _g_l_C_o_p_y_T_e_x_I_m_a_g_e_2_D_E_X_T and _g_l_C_o_p_y_T_e_x_S_u_b_I_m_a_g_e_2_D_E_X_T, such that when GL_INTERLACE_SGIX is enabled the source image is considered to be a field of an "interlaced" frame. This is particularly useful for assembling consecutive interlaced video format fields to into a complete frame in either the framebuffer or in texture memory. Supported on RealityEngine, RealityEngine2, and VTX systems and on InfiniteReality systems. +o _S_G_I_S__m_u_l_t_i_s_a_m_p_l_e provides a mechanism to antialias all primitives. The technique is to sample all primitives multiple times at different locations within each pixel (rather than just the pixel center). The color sample values are resolved to a single, displayable color each time a pixel is updated, so the antialiasing appears to be automatic at the application level. Supported on - 5 - RealityEngine, RealityEngine2, and VTX systems and on InfiniteReality systems. +o _E_X_T__p_a_c_k_e_d__p_i_x_e_l_s provides support for packed pixels in host memory. A packed pixel is represented entirely by one unsigned byte, one unsigned short, or one unsigned integer. The fields with the packed pixel are not proper machine types, but the pixel as a whole is. Thus the pixel storage modes, and their unpacking counterparts, all work correctly with packed pixels. This extension is not supported on RealityEngine, RealityEngine2, and VTX systems. +o _E_X_T__p_o_l_y_g_o_n__o_f_f_s_e_t allows depth values of fragments to be displaced so that lines (or points) and polygons that lie in the same plane can be rendered without interaction -- the lines are rendered either completely in front of or behind the polygons (depending on the sign of the offset factor). It also allows multiple coplanar polygons to be rendered without interaction, if different offset factors are used for each polygon. +o _S_G_I_X__p_o_l_y_n_o_m_i_a_l__f_f_d alters vertex coordinates, texture coordinates, and normals according to user-specified trivariate polynomials. The resulting deformations are useful in modelling and character animation. This extension is supported on InfiniteReality systems. +o _S_G_I_X__r_e_f_e_r_e_n_c_e__p_l_a_n_e allows a group of coplanar primitives to be rendered without depth-buffering artifacts. This is accomplished by generating the depth values for all the primitives from a single ``reference plane'' rather than from the primitives themselves. This ensures that all the primitives in the group have exactly the same depth value at any given sample point, no matter what imprecision may exist in the original specifications of the primitives or in the GL's coordinate transformation process. _S_G_I_X__r_e_f_e_r_e_n_c_e__p_l_a_n_e is useful for generating hidden- line drawings, for applying decals to polygons, and for multipass rendering techniques. Supported on InfiniteReality systems. +o _S_G_I_X__s_h_a_d_o_w provides support for rendering shadows using shadow maps. First the application renders the scene from the point of view of the light source, and copies the resulting depth buffer to a texture with internal format GL_DEPTH_COMPONENT. Next the application renders the scene from the normal viewpoint. Then the application enables the texture parameter GL_TEXTURE_COMPARE_SGIX, sets the texture - 6 - comparison operator and texture matrix appropriately, and re-renders the scene with 2D texturing enabled. During this final rendering pass, the depth value generated by iterating the _r texture coordinate is compared with the shadow map stored in texture memory, and the results of the comparison indicate whether the pixel being textured is in shadow. The filtered result of the shadow comparisons can be blended with the pixel to darken it. Supported on InfiniteReality systems. +o _S_G_I_X__s_h_a_d_o_w__a_m_b_i_e_n_t controls the filtered texture value generated in shadowed regions (see _S_G_I_X__s_h_a_d_o_w). In effect, this changes the ambient lighting in shadows. Supported on InfiniteReality systems. +o _S_G_I_S__s_h_a_r_p_e_n__t_e_x_t_u_r_e introduces texture magnification filters that sharpen the resulting image by extrapolating from the level 1 image to the level 0 image. Sharpening can be enabled for all color channels, for the alpha channel only, or for the red, green, and blue channels only. Supported on RealityEngine, RealityEngine2, and VTX systems and on InfiniteReality systems. +o _E_X_T__s_u_b_t_e_x_t_u_r_e allows a contiguous portion of an already-existing texture image to be redefined without affecting the remaining portion of the image or any of the other state that describes the texture. There are three new calls: _g_l_T_e_x_S_u_b_I_m_a_g_e_1_D_E_X_T, _g_l_T_e_x_S_u_b_I_m_a_g_e_2_D_E_X_T, and _g_l_T_e_x_S_u_b_I_m_a_g_e_3_D_E_X_T. A subset of this extension is available on RealityEngine, RealityEngine2, and VTX systems, and the full extension is available on all other systems. +o _E_X_T__t_e_x_t_u_r_e provides support for a variety of resolutions of color components in texture images. That is, instead of treating a retained image as having 1, 2, 3, or 4 components, it is treated as though it had a specific format, such as GL_LUMINANCE_ALPHA, or just GL_ALPHA. This extension also defines a robust method for applications to determine what combinations of texture dimensions and resolutions are supported by an implementation and it introduces a new texture environment: GL_REPLACE_EXT. +o _E_X_T__t_e_x_t_u_r_e_3_D supports 3-dimensional texture mapping. It also defines the in-memory formats for 3D images, and adds pixel storage modes to support them. +o _S_G_I_X__t_e_x_t_u_r_e__a_d_d__e_n_v defines a new texture environment function which scales the texture value by the constant - 7 - texture color and then adds a bias color. Supported only on InfiniteReality systems. +o _S_G_I__t_e_x_t_u_r_e__c_o_l_o_r__t_a_b_l_e adds a color lookup table to the texture mapping process. +o _S_G_I_S__t_e_x_t_u_r_e__e_d_g_e__c_l_a_m_p The GL normally clamps texture coordinates to the range [0,1]. This can cause the texture sampling filter to straddle the edge of the texture image, taking half its sample values from within the texture image, and the other half from the texture border. Sometimes this is undesirable. _S_G_I_S__t_e_x_t_u_r_e__e_d_g_e__c_l_a_m_p defines a new texture clamping method that ensures all sample values fall within the texture image. +o _S_G_I_S__t_e_x_t_u_r_e__f_i_l_t_e_r_4 allows 1D and 2D textures to be filtered using an application-defined symmetric and separable filter with four samples per dimension. In the most common 2D case, the filter is bicubic. This filtering can yield better-quality images than mipmapping, and is often used in image processing applications. Supported on InfiniteReality systems. +o _S_G_I_S__t_e_x_t_u_r_e__l_o_d provides mechanisms that reduce the number of mipmap levels required for mipmapped texturing. This allows a large texture to be loaded and used initially at low resolution, and to increase the resolution gradually as time passes or as more mipmap levels become available. Supported on InfiniteReality systems. +o _E_X_T__t_e_x_t_u_r_e__o_b_j_e_c_t supports named texture objects whose contents and parameters may be changed after they are defined. (Contrast this with textures in display lists, which cannot be modified after the display lists are created.) For machines with special texture memories, _E_X_T__t_e_x_t_u_r_e__o_b_j_e_c_t also provides simple texture memory management. +o _S_G_I_X__t_e_x_t_u_r_e__s_c_a_l_e__b_i_a_s adds scale, bias, and clamp operations to the texture pipeline. These operations are applied to the filtered result of a texture lookup, before that result is used in the texture environment equations and before the texture color lookup table of _S_G_I__t_e_x_t_u_r_e__c_o_l_o_r__t_a_b_l_e. +o _E_X_T__v_e_r_t_e_x__a_r_r_a_y adds the ability to specify multiple geometric primitives with very few subroutine calls. Instead of calling an OpenGL procedure to pass each individual vertex, normal, or color, separate arrays of - 8 - vertexes, normals, and colors are prespecified, and are used to define a sequence of primitives (all of the same type) when a single call is made to _g_l_D_r_a_w_A_r_r_a_y_s_E_X_T. A stride mechanism is provided so that an application can choose to keep all vertex data staggered in a single array, or sparsely in separate arrays, but single-array storage generally will provide better performance. This extension also supports the rendering of individual array elements, each specified as an index into the enabled arrays. The following GLX extensions are available in 6.2. For detailed information, please consult the _g_l_x_i_n_t_r_o reference page. +o _S_G_I_X__f_b_c_o_n_f_i_g introduces a new way to describe the capabilities of a GLX drawable (i.e., to describe the depth of color buffer components and the type and size of ancillary buffers), removes the "similarity" requirement when making a context current to a drawable, and supports RGBA rendering to one- and two- component Windows and GLX Pixmaps. +o _E_X_T__i_m_p_o_r_t__c_o_n_t_e_x_t allows multiple X clients to share an indirect rendering context. Also, two convenience routines are added: one to get the display for the current context and one to retrieve the attributes that a context was created with. +o _S_G_I__m_a_k_e__c_u_r_r_e_n_t__r_e_a_d allows OpenGL pixel operations to read pixel data from the buffers of one drawable and draw into the buffers of another. For example, pixels can be copied from one window into another, or from a GLXPbuffer into a window. +o _S_G_I_S__m_u_l_t_i_s_a_m_p_l_e provides a mechanism to antialias all primitives. In order to support multisampling both GLX and OpenGL had to be extended. The GLX portion of the extension includes new visual attributes which can be specified when calling _g_l_X_C_h_o_o_s_e_V_i_s_u_a_l and _g_l_X_G_e_t_C_o_n_f_i_g. This extension is supported on RealityEngine, RealityEngine2, and VTX systems, and on InfiniteReality systems. +o _S_G_I_X__p_b_u_f_f_e_r defines GLX pixel buffers, which are additional non-visible rendering buffers for an OpenGL renderer. GLX pixel buffers are typically allocated in non-visible frame buffer memory. They are intended to be "static" resources, in that a program will typically allocate them only once, rather than as a part of its rendering loop. Also the frame buffer resources that - 9 - are associated with a GLX pixel buffer are static, and are deallocated only when the GLXPbuffer is destroyed, or, in the case of a _u_n_p_r_e_s_e_r_v_e_d GLX pixel buffer, as a result of X server activity that changes its frame buffer requirements. +o _S_G_I__s_w_a_p__c_o_n_t_r_o_l provides new parameters that modify the semantics of _g_l_S_w_a_p_B_u_f_f_e_r_s. With this extension an application can specify a minimum periodicity for color buffer swaps, measured in display retrace periods. +o _S_G_I_X__v_i_d_e_o__r_e_s_i_z_e allows the frame buffer to be resized to the output resolution of the video channel when _S_w_a_p_B_u_f_f_e_r_s is called for the window that is bound to the video channel. This extension is supported only on InfiniteReality systems. +o _S_G_I_X__v_i_d_e_o__s_o_u_r_c_e allows pixel data to be sourced from a video input stream. It defines a new type of drawable, GLXVideoSourceSGIX, that represents the drain node of a Video Library (VL) path. A GLXVideoSourceSGIX may be passed as a parameter to _g_l_X_M_a_k_e_C_u_r_r_e_n_t_R_e_a_d_S_G_I to indicate that pixel data should be read from the specified video source instead of from the framebuffer. +o _S_G_I__v_i_d_e_o__s_y_n_c provides a means for synchronization with the video frame rate of a monitor - or, in the case of an interlaced monitor, with the field rate of the monitor. +o _E_X_T__v_i_s_u_a_l__i_n_f_o allows the user to request a particular X visual type to be associated with a GLX visual, and allows the user to query the X visual type underlying a GLX visual. In addition, this extension provides a means to request a visual with a transparent pixel and to query whether a visual supports a transparent pixel value and the value of the transparent pixel. +o _E_X_T__v_i_s_u_a_l__r_a_t_i_n_g allows servers to identify a particular GLX visual as undesirable. This allows servers to export visuals with improved features or image quality, but lower performance or greater system burden, without having to have these visuals selected preferentially. - 10 - 6.3 _N_e_w__F_e_a_t_u_r_e_s__i_n__6_._2 In IRIX 5.3, an OpenGL debugging utility, ogldebug, was added. ogldebug is a development tool that allows you to examine OpenGL calls generated by an application. See the _o_g_l_d_e_b_u_g reference page for details. Also, in IRIX 6.2, two new OpenGL utility libraries were added: GLC is a subroutine library that provides OpenGL programs with character rendering services (consult the _g_l_c_i_n_t_r_o reference page for details), GLS is a facility for encoding and decoding streams of 8-bit bytes that represent sequences of OpenGL commands (consult the _g_l_s_i_n_t_r_o reference page for details). 6.4 _C_h_a_n_g_e_s_,__A_d_d_i_t_i_o_n_s__a_n_d__K_n_o_w_n__P_r_o_b_l_e_m_s__i_n__6_._2 IRIX 6.2 includes the OpenGL functionality previously provided by IRIX 5.3 with patches 154 and 918, plus support for more extensions on all platforms and support for IMPACT and InfiniteReality. Auxbuffers, which were removed in IRIX 5.3, are once again supported on RealityEngine, RealityEngine2, VTX, and InfiniteReality systems. Starting in 6.2, all known problems and machine-dependencies for OpenGL are documented in the OpenGL man pages. This provides an integrated source of information for development and debugging. 6.5 _C_h_a_n_g_e_s_,__A_d_d_i_t_i_o_n_s__a_n_d__K_n_o_w_n__P_r_o_b_l_e_m_s__i_n__5_._3__a_n_d__6_._1 Aux buffers are no longer supported on any platform. In Irix 5.2, RealityEngine, Extreme, and Elan systems had OpenGL visuals that supported aux buffers. However, since rendering to aux buffers could cause serious data corruption, and the problem could not be repaired in time for release, support for aux buffers was removed in 5.3 and 6.1. The following problems exist in 5.3, 6.1, and earlier releases: +o Textures loaded using glPixelMap might be corrupted when enough textures are loaded to cause kernel management of texture memory. Corruption should occur only if the glPixelMap has changed or been disabled since the original load. - 11 - +o Line stippling for antialiased lines is not quite correct on Onyx systems. +o Different OpenGL processes which render to the same window using direct rendering will not share the software ancillary buffers on that window. +o X and OpenGL do not coordinate swapping on double- buffered windows properly. +o The GLX specification allows rendering contexts to be shared within an address space. This implies that an indirect rendering context may be used by different clients connected to the same server, and that a direct rendering context may be used by different threads sharing the address space of a single client. However, neither of these are currently supported, and attempting either can result in a graphics or system hang. If an application requires more than one rendering thread then it must create a separate context for each thread. +o If an OpenGL program does a server grab using its X connection, then for the duration of the grab it should not render OpenGL into any window that the client doing the grab did not create. Otherwise a deadlock occurs. The client is still able to do X rendering. This holds for both local and remote rendering. +o glXCopyContext does not work correctly if the source context is not the current context or if the destination context has never been made current. +o On XS/XZ/Elan/Extreme, Indy, XL, Indigo Entry, PI and VGX it is not possible to create a texture map with borders that is MAX_TEXTURE_SIZE X MAX_TEXTURE_SIZE (i.e., 1024 X 1024). Due to a bug, the maximum texture size is 512 X 512 if the texture has borders. (The width (and height) parameters for glTexImage1D (and glTexImage2D) would be set to 512 + border). +o For RealityEngine systems, the _b_o_r_d_e_r texels for the glTexImage1D and glTexImage2D calls are ignored. +o On Personal Iris systems, when calling glXChooseVisual to get an OpenGL-capable visual, add the attribute "GLX_RED_SIZE 1" to attribList--otherwise you may get back an invalid visual. Due to this bug, it is only possible to select deep visuals on Personal Iris systems. - 12 - +o No locking of display list structures is done on behalf of indirect OpenGL contexts that share display list spaces. Applications that use such contexts should use their own mechanisms to ensure mutual exclusion when defining or destroying display lists. +o When running OpenGL applications that use indirect rendering, it is normal for more than one instance of _X_s_g_i, the SGI X server, to show up under _p_s. They represent multiple threads of the X server, used to implement indirect rendering. +o You may notice some discrepancies between the OpenGL Reference Manual which is available through InSight and the man pages you see when you type "man glXxx" in a shell window. If so, you should believe what you see in the shell window. 6.6 _C_h_a_n_g_e_s_,__A_d_d_i_t_i_o_n_s__a_n_d__K_n_o_w_n__P_r_o_b_l_e_m_s__i_n__5_._2 The following problems are known to exist in 5.2 and earlier releases: +o During direct rendering, software buffers that are associated with the window are not freed when the window is destroyed, but rather when the display connection is closed. (The machine type determines which buffers are implemented in software; on Indigo Starter and Indy, for example, depth buffer, stencil buffer, and accum buffer are all software buffers.) In 5.2, a workaround was included to force the buffers to be cleaned up, at the cost of an extra X connection. To enable this feature, do setenv GL_CHECK_WINDOW_DESTROY y before the first glXCreateContext. It will check for window destroy events and clean up memory the next time any rendering context is bound to a new window. +o Rendering to aux buffers does not work correctly on RealityEngine, EXTREME and Elan systems. 6.7 _C_h_a_n_g_e_s_,__A_d_d_i_t_i_o_n_s__a_n_d__K_n_o_w_n__P_r_o_b_l_e_m_s__i_n__5_._1_x The following problems are known to exist in 5.1 and earlier releases: +o For RealityEngine systems, visuals that include a 12- bit accumulation buffer do not pass the conformance - 13 - tests. The 12-bit accumulation buffer is implemented using unsigned arithmetic, but the OpenGL specification requires signed arithmetic. The 24-bit accumulation buffer implementation is conforming. +o The command glCopyContext is not functional on Onyx systems. +o Using the _4_D_w_m menubar ``Quit'' or ``Close'' items to kill an OpenGL application that uses an indirect context will occasionally cause X server threads to not get freed when the application terminates. +o Once an OpenGL indirect context has been made current to a window, avoid making it current to a pixmap. Likewise, once an indirect context has been made current to a pixmap, avoid making it current to a window. +o Multiple OpenGL renderers rendering to the same window does not always work. +o These releases are not `tuned' nor are they thoroughly tested.