Rob Jenkins (robj++at++quid)
Wed, 1 Oct 1997 17:27:08 -0700
I got some very useful information from Paul Hansen (the author of the Impact
texture manager), it's interspersed with info I had previously so not in the
greatest format. I've avoided editing too much though so I don't lose anything:
----------------------------------
Impacts and OCTANEs with hardware texturing (not "Solids") have the
texture memory configured (for high-speed access reasons) into 256 pages.
1-TRAM systems also have 256 pages, but the pages are not as "wide".
Generally, a page cannot be shared by two texture (level)s, but the
exception to this is:
1. for mipmapped textures, the 5 smallest (tiny) levels get packed onto
one page.
2. for 4-TRAM systems (=> "wide" pages), luminance or luminance/alpha
texture objects can share the page by residing in different TRAMs.
The matter is further complicated by the fact that mipmapped texture
levels 32 texels wide or bigger will require at least one extra page
of memory, for "system borders", again for high-speed access reasons.
How and why this page(s) is used is probably not necessary to describe
here, but I will later if you inquire.
To help people I coded the "tpage calculator" which resides on the
Developer Toolbox which you can download and play around with. It
will show you quickly which textures fit and how many pages they use.
http://dtdustbin.engr/toolbox/src/tutorials/OGLT
( not sure if will work outside the firewall, use the Dev Toolbox address you
normally use )
This is a training course with frames, so click on the left in "Texture
Transfer" and then you'll see it.
> General Impact tips I would post:
> 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.
>
The "max texture size" issue is complicated (as you can see in the tpage
calculator). Sometimes textures which barely fit can have more of them
simultaneously resident! (4 luminance texture objects, 1Kx1Kx8bit, nmm, in a
4-TRAM system).
Actually, with 1 TRAM you could have a 2Kx1Kx4bit nmm luminance texture!
So the 512 number you get is simply the largest square texture of any
type guaranteed to fit on any system. To find the real maximum, use the
tpage calculator or proxy texture queries. The absolute upper limit for
a texture dimension size is 8K, so you could have a texture that is 8Kx64.
I used to have 8K as the MAX_TEXTURE_SIZE, but people were trying to
define 8Kx8K!
> 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.
>
The information above is basically correct. Texture sizes could
be power-of-two plus two for textures with border data.
/usr/share/Performer/src/lib/libpfutil/tex.c.IMPACT is that still optimal as it
uses Guy Russell's scheme for Performer's defining textures in a special order,
with special format, with special page-related stats on usage. All of this
is still current, although with the next all platform release, defining
textures in a special order will not make a difference in how well they
get packed into the RAM's.
------------------------------------------
Cheers
Rob
--
________________________________________________________________
Rob Jenkins mailto:robj++at++sgi.com
Silicon Graphics, Mtn View, California, USA
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:56:03 PDT