home *** CD-ROM | disk | FTP | other *** search
ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) OOOOppppeeeennnnGGGGLLLL RRRReeeeffffeeeerrrreeeennnncccceeee ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) NNNNAAAAMMMMEEEE ggggllllIIIInnnnttttrrrroooo - Introduction to OpenGL OOOOVVVVEEEERRRRVVVVIIIIEEEEWWWW OpenGL is a high-performance 3D-oriented renderer similar to IrisGL. It is supported on all SGI graphics adaptors except for the G, GT and GTX. A number of other vendors also support OpenGL. See ggggllllXXXXIIIInnnnttttrrrroooo for a short example program and compilation instructions. OOOOPPPPEEEENNNNGGGGLLLL EEEEXXXXTTTTEEEENNNNSSSSIIIIOOOONNNNSSSS SGI has implemented some extensions to OpenGL. The following extensions are supported on all platforms that support OpenGL: EEEEXXXXTTTT____aaaabbbbggggrrrr 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. (For more information see ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss, ggggllllGGGGeeeettttTTTTeeeexxxxIIIImmmmaaaaggggeeee, ggggllllRRRReeeeaaaaddddPPPPiiiixxxxeeeellllssss, ggggllllTTTTeeeexxxxIIIImmmmaaaaggggeeee1111DDDD, ggggllllTTTTeeeexxxxIIIImmmmaaaaggggeeee2222DDDD). EEEEXXXXTTTT____tttteeeexxxxttttuuuurrrreeee 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 GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE____AAAALLLLPPPPHHHHAAAA, or just GGGGLLLL____AAAALLLLPPPPHHHHAAAA. 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: GGGGLLLL____RRRREEEEPPPPLLLLAAAACCCCEEEE____EEEEXXXXTTTT. (For more information see ggggllllTTTTeeeexxxxIIIImmmmaaaaggggeeee1111DDDD, ggggllllTTTTeeeexxxxIIIImmmmaaaaggggeeee2222DDDD, ggggllllGGGGeeeettttTTTTeeeexxxxLLLLeeeevvvveeeellllPPPPaaaarrrraaaammmmeeeetttteeeerrrriiiivvvv, ggggllllGGGGeeeettttTTTTeeeexxxxLLLLeeeevvvveeeellllPPPPaaaarrrraaaammmmeeeetttteeeerrrrffffvvvv, ggggllllTTTTeeeexxxxEEEEnnnnvvvvffff, ggggllllTTTTeeeexxxxEEEEnnnnvvvviiii, ggggllllTTTTeeeexxxxEEEEnnnnvvvvffffvvvv, ggggllllTTTTeeeexxxxEEEEnnnnvvvviiiivvvv). EEEEXXXXTTTT____ppppoooollllyyyyggggoooonnnn____ooooffffffffsssseeeetttt 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. (For more information see ggggllllPPPPoooollllyyyyggggoooonnnnOOOOffffffffsssseeeettttEEEEXXXXTTTT, ggggllllEEEEnnnnaaaabbbblllleeee, ggggllllDDDDiiiissssaaaabbbblllleeee, ggggllllIIIIssssEEEEnnnnaaaabbbblllleeeedddd, ggggllllGGGGeeeettttBBBBoooooooolllleeeeaaaannnnvvvv, ggggllllGGGGeeeettttIIIInnnntttteeeeggggeeeerrrrvvvv, ggggllllGGGGeeeettttFFFFllllooooaaaattttvvvv, ggggllllGGGGeeeettttDDDDoooouuuubbbblllleeeevvvv). PPPPaaaaggggeeee 1111 ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) OOOOppppeeeennnnGGGGLLLL RRRReeeeffffeeeerrrreeeennnncccceeee ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) EEEEXXXXTTTT____bbbblllleeeennnndddd____ccccoooolllloooorrrr 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. (For more information see ggggllllBBBBlllleeeennnnddddCCCCoooolllloooorrrrEEEEXXXXTTTT, ggggllllBBBBlllleeeennnnddddFFFFuuuunnnncccc, ggggllllGGGGeeeettttBBBBoooooooolllleeeeaaaannnnvvvv, ggggllllGGGGeeeettttIIIInnnntttteeeeggggeeeerrrrvvvv, ggggllllGGGGeeeettttFFFFllllooooaaaattttvvvv, ggggllllGGGGeeeettttDDDDoooouuuubbbblllleeeevvvv). EEEEXXXXTTTT____bbbblllleeeennnndddd____mmmmiiiinnnnmmmmaaaaxxxx allows the blend equation to be changed using ggggllllBBBBlllleeeennnnddddEEEEqqqquuuuaaaattttiiiioooonnnnEEEEXXXXTTTT) 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. (Also see ggggllllGGGGeeeettttBBBBoooooooolllleeeeaaaannnnvvvv, ggggllllGGGGeeeettttIIIInnnntttteeeeggggeeeerrrrvvvv, ggggllllGGGGeeeettttFFFFllllooooaaaattttvvvv, ggggllllGGGGeeeettttDDDDoooouuuubbbblllleeeevvvv). EEEEXXXXTTTT____bbbblllleeeennnndddd____llllooooggggiiiicccc____oooopppp defines an additional blending equation for ggggllllBBBBlllleeeennnnddddEEEEqqqquuuuaaaattttiiiioooonnnnEEEEXXXXTTTT. This equation is a simple logical combination of the source and destination colors. (Also see ggggllllGGGGeeeettttBBBBoooooooolllleeeeaaaannnnvvvv, ggggllllGGGGeeeettttIIIInnnntttteeeeggggeeeerrrrvvvv, ggggllllGGGGeeeettttFFFFllllooooaaaattttvvvv, ggggllllGGGGeeeettttDDDDoooouuuubbbblllleeeevvvv). EEEEXXXXTTTT____bbbblllleeeennnndddd____ssssuuuubbbbttttrrrraaaacccctttt adds two additional blending equations which are set using ggggllllBBBBlllleeeennnnddddEEEEqqqquuuuaaaattttiiiioooonnnnEEEEXXXXTTTT. 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 processing applications. (Also see ggggllllGGGGeeeettttBBBBoooooooolllleeeeaaaannnnvvvv, ggggllllGGGGeeeettttIIIInnnntttteeeeggggeeeerrrrvvvv, ggggllllGGGGeeeettttFFFFllllooooaaaattttvvvv, ggggllllGGGGeeeettttDDDDoooouuuubbbblllleeeevvvv). OOOOPPPPEEEENNNNGGGGLLLL EEEEXXXXTTTTEEEENNNNSSSSIIIIOOOONNNNSSSS oooonnnn RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee,,,, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222,,,, aaaannnndddd VVVVTTTTXXXX RealityEngine, RealityEngine2, and VTX systems support the following extensions in addition to those listed above: SSSSGGGGIIIISSSS____ddddeeeettttaaaaiiiillll____tttteeeexxxxttttuuuurrrreeee 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. (For more information see ggggllllDDDDeeeettttaaaaiiiillllTTTTeeeexxxxFFFFuuuunnnnccccSSSSGGGGIIIISSSS, ggggllllGGGGeeeettttDDDDeeeettttaaaaiiiillllTTTTeeeexxxxFFFFuuuunnnnccccSSSSGGGGIIIISSSS, ggggllllTTTTeeeexxxxIIIImmmmaaaaggggeeee2222DDDD, ggggllllTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrrffff, ggggllllTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrrffffvvvv, ggggllllTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrriiii, ggggllllTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrriiiivvvv, ggggllllTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee2222DDDDEEEEXXXXTTTT, ggggllllGGGGeeeettttTTTTeeeexxxxIIIImmmmaaaaggggeeee, ggggllllGGGGeeeettttTTTTeeeexxxxLLLLeeeevvvveeeellllPPPPaaaarrrraaaammmmeeeetttteeeerrrrffffvvvv, ggggllllGGGGeeeettttTTTTeeeexxxxLLLLeeeevvvveeeellllPPPPaaaarrrraaaammmmeeeetttteeeerrrriiiivvvv, ggggllllGGGGeeeettttTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrrffffvvvv, ggggllllGGGGeeeettttTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrriiiivvvv, ggggllllGGGGeeeettttBBBBoooooooolllleeeeaaaannnnvvvv, ggggllllGGGGeeeettttIIIInnnntttteeeeggggeeeerrrrvvvv, ggggllllGGGGeeeettttFFFFllllooooaaaattttvvvv, ggggllllGGGGeeeettttDDDDoooouuuubbbblllleeeevvvv). PPPPaaaaggggeeee 2222 ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) OOOOppppeeeennnnGGGGLLLL RRRReeeeffffeeeerrrreeeennnncccceeee ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) SSSSGGGGIIIISSSS____mmmmuuuullllttttiiiissssaaaammmmpppplllleeee 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. (For more information see ggggllllSSSSaaaammmmpppplllleeeeMMMMaaaasssskkkkSSSSGGGGIIIISSSS, ggggllllSSSSaaaammmmpppplllleeeePPPPaaaatttttttteeeerrrrnnnnSSSSGGGGIIIISSSS, ggggllllTTTTaaaaggggSSSSaaaammmmpppplllleeeeBBBBuuuuffffffffeeeerrrrSSSSGGGGIIIIXXXX, ggggllllXXXXCCCChhhhoooooooosssseeeeVVVViiiissssuuuuaaaallll, ggggllllXXXXGGGGeeeettttCCCCoooonnnnffffiiiigggg, ggggllllEEEEnnnnaaaabbbblllleeee, ggggllllDDDDiiiissssaaaabbbblllleeee, ggggllllIIIIssssEEEEnnnnaaaabbbblllleeeedddd, ggggllllPPPPuuuusssshhhhAAAAttttttttrrrriiiibbbb, ggggllllGGGGeeeettttBBBBoooooooolllleeeeaaaannnnvvvv, ggggllllGGGGeeeettttDDDDoooouuuubbbblllleeeevvvv, ggggllllGGGGeeeettttIIIInnnntttteeeeggggeeeerrrrvvvv, ggggllllGGGGeeeettttFFFFllllooooaaaattttvvvv.) EEEEXXXXTTTT____ssssuuuubbbbtttteeeexxxxttttuuuurrrreeee 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: ggggllllTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee1111DDDDEEEEXXXXTTTT, ggggllllTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee2222DDDDEEEEXXXXTTTT, ggggllllTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee3333DDDDEEEEXXXXTTTT. Only a subset of this extension is available; refer to the man pages for more details. EEEEXXXXTTTT____tttteeeexxxxttttuuuurrrreeee3333DDDD supports 3-dimensional texture mapping. It also defines the in- memory formats for 3D images, and adds pixel storage modes to support them. (For more information see ggggllllTTTTeeeexxxxIIIImmmmaaaaggggeeee3333DDDDEEEEXXXXTTTT, ggggllllPPPPiiiixxxxeeeellllSSSSttttoooorrrreeee, ggggllllEEEEnnnnaaaabbbblllleeee, ggggllllDDDDiiiissssaaaabbbblllleeee, ggggllllIIIIssssEEEEnnnnaaaabbbblllleeeedddd, ggggllllTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrriiiivvvv, ggggllllTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrrffffvvvv, ggggllllGGGGeeeettttBBBBoooooooolllleeeeaaaannnnvvvv, ggggllllGGGGeeeettttIIIInnnntttteeeeggggeeeerrrrvvvv, ggggllllGGGGeeeettttFFFFllllooooaaaattttvvvv, ggggllllGGGGeeeettttDDDDoooouuuubbbblllleeeevvvvEEEEnnnnaaaabbbblllleeee, ggggllllGGGGeeeettttTTTTeeeexxxxIIIImmmmaaaaggggeeee, ggggllllGGGGeeeettttTTTTeeeexxxxLLLLeeeevvvveeeellllPPPPaaaarrrraaaammmmeeeetttteeeerrrriiiivvvv, ggggllllGGGGeeeettttTTTTeeeexxxxLLLLeeeevvvveeeellllPPPPaaaarrrraaaammmmeeeetttteeeerrrrffffvvvv, ggggllllGGGGeeeettttTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrriiiivvvv, ggggllllGGGGeeeettttTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrrffffvvvv.) SSSSGGGGIIIISSSS____sssshhhhaaaarrrrppppeeeennnn____tttteeeexxxxttttuuuurrrreeee 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. (For more information see ggggllllSSSShhhhaaaarrrrppppeeeennnnTTTTeeeexxxxFFFFuuuunnnnccccSSSSGGGGIIIISSSS, ggggllllGGGGeeeettttSSSShhhhaaaarrrrppppeeeennnnTTTTeeeexxxxFFFFuuuunnnnccccSSSSGGGGIIIISSSS, ggggllllTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrriiii, ggggllllTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrrffff, ggggllllTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrriiiivvvv, ggggllllTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrrffffvvvv, ggggllllGGGGeeeettttTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrriiiivvvv, ggggllllGGGGeeeettttTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrrffffvvvv). EEEEXXXXTTTT____ccccoooonnnnvvvvoooolllluuuuttttiiiioooonnnn adds 1- or 2-dimensional convolution operations to the pixel transfer process. Thus pixel drawing, reading, and copying, as well as texture image definition, are all 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. (For more information see ggggllllCCCCoooonnnnvvvvoooolllluuuuttttiiiioooonnnnFFFFiiiilllltttteeeerrrr1111DDDDEEEEXXXXTTTT, ggggllllCCCCoooonnnnvvvvoooolllluuuuttttiiiioooonnnnFFFFiiiilllltttteeeerrrr2222DDDDEEEEXXXXTTTT, ggggllllCCCCooooppppyyyyCCCCoooonnnnvvvvoooolllluuuuttttiiiioooonnnnFFFFiiiilllltttteeeerrrr1111DDDDEEEEXXXXTTTT, ggggllllCCCCooooppppyyyyCCCCoooonnnnvvvvoooolllluuuuttttiiiioooonnnnFFFFiiiilllltttteeeerrrr2222DDDDEEEEXXXXTTTT, ggggllllGGGGeeeettttCCCCoooonnnnvvvvoooolllluuuuttttiiiioooonnnnFFFFiiiilllltttteeeerrrrEEEEXXXXTTTT, ggggllllSSSSeeeeppppaaaarrrraaaabbbblllleeeeFFFFiiiilllltttteeeerrrr2222DDDDEEEEXXXXTTTT, ggggllllGGGGeeeettttSSSSeeeeppppaaaarrrraaaabbbblllleeeeFFFFiiiilllltttteeeerrrrEEEEXXXXTTTT, ggggllllCCCCoooonnnnvvvvoooolllluuuuttttiiiioooonnnnPPPPaaaarrrraaaammmmeeeetttteeeerrrriiiiEEEEXXXXTTTT, ggggllllCCCCoooonnnnvvvvoooolllluuuuttttiiiioooonnnnPPPPaaaarrrraaaammmmeeeetttteeeerrrriiiivvvvEEEEXXXXTTTT, PPPPaaaaggggeeee 3333 ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) OOOOppppeeeennnnGGGGLLLL RRRReeeeffffeeeerrrreeeennnncccceeee ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) ggggllllCCCCoooonnnnvvvvoooolllluuuuttttiiiioooonnnnPPPPaaaarrrraaaammmmeeeetttteeeerrrrffffEEEEXXXXTTTT, ggggllllCCCCoooonnnnvvvvoooolllluuuuttttiiiioooonnnnPPPPaaaarrrraaaammmmeeeetttteeeerrrrffffvvvvEEEEXXXXTTTT, ggggllllGGGGeeeettttCCCCoooonnnnvvvvoooolllluuuuttttiiiioooonnnnPPPPaaaarrrraaaammmmeeeetttteeeerrrriiiivvvvEEEEXXXXTTTT, ggggllllGGGGeeeettttCCCCoooonnnnvvvvoooolllluuuuttttiiiioooonnnnPPPPaaaarrrraaaammmmeeeetttteeeerrrrffffvvvvEEEEXXXXTTTT, ggggllllEEEEnnnnaaaabbbblllleeee, ggggllllDDDDiiiissssaaaabbbblllleeee, ggggllllIIIIssssEEEEnnnnaaaabbbblllleeeedddd, ggggllllGGGGeeeettttBBBBoooooooolllleeeeaaaannnnvvvv, ggggllllGGGGeeeettttIIIInnnntttteeeeggggeeeerrrrvvvv, ggggllllGGGGeeeettttFFFFllllooooaaaattttvvvv, ggggllllGGGGeeeettttDDDDoooouuuubbbblllleeeevvvv, ggggllllPPPPiiiixxxxeeeellllTTTTrrrraaaannnnssssffffeeeerrrriiii, ggggllllPPPPiiiixxxxeeeellllTTTTrrrraaaannnnssssffffeeeerrrrffff). Only a subset of this extension is available; refer to the man pages for details. EEEEXXXXTTTT____hhhhiiiissssttttooooggggrrrraaaammmm 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. (For more information see ggggllllHHHHiiiissssttttooooggggrrrraaaammmmEEEEXXXXTTTT, ggggllllRRRReeeesssseeeettttHHHHiiiissssttttooooggggrrrraaaammmmEEEEXXXXTTTT, ggggllllGGGGeeeettttHHHHiiiissssttttooooggggrrrraaaammmmEEEEXXXXTTTT, ggggllllGGGGeeeettttHHHHiiiissssttttooooggggrrrraaaammmmPPPPaaaarrrraaaammmmeeeetttteeeerrrriiiivvvvEEEEXXXXTTTT, ggggllllGGGGeeeettttHHHHiiiissssttttooooggggrrrraaaammmmPPPPaaaarrrraaaammmmeeeetttteeeerrrrffffvvvvEEEEXXXXTTTT, ggggllllMMMMiiiinnnnmmmmaaaaxxxxEEEEXXXXTTTT, ggggllllRRRReeeesssseeeettttMMMMiiiinnnnmmmmaaaaxxxxEEEEXXXXTTTT, ggggllllGGGGeeeettttMMMMiiiinnnnmmmmaaaaxxxxEEEEXXXXTTTT, ggggllllGGGGeeeettttMMMMiiiinnnnmmmmaaaaxxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrriiiivvvvEEEEXXXXTTTT, ggggllllGGGGeeeettttMMMMiiiinnnnmmmmaaaaxxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrrffffvvvvEEEEXXXXTTTT, ggggllllEEEEnnnnaaaabbbblllleeee, ggggllllDDDDiiiissssaaaabbbblllleeee, ggggllllIIIIssssEEEEnnnnaaaabbbblllleeeedddd, ggggllllGGGGeeeettttBBBBoooooooolllleeeeaaaannnnvvvv, ggggllllGGGGeeeettttIIIInnnntttteeeeggggeeeerrrrvvvv, ggggllllGGGGeeeettttFFFFllllooooaaaattttvvvv, ggggllllGGGGeeeettttDDDDoooouuuubbbblllleeeevvvv) SSSSGGGGIIII____ccccoooolllloooorrrr____mmmmaaaattttrrrriiiixxxx 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. (For more information, see ggggllllGGGGeeeettttBBBBoooooooolllleeeeaaaannnnvvvv, ggggllllGGGGeeeettttIIIInnnntttteeeeggggeeeerrrrvvvv, ggggllllGGGGeeeettttFFFFllllooooaaaattttvvvv, ggggllllGGGGeeeettttDDDDoooouuuubbbblllleeeevvvv, ggggllllPPPPiiiixxxxeeeellllTTTTrrrraaaannnnssssffffeeeerrrr) SSSSGGGGIIII____tttteeeexxxxttttuuuurrrreeee____ccccoooolllloooorrrr____ttttaaaabbbblllleeee adds a color lookup table to the texture mapping process. (For more information, see ggggllllTTTTeeeexxxxCCCCoooolllloooorrrrTTTTaaaabbbblllleeeePPPPaaaarrrraaaammmmeeeetttteeeerrrrSSSSGGGGIIII) SSSSGGGGIIII____ccccoooolllloooorrrr____ttttaaaabbbblllleeee 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 GGGGLLLL____AAAALLLLPPPPHHHHAAAA modifies only the A component of each passing pixel, leaving the R, G, and B components untouched.) At present, only the functionality needed to support SSSSGGGGIIII____tttteeeexxxxttttuuuurrrreeee____ccccoooolllloooorrrr____ttttaaaabbbblllleeee has been implemented, so this extension is not listed in the extensions string returned by ggggllllGGGGeeeettttSSSSttttrrrriiiinnnngggg. (For more information, see ggggllllCCCCoooolllloooorrrrTTTTaaaabbbblllleeeeSSSSGGGGIIII, ggggllllCCCCoooolllloooorrrrTTTTaaaabbbblllleeeePPPPaaaarrrraaaammmmeeeetttteeeerrrrSSSSGGGGIIII, and ggggllllGGGGeeeettttCCCCoooolllloooorrrrTTTTaaaabbbblllleeeePPPPaaaarrrraaaammmmeeeetttteeeerrrrSSSSGGGGIIII) PPPPaaaaggggeeee 4444 ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) OOOOppppeeeennnnGGGGLLLL RRRReeeeffffeeeerrrreeeennnncccceeee ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) EEEEXXXXTTTT____tttteeeexxxxttttuuuurrrreeee____oooobbbbjjjjeeeecccctttt 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, EEEEXXXXTTTT____tttteeeexxxxttttuuuurrrreeee____oooobbbbjjjjeeeecccctttt also provides simple texture memory management. (For more information, see ggggllllGGGGeeeennnnTTTTeeeexxxxttttuuuurrrreeeessssEEEEXXXXTTTT, ggggllllDDDDeeeelllleeeetttteeeeTTTTeeeexxxxttttuuuurrrreeeessssEEEEXXXXTTTT, ggggllllBBBBiiiinnnnddddTTTTeeeexxxxttttuuuurrrreeeeEEEEXXXXTTTT, ggggllllPPPPrrrriiiioooorrrriiiittttiiiizzzzeeeeTTTTeeeexxxxttttuuuurrrreeeessssEEEEXXXXTTTT, ggggllllAAAArrrreeeeTTTTeeeexxxxttttuuuurrrreeeessssRRRReeeessssiiiiddddeeeennnnttttEEEEXXXXTTTT, and ggggllllIIIIssssTTTTeeeexxxxttttuuuurrrreeeeEEEEXXXXTTTT) EEEEXXXXTTTT____ccccooooppppyyyy____tttteeeexxxxttttuuuurrrreeee 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, so the extension name is not listed in the extensions string returned by ggggllllGGGGeeeettttSSSSttttrrrriiiinnnngggg. (For more information, see ggggllllCCCCooooppppyyyyTTTTeeeexxxxIIIImmmmaaaaggggeeee2222DDDDEEEEXXXXTTTT and ggggllllCCCCooooppppyyyyTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee2222DDDDEEEEXXXXTTTT) SSSSGGGGIIIIXXXX____iiiinnnntttteeeerrrrllllaaaacccceeee modifies the behavior of ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss, ggggllllCCCCooooppppyyyyPPPPiiiixxxxeeeellllssss, ggggllllTTTTeeeexxxxIIIImmmmaaaaggggeeee2222DDDD, ggggllllTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee2222DDDDEEEEXXXXTTTT, ggggllllCCCCooooppppyyyyTTTTeeeexxxxIIIImmmmaaaaggggeeee2222DDDDEEEEXXXXTTTT and ggggllllCCCCooooppppyyyyTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee2222DDDDEEEEXXXXTTTT, such that when GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX is enabled the source image is considered to be a field of an "interlaced" frame. That is, the effective source image has height equal to twice the actual height and every other row contains "transparent" pixels that do not affect the corresponding destination pixels in the target image. For example: ggggllllEEEEnnnnaaaabbbblllleeee(GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX); _s_e_t _c_u_r_r_e_n_t _r_a_s_t_e_r _p_o_s_i_t_i_o_n _t_o (_x_r,_y_r) ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss(_w_i_d_t_h, _h_e_i_g_h_t, GGGGLLLL____RRRRGGGGBBBBAAAA, GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____BBBBYYYYTTTTEEEE, _I0); _s_e_t _r_a_s_t_e_r _p_o_s_i_t_i_o_n _t_o (_x_r,_y_r+_z_o_o_m_y) ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss(_w_i_d_t_h, _h_e_i_g_h_t, GGGGLLLL____RRRRGGGGBBBBAAAA, GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____BBBBYYYYTTTTEEEE, _I1); is equivalent to ggggllllDDDDiiiissssaaaabbbblllleeee( GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX); _s_e_t _c_u_r_r_e_n_t _r_a_s_t_e_r _p_o_s_i_t_i_o_n _t_o (_x_r,_y_r) ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss(_w_i_d_t_h, 2x_h_e_i_g_h_t, GGGGLLLL____RRRRGGGGBBBBAAAA, GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____BBBBYYYYTTTTEEEE, _I2); where pixel rows (0,2,4,...) of _I2 are from image _I0, and rows (1,3,5,...) are from image _I1. This is particularly useful for assembling consecutive interlaced video format fields to into a complete frame in either the frame- buffer or in texture memory. PPPPaaaaggggeeee 5555 ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) OOOOppppeeeennnnGGGGLLLL RRRReeeeffffeeeerrrreeeennnncccceeee ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) UUUUSSSSIIIINNNNGGGG EEEEXXXXTTTTEEEENNNNSSSSIIIIOOOONNNNSSSS Procedure names and tokens for OpenGL extensions are suffixed with EXT or with a vendor-specfic acronym. EXT is used for extensions that have been reviewed and will be supported by more than one OpenGL vendor. SGI also supports some vendor-specific extensions. Procedure names and tokens for the SGI-specific extensions are suffixed with SGI, SGIS or SGIX. ``SGI'' is used for extensions that will be available across the product line (although the support for all machines might not be released simultaneously). ``SGIS'' is used for extensions that will be available on a subset of SGI platforms. ``SGIX'' extensions are experimental; in future releases, the API for these extensions might change or might not be supported at all. All supported extensions will have an associated macro definition in gl.h and a corresponding token in the extensions string returned by ggggllllGGGGeeeetttt---- SSSSttttrrrriiiinnnngggg. For example, if the EEEEXXXXTTTT____aaaabbbbggggrrrr extension is supported then the token GGGGLLLL____EEEEXXXXTTTT____aaaabbbbggggrrrr will be defined in gl.h and GGGGLLLL____EEEEXXXXTTTT____aaaabbbbggggrrrr will appear in the extensions string returned by ggggllllGGGGeeeettttSSSSttttrrrriiiinnnngggg. The definitions in gl.h can be used at compile time to determine if an extension's tokens and procedures exist in the OpenGL library. However, the tokens returned by ggggllllGGGGeeeettttSSSSttttrrrriiiinnnngggg must be consulted at runtime to deter- mine whether the extension is supported on the particular display in use at that moment. Some of the RealityEngine extensions are incomplete and therefore are not advertised in the extensions string. As an alternative to parsing the extensions string, you can determine which extensions are supported by examining the renderer string (to determine which graphics subsystem is being used) and the version string (to determine the release number of the software being used). For more information see ggggllllGGGGeeeettttSSSSttttrrrriiiinnnngggg. GLX also has been extended. Refer to ggggllllXXXXIIIInnnnttttrrrroooo for more information. NNNNOOOOTTTTEEEESSSS When an OpenGL application uses indirect rendering, additional instances of Xsgi, the SGI X server, process show up under ps. The additional processes are multiple threads of the X server, used to implement indirect rendering. BBBBUUUUGGGGSSSS Different OpenGL processes which render to the same window using direct rendering will not share the software ancillary buffers on that window. X and OpenGL do not coordinate swapping on double-buffered windows prop- erly. PPPPaaaaggggeeee 6666 ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) OOOOppppeeeennnnGGGGLLLL RRRReeeeffffeeeerrrreeeennnncccceeee ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) 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 sup- ported. If an application requires more than one rendering thread then it must create a separate context for each thread. 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. ggggllllXXXXCCCCooooppppyyyyCCCCoooonnnntttteeeexxxxtttt does not work correctly if the source context is not the current context or if the destination context has never been made current. 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. You may notice some discrepancies between the OpenGL Reference Manual which is available through InSight and the man pages (i.e., the ones you get using the "man gl..." command in a shell window). If so, the man pages contain the correct, up to date, information. MMMMAAAACCCCHHHHIIIINNNNEEEE DDDDEEEEPPPPEEEENNNNDDDDEEEENNNNCCCCIIIIEEEESSSS RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee,,,, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222,,,, aaaannnndddd VVVVTTTTXXXX Textures loaded using ggggllllPPPPiiiixxxxeeeellllMMMMaaaapppp might be corrupted when enough textures are loaded to cause kernel management of texture memory. Corruption should occur only if the ggggllllPPPPiiiixxxxeeeellllMMMMaaaapppp has changed or been disabled since the original load. Line stippling for antialiased lines is not quite correct. Antialiasing has no effect in multisampled visuals. When multisampling is off, all primitives will be aliased. VVVVGGGGXXXX aaaannnndddd VVVVGGGGXXXXTTTT On VGX and VGXT systems, OpenGL is implemented atop IrisGL. This imple- mentation passes the mustpass OpenGL conformance tests but, nonetheless, the following inconsistencies exist: fragments centers lie on integer coordinates (not half-integer coordinates), and diffuse and specular light colors are ignored. PPPPaaaaggggeeee 7777 ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) OOOOppppeeeennnnGGGGLLLL RRRReeeeffffeeeerrrreeeennnncccceeee ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) If any of the following is enabled, then all geometric primitives will be rendered through software (i.e., no hardware acceleration will be used): o alpha test (unless test is GL_ALWAYS or GL_NOTEQUAL and reference value is '0') o texture o lighting enabled but no lights enabled o clock-wise front face o fog enabled and color index visual o we have to draw into both front and back buffer AND blend is enabled, or logic op is enabled Points will be rendered through software if evaluators are used (e.g., GGGGLLLL____MMMMAAAAPPPP1111____VVVVEEEERRRRTTTTEEEEXXXX3333 is enabled). Polygons, meshes and strips will be rendered through software if any of the following is true: o front mode is not the same as back mode and front mode is not GGGGLLLL____FFFFIIIILLLLLLLL o polygon offset is enabled and the scale and bias offset factors are not 1 and 0, respectively. o points have to go through software and front mode is GGGGLLLL____PPPPOOOOIIIINNNNTTTT On VGXT fog is done per-vertex instead of per-pixel. PPPPeeeerrrrssssoooonnnnaaaallll IIIIrrrriiiissss On Personal Iris systems, OpenGL is implemented atop IrisGL. This imple- mentation passes the mustpass OpenGL conformance tests but, nonetheless, the following incompatibilities exist: fragments centers lie on integer coordinates (not half-integer coordinates), and diffuse and specular light colors are ignored. If any of the following is enabled, then all geometric primitives will be rendered through software (i.e., no hardware acceleration will be used): o alpha test o texture o stencil o model clip o two-sided lighting, if lighting is enabled o clock-wise front face o fog (unless the fog mode is GGGGLLLL____LLLLIIIINNNNEEEEAAAARRRR) o blend If any of the following is enabled, points will be rendered through software: o anti-aliasing and the point smooth hint is set to GGGGLLLL____NNNNIIIICCCCEEEESSSSTTTT o point size is greater than 1.5 o evaluation (e.g., GGGGLLLL____MMMMAAAAPPPP1111____VVVVEEEERRRRTTTTEEEEXXXX3333 is enabled) PPPPaaaaggggeeee 8888 ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) OOOOppppeeeennnnGGGGLLLL RRRReeeeffffeeeerrrreeeennnncccceeee ggggllllIIIInnnnttttrrrroooo((((3333GGGG)))) If any of the following is enabled, lines are done in software: o anti-aliasing and the width is not equal to 1.0 o anti-aliasing and the line smooth hint is set to GGGGLLLL____NNNNIIIICCCCEEEESSSSTTTT If any of the following is true, polygons, meshes and strips are done in software: o anti-aliasing is enabled o front mode is not the same as back mode (two-sidedness is not supported in hardware) o polygon offset is enabled and the scale and bias offset factors are not 1 and 0, respectively. o points have to go through software and front mode is GGGGLLLL____PPPPOOOOIIIINNNNTTTT o lines have to go through software and front mode is GGGGLLLL____LLLLIIIINNNNEEEE SSSSEEEEEEEE AAAALLLLSSSSOOOO ggggllllXXXXIIIInnnnttttrrrroooo PPPPaaaaggggeeee 9999 
