Jim Helman (jimh++at++surreal)
Mon, 27 Jun 94 19:19:34 -0700
Keep in mind that there can be up to three copies of a texture:
1) The image array that you handed Performer with
pfTexImage() or the array allocated within pfLoadTexFile().
Unless you plan on changing texture attributes after the
texture has been defined, you don't need this image at run
time. To free the storage call pfFreeTexImage() after the
texture has been used the first time (so you're sure it has
been GL texdef'd.) This is in external format, typically 8
bits per component.
2) The image array inside GL on the host that GL uses to page
down to the graphics pipe when needed. This is in internal
format, 16bits per texel by default (e.g. RGB_5), and is
necessary.
3) The copy (sometimes) down in the graphics hardware.
If pfuDownLoadTexList() was reporting 250MB of texture loaded, that
means there should be 250MB inside GL. Unless you have called
pfuFreeTexImage, Performer has another 250MB to 500MB (depending on
whether the internal and external formats have the same number of
bytes per texel).
250MB is a LOT of texture. If you plan to do real-time paging of
these textures through the 4-16MB of RM memory, you may run into
some performance problems when GL deals with a large number of
textures ids. If the textures are not mipmapped, you might look at
using subtexload or tx_nocopy to reuse Performer (and hence GL)
texture IDs. If the textures are mipmapped, you might look at
combining several small textures that are used together onto larger
single textures to reduce the number of GL texture IDs to a few
hundred.
rgds,
-jim helman
jimh++at++surreal.asd.sgi.com
415/390-1151
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:22 PDT