On 20 Sep 2001, Thayne Harbaugh wrote:
> What's the best way for managing vram memory if there are many small
> off-screen images? I thought libgalloc could do this?
LibGAlloc takes a hands off approach to this, because it is very
much a matter of preference: there are many different ways to manage
your memory, some optimized for speed, some for utilization, some
for convenience of use. We didn't want to lock anyone in to any
particular cache management system.
So how, you may ask, does a graphics allocator "allocate" VRAM
without providing a caching policy? Good question, glad you
asked :-)
LibGAlloc allows you to ask for a chunk of VRAM for a certain
purpose, with a certain geometry. You can also ask for N identical
chunks of VRAM, in a single LibGAlloc resource. LibGAlloc will find
the necessary VRAM, if it exists, and pass back information on
where and how to access it. This information includes a way to
find the start addresses of each of the N chunks.
But what if you don't want identical sized chunks? Another good
question! :-)
LibGAlloc also allows you to request a "shared" resource. When you do so,
you tell it which resource to share storage with. A shared resource uses
overlapping VRAM with that resource. Say you send resource A asking for
200x200 textures and resource B asking for 100x150 textures. Since you
are given exact information about the rules for placing the textures,
you can develop your own caching strategy -- it is up to you to decide
when/where the storage is used for A sized, vs B sized, resources.
In fact, as long as compatible storage types are available, and a resource
does not flavor the VRAM so it is incompatible, LibGAlloc allows any type
of resource to share with any other -- so you can mix up 3d textures,
2d Blts, etc. etc. as you see fit. If we find that a given caching
strategy works well for a particular purpose, we can then provide an
independent library to provide it.
--
Brian
