From: Rik F. <fa...@va...> - 2000-05-23 16:26:29
|
On Mon 22 May 2000 14:02:41 +0100, Ala...@bt... <Ala...@bt...> wrote: > Is there any document detailing the DRM Texture Management functions ? No. driTMM is a client-side abstraction for managing texture memory. It assumes that texture memory is linear (e.g., not tiled), that there are two driver-supplied functions that can be used to load images and subimages, and that the size and layout of the memory being managed will not change out from under the driTMM system (this means that another client cannot force a texture out of memory, although moving the whole block of memory to a new location would be ok, since that is handled elsewhere). Note that the last restriction could be relaxed if there were callbacks to tell driTMM when an texture is no longer resident (to add this, you just have to expose the interface that frees the area that is describing where a particular texture is resident in the driTMM abstract space). The main thing that driTMM gives you is the ability to force a _set_ of textures to be resident (e.g., for mipmaps) and to determine the best textures to kick out if the texture memory is full (using OpenGL priority and a simple LRU algorithm). driTMM is an abstraction -- it doesn't actually know where the texture is loaded on the card, it just knows whether or not the texture is loaded, whether or not another texture will fit in the empty spaces between loaded textures, and which are the best textures to overwrite when texture memory is full. |