Remi Arnaud (remi++at++remi.asd.sgi.com)
Thu, 16 May 1996 10:44:48 -0700
OK,
> However, when I try to preload textures
> I can only preload 4 Meg until internal texture management paging takes over
> and starts removing early textures. I am using TX_FASTDEFINE when defining
> the textures and am "prebinding" to avoid start up delays/ pay attention to
> texture bank ordering / etc. I have reduced the problem to this:
> I define then pre-bind the textures one after another (all same size 64x64
> shorts). After each def/bind I check to see if the first one is still loaded
> (it is the "oldest" one so it seems it would be "paged" out first) with
> "istexloaded" (for debug). After I reach the 4 Meg boundary, the first
> one returns that it is not loaded. There are no other textures loaded,
> there is no mip-mapping, etc. I have tried this on two identical machines
> and have gotten the same results. I only thought something was wrong
> because the program would "hang" while it shuffled the texture memory.
> It seems that 16 Meg of texture memory could handle this ( only need about
> 8 Meg for the application). Since it uses a TX_FASTDEFINE token I have
> tried binding both a NULL texture and a real texture. I don't even
> get to the subtexload at all before the RMs start swapping out texture
> space.
>
When you say X Meg, do you say MBytes, or MTexels ?
- A RM5 has 16 MBytes memory == 8 MTexels 16 bits == 4 MTexels 32 bits
Do you include MipMaps in your texture size ?
ex: a 1024x1024 texture, 16 bit coded, with mip-maping takes:
4/3 * 1 * 2 = 2.66.... MBytes
^ ^ ^
| | |_______> 1 texel = 2 bytes
| |
| |___________> 1024x1024 texture is 1 Mtexels
|
|----------------> mip map cost (= 1 + 1/2 + 1/4 + 1/8 + .....)
Best Regards
Remi
--
o o Remi ARNAUD - Silicon Graphics, Advanced Systems Dev o o o o Mail Stop 590 - 2011 N. Shoreline Boulevard o o o o Mountain View, California 94043-1389, USA o o o o Tel: (415) 933 6208 Fax: (415) 965 2658 o o
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:53 PDT