Steve Baker (sbaker++at++link.com)
Wed, 29 Jul 1998 11:02:06 -0500 (CDT)
> I have an application that renders a cube of data with textures - rather
> simple. The textures are somewhat large in this case four of the faces
> are 1k*2k and the other two are 2k*2k. They are luminance in byte
> format. The amount of texture memory needed to hold these textures is
> then (4*1k*2k + 2*2k*2k)*4 [the final 4 is because they are stored at
> 32bit textures]. This is then 8k*2k*4 or 64k of memory or 100% of the
> texture memory on my Onyx2. If I change the geometry by cutting a corner
> out of the cube, I add three more textures. This doesn't have any effect
> on the performance. I can cut another corner out and still have no
> effect. So now I am using 200% of texture memory and haven't had any
> effect on performance. Now if I cut another corner out I have a total of
> 15 textures using a total of 64k+64k+32k of tram. Now the performance
> drops from 36 fps to 1 fps. The gfx stats now indicates that I'm
> downloading 7 textures at some rate of 83000. Performance stinks.
If it's a luminance-only texture then it's probably being stored as a byte
per texel and not the 32 bits you seem to think.
You said (confusingly):
> They are luminance in byte format
...and then you said:
> the final 4 is because they are stored at 32bit textures
So, if we assume that the final x4 in your math is wrong, it would lead you
to think that you could have 4x as much texture as you thought. However,
it looks like you are running out before that point - and that may be
due to MIPmapping - which (if enabled) consumes an extra 33% of texture
memory over the basic texture maps.
Steve Baker (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-4028 (Fax)
Work: SBaker++at++link.com http://www.hti.com
Home: SJBaker1++at++airmail.net http://web2.airmail.net/sjbaker1
=======================================================================
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:45 PDT