[Future Technology Research Index] [SGI Tech/Advice Index] [Nintendo64 Tech Info Index]


[WhatsNew] [P.I.] [Indigo] [Indy] [O2] [Indigo2] [Crimson] [Challenge] [Onyx] [Octane] [Origin] [Onyx2]

Ian's SGI Depot: FOR SALE! SGI Systems, Parts, Spares and Upgrades

(check my current auctions!)

IMPACT Graphics, Video and OS Information

My thanks to Rob Jenkins at SGI who sent me this information after I posted the O2/Indigo2 comparison info to comp.sys.sgi.hardware.

Rob says...

The main thing to know for texturing is that IMPACT machines with 1MB of TRAM (texture memory) only support up to 16bit textures. If an OpenGL (or Iris GL) application uses 4 channel (RGBA) textures then the maximum resolution is 4bits per colour component. This can mean that on textures with subtle colour gradients some banding may be apparent. To check the hardware on the machine do:

   /usr/gfx/gfxinfo

If customers require 32 bit texture in their applications, they'd need a 4 meg texture memory system, or they would have to use the above texture formats that are supported by the 1 TRAM system.

In summary, the following are the supported texture formats on different TRAM configurations.

   BITS/COMPONENT  4   4   4   4   8   8   8   8   12   12   12   12
   COMPONENTS      1   2   3   4   1   2   3   4    1    2    3    4

   1 TRAM          Y   Y   Y   Y   Y   Y   N   N    N    N    N    N
   4 TRAM          Y   Y   Y   Y   Y   Y   Y   Y    Y    Y    Y    Y

I have a collection of IMPACT texture info collected from various people so I'll paste that below:

  1. The largest texture you can load with one TRAM is 512x512... if a polygon is supposed to be textured but shows up white, this is a good candidate for your problem.

  2. Textures must be a power of 2 on each edge... i.e. 8x8, 16x16, 32x32, etc.

    More specifically, the texture size is bounded by the TRAM size. We have 1M TRAMs, so the largest texture size is 1M. The amount of texture data is dependent on the number of TRAMs in the system. There can be either 1 or 4 TRAMs. With one TRAM, all channels of a texture are multiplexed into the same TRAM. With 4 TRAMs, each channel is split out into the individual TRAMs.

    So, if you have 2D Luminance textures, you can create 1K x 1K textures on a 1 or 4 TRAM system. But if you have RGBA textures, on a 1 TRAM system, you can only create a 512 x 512 texture. A 1K x 1K RGBA texture will work on a 4 TRAM system, each 1M R, G, B, and A channel will fill the full 1M of each of the 4 TRAMs.

    Same goes for 1D or 3D textures. The largest 3D texture size is still 1M, a possible size is 128 * 128 * 64. Depending on the number of channels: Luminance, Luminance-Alpha, RGB, or RGBA, and the number of TRAMs in the system, the texture size may have to be reduced.

    There is an environment variable to control use of HW or SW texturing on a 1MB TRAM IMPACT:

       setenv USE_SOFT_TEXTURE 1
    

    This will disable hardware texturing - only on 1 TRAM machines though. Obviously just use unsetenv or set it back to 0 to re-enable. This isn't global, in other words if you set this in a shell it only effects programs run in that shell afterwards -if you run the same code in another shell ( without the variable set) it'll use hardware texturing. Also if you use OpenInventor you can also use the textureQuality field in a SoComplexity node set to 1.0 to achieve this, which is useful if you are suffering from banded textures and can take the obvious performance hit of using software texturing.


    IMPACT Video:

    There are two video boards available for IMPACT machines:

    There is also a Color Space/Video Texture Daughter Card and a compression card (Cosmo 2.0) for IMPACT video.


    A couple of IMPACT 'Gotchas':

    When using/testing Indigo2 IMPACTs make sure the latest gfx patches are installed, at the moment Irix 6.2 should have patch 1447, Irix 5.3 pacth 1333. There are other recommended patches for IMPACT but these gfx ones are essential.

    On pre-Irix5.x operating systems software was compiled into COFF format executables, after Irix 5.x executables are ELF format. Any COFF executables calling Iris GL will run very slowly on IMPACTs as the Iris GL calls go via the Distributed GL (DGL) daemon which is like running remotely. So, if you have problems where certian graphics applications run very slowly check the executable format by doing:

       file <executable name>
    

    if it's COFF then that's why it's slow, get a newer version (that's been compiled on Irix 5.x). NOTE: COFF will not be supported at all from Irix 6.2 onwards so I think (not sure) but O2 won't support COFF executables, even if it does I'm sure it would be better to move to ELF.


    Ian's SGI Depot: FOR SALE! SGI Systems, Parts, Spares and Upgrades

    (check my current auctions!)
    [WhatsNew] [P.I.] [Indigo] [Indy] [O2] [Indigo2] [Crimson] [Challenge] [Onyx] [Octane] [Origin] [Onyx2]
    [Future Technology Research Index] [SGI Tech/Advice Index] [Nintendo64 Tech Info Index]