david.heskamp++at++lmco.com
Tue, 4 Nov 97 14:26:38 EST
--- Begin Included Message ---
Here's an answer from Mark Peercy, who knows this stuff...
> | From: ESPELSA-STC <espelsa++at++mad.servicom.es>
> | To: "info-performer++at++sgi.com" <info-performer++at++sgi.com>
> | Subject: Computing TRAM usage on iR
> | Date: Thu, 16 Oct 1997 13:45:55 +-100
> |
> | Hi all,
> |
> | I'm trying to compute the TRAM usage due to more than one clipmap,
> | although this could be applied to regular mipmaps.
> |
> | Each level's size will be added to a TRAM bank alternatively, and this
> | will yield different occupacies per bank for the first
> | clip/mipmap. Now, for the second clipmap, will its first level be
> | loaded in bank 0 (more loaded in my computation) or in bank 1? What
> | will happen to the third mipmap? A new clipmap might be accepted
> | without overloading TRAM depending on where will the first level and
> | subsequent levels go.
>
> Assuming an application has not run out of texture memory, we always try
> to place the larger collection of levels on the bank with more space.
> So two identical textures loaded back to back will occupy exactly the
> same amount of space total on both banks.
>
> | Further, since the mipmap levels occupy *areas* rather than *lengths*
> | and thus, texture occupancies do not actually sum up linearly,
> | an estimation in this fashion can be risky. Is there any fine grain
> | algorithm available for this computation?
>
> Except for really small levels (<8x8) the memory allocation acts as if
> it were linear within each bank.
>
> | And one additional issue: does iR manage the last 5 levels of a mipmap
> | in a single bundle as IMPACT so that they are not distributed
> | alternatively in banks but rather stay together in one?
>
> No; the iR treats every level uniquely. The smallest levels are expanded
> slightly in terms of memory usage in a space-vs-efficiency tradeoff, but
> alternating levels go to opposite banks.
Also, if you set the environment variable GLKONA_TEXTURE_USAGE,
you'll get some info messages saying how much texture memory
is being used.
Don
--
Don Hatch hatch++at++sgi.com (415) 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
--- End Included Message ---
Dave Heskamp
=======================================================================
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:56:12 PDT