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:
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.
There are two video boards available for IMPACT machines:
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.