Re: Texture performance

New Message Reply Date view Thread view Subject view Author view

David Marsland (mars++at++clubted.csd.sgi.com)
Thu, 14 Apr 94 10:52:29 -0700

Just a guess, but it sounds like you're overflowing the texture memory and swapping to main memory when you load the second sign
texture. Have you tried using a lower resolution texture? On
a VGXT 128x128 is a good texture size. Here's an old table,
posssibly outdated, of texture memory size:

Also, using a non-mipmapped minification filter may help
load bigger textures.

> 1) Does the execution time of texdef2d vary with the size of the
> image array passed to it?

   Yes. the GL makes a copy of the texture in the format the hardware actually
   uses. That copy is also used for re-loading texture memory if necessary
   during context switching (VGX,VGX/T). The bigger the texture, the longer
   it takes to process it.

   Here is a table that indicates how many textures of what size can
   fit in VGX, VGX/T.
-------

        Here is a summary of the texture memory on 5 and 10 span VGX and VGXT
with some notes on how the texture memory is managed differently on
VGX and VGXT. Some I conclusions reached are:

        - VGXT uses texture memory much more efficiently

        - since textures sizes are rounded up to the next multiple of 32,
          fewer textures can fit than is possible. e.g. a 5-span VGXT can
          really store 3 128 x 128 MIPMAP textures instead of 2 and there
          probably are other shoehorn cases for the real-life 10-span VGXT.
          airey says we can fix the 32-texel chunksize but the hassle factor
          and performance issues are not yet clear.
         

- 5 span has 64K texels texel == 32 bits
- 10 span has 64K + 32K + 64K(acbuf) texels
- VGX textures cannot span bank boundaries
- VGXT textures can span bank boundaries
- VGX textures need borders for wrapping so size is (size+2)*(size+2)
- 1-component takes same amount of space as 4-component
- MIPMAP size is floor(size * 4/3)
- all textures not multiples of 32 are rounded up to next multiple of 32
  since gl sends textures down in 32 texel chunks

VGX: Spans(texels) Spans(texels)
texture size not MIPMAP 5(64) 10(160) MIPMAP 5(64) 10(160)
-------------------------------------------------------------------------------
16 x 16 352 186 465 512 128 320
32 x 32 1184 = 1.16K 55 137 1664 = 1.62K 39 97
64 x 64 4384 = 4.28K 14 35 6016 = 5.88K 10 25
128 x 128 16928 = 16.53K 3 7 22912 = 22.38K 2 5
256 x 256 66592 = 65.03K 1* 2* 89472 = 87.38K 0 0
512 x 512 264224 = 258.03K 0 0 353664 = 345.37K 0 0

*special ucode allows non-mipmapped 256 x 256 textures to work on VGX.

VGXT: Spans(texels) Spans(texels)
texture size not MIPMAP 5(64) 10(160) MIPMAP 5(64) 10(160)
------------------------------------------------------------------------------
16 x 16 256 256 640 352 186 465
32 x 32 1K 64 160 1376 = 1.34K 47 119
64 x 64 4K 16 40 5472 = 5.34K 11 29
128 x 128 16K 4 10 21856 = 21.34K 2 7
256 x 256 64K 1 2 87392 = 85.34K 0 1
512 x 512 256K 0 0 349536 = 341.34K 0 0

> 2) What is the optimum size for MIP mapped bilinearly interpolated
> texture maps for
> a) VGX
> b) VGX/T
> c) Indigo Starter
> d) Elan

  See the table.

/* David Marsland "On Spaceship Earth *
 * MTS, Worldwide Education R&D there are no passengers, *
 * Silicon Graphics Computer Systems only crew." *
 * Internet: mars++at++csd.sgi.com Buckminster Fuller */

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:14 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.