Don Hatch (hatch++at++hell.engr.sgi.com)
Fri, 17 Jul 1998 12:18:40 -0700
Wait, the levels smaller than the clip size
only take up a full clip size of texture memory
if the clip texture is "virtual" (i.e. if it's bigger than 32Kx32K,
or if you explicitly set its numEffectiveLevels smaller than
its number of levels before using it).
So, assuming your clip textures are not virtual, each one has only
3*(512*512) (the 512x512, 1Kx1K and 2Kx2K levels)
+ (512*512)/3 (the smaller pyramid levels)
= 5/6 Mtexels per texture.
My guess is you're using an internal texel format
that takes 4 bytes per texel, so this
is 4 * 5/6 = 3.33 MB of texture memory per texture
(a little more than Angus's estimate).
Is 4 bytes per texel what you intended?
Other possibly relevant issues:
- due to texture banking considerations,
you may not be able to use all of texture memory
(maybe a clip size or so less)
- as Angus suggested, other textures in the scene (or
even in other programs you may be running) add to the total
texture memory usage.
- set the environment variable GLKONA_TEXTURE_USAGE
to make OpenGL print out how much texture memory is being used.
- your symptom (dropping from 30Hz to 2Hz) is definitely
indicative of overcommitting texture memory.
The garbage is not surprising either (I don't
think the OpenGL implementation is robust about
swapping clip textures).
I'm including a document from Tom McReynolds
that gives more detail on the banking issues.
I don't know whether this has been sent to this list before.
I'm surprised it's not in the 2.2 docs directory; I think
we meant to put it there.
Don
==========================================================================
Clipmap Memory (System and Texture) Usage Estimation
System Memory Estimation
Given:
Size of clipmap level 0
Clipsize (in texels)
Tilesize (in texels; assuming tile size is the same for all levels)
Texel size in bytes
Whether the tiles have high disk latency
1. round up clipsize to even multiple of tile size in each dimension
2. divide each dimension by tilesize in that dimension
3. add 2 tiles to each dimension for a tile boundary of 1.
3a. if there is high latency downloading, such as reading tiles
over the network, or decompressing tiles, add 4 tiles per
dimension, giving a tile boundary of 2.
You now have the number of tiles in each dimension per clipped level*
4. multipy each tile number in each dimension by the corresponding
tilesize in that dimension.
You now have the number of texels in each dimension
5. Multiply the texel dimensions together
6. Scale by the size of each texel
7. (extra credit) add in the fixed cost of imagecache structs, etc.
You now have the system memory cost in bytes for each clipped level
8. Treat each level bigger than clipsize as clipped(**).
Add 4/3rds the clipsize scaled by the texel size for the pyramid
levels.
9. Scale the clipped level size by the number of clipped levels
**This estimate is a bit too conservative, since the lowest clipped levels
may exceed the entire level size with a border of 2 tiles. It is a function
of tilesize and clipsize.
Example: 2M top level, 1K clipsize, 512 Tile Size (everything square)
1 byte texel size (LMV example)
1. no-op: 1K, 1K (for both s and t)
2. 1K/512 = 2, 2 (for both s and t)
3. 2+4 = 6, 6 (for both s and t; high latency on tile download)
4. 6 * 512 = 3K, 3K (for both s and t)
5. 3K * 3K = 9M
6. 9M * 1 = 9M
7. We haven't figured out this constant yet, and we haven't proved it's
a constant.
8. 9M * 10 = 90M (for 2M -> 4K levels) + 2M (for 2K level) = 92M
9. 4/3 * 1K * 1K= 1.3M
10. Total Size 92M + 1.3M = 93.3M
Texture Memory Usage
Given:
Clipsize (in texels)
Whether clipmap is virtual or non-virtual
Number of levels in use (if less than 16)
1a. if virtual, multiply number of levels by square of clipsize
1b. if non-virtual, multiply number of levels bigger than clipsize
by square clipsize. Add in 4/3 times clipsize squared (to
account for the pyramid.
Texture Memory Usage: A further complication
Infinite reality rendering boards come with either 16 or 64
megabytes of texture memory. Unfortunately, you can't just
use the texture memory any way you want. The texture memory
is divided into two equal banks. Each adjacent mipmap level
clipmapped or not, must be placed in opposite banks. This
ends up restricting the amount of texture memory available
for clipmapping.
A further restriction is that texture formats can take up
16 bits or 32 bits of data per texel, but nothing in-between.
This means an 888 RGB format will take up 32 bits per texel,
just like an 8888 RGBA format.
To give you an example of this restriction. Say you want
to use RGB texel data, 8 bits per component, with a clipsize
of 2048 by 2048. The largest level is 8K by 8K.
You have an RM board with 64M of texture memory, so you
think you have plenty of room:
You're non-virtual, so the total size is clipsize times the
number of clipped levels plus 4/3 of the pyramid:
8K, 4K levels are clipped to 2K X 2K:
RGB, 8 bits per channel 4 bytes (not 3!) per texel
times 2K X 2K = 4M of texels per level;
16M of texture memory per clipped level
So that's 32M of texture memory
2K and below is the pyramid, so 4/3 of 16M = 21-1/3M
Total is 53-1/3M of texture memory.
Sorry. it won't work:
* 64M of texture memory means 2 32M banks.
* Each level must be in the opposite 32M bank
So: 8K level -> 16M in bank 0 (16M left)
4K level -> 16M in bank 1 (16M left)
2K level -> 16M in bank 0 (0M left)
1K level -> 8M in bank 1 (8M left)
152 level -> no room in bank 0!!!
The best you could do is to have only 1 clipped level:
4K level -> 16M in bank 0 (16M left)
2K level -> 16M in bank 1 (16M left)
1K level -> 8M in bank 0 (8M left)
512 level -> 4M in bank 1 (12M left)
256 level -> 2M in bank 0 (6M left)
and so on.
Probably a better solution would be to use 5551 format
RGBA texels, which only use 16 bits per texel, allowing
you to use more levels:
32K level -> 8M in bank 0 (24M left)
16K level -> 8M in bank 1 (24M left)
8K level -> 8M in bank 0 (16M left)
4K level -> 8M in bank 1 (16M left)
2K level -> 8M in bank 0 (8M left)
1K level -> 4M in bank 1 (12M left)
512 level -> 2M in bank 0 (6M left)
256 level -> 1M in bank 1 (11M left)
and so on.
You can see that you get a lot more mileage out of smaller texel
formats than less levels. This becomes even more true for
RMs with only 16M of texture memory.
--
Don Hatch hatch++at++sgi.com (650) 933-5150 Silicon Graphics, Inc.
=======================================================================
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:57:42 PDT