[SDL] glSDL Texture sizes

David Olofson david at olofson.net
Wed Nov 12 12:57:02 PST 2003

On Wednesday 12 November 2003 17.08, Bob Pendleton wrote:
> Personally I'm starting to like the idea of a bit map based
> allocator like the one described earlier.

Yeah. It allows for more efficient texture space allocation, 
especially when dealing with odd (ie non power-of-two) sizes. It 
might have fragmentation issues with certain mixes of allocation 
sizes and tile sizes, but OTOH, it doesn't chop up good contigous 
space when allocating small areas.

> If you use two layers of
> bit maps you can solve your problem pretty well. The top layer is
> used to allocate max texture sized textures out of the available
> space and unused space withing those blocks can be kept track of
> and allocated using another bit map for each block.

I'm not sure I get the point with the top layer bit map. To keep track 
of allocations bigger than the max texture size...? That wouldn't 
make sense, since tiles in a surface can come from anywhere 
physically; the only requirement is that there's some way of finding 
them when they're needed.

Anyway, a 2048x2048 RGBA8 texture is 16 MB, which is rather big to use 
as allocation granularity for many of the cards that support 
2048x2048 textures. (Even some 16 MB cards support that large 
textures, though it's obviously not physically possible to keep one 
in VRAM together with the frame buffer. It's just supported because 
textures can have less than 32 bpp, and/or because there are versions 
of the card with more VRAM.)

Maybe it would make sense to have some kind of internal limit here, 
maybe related to the display resolution or something... Tiles larger 
than the screen don't make much sense, even for huge surfaces. If 
they do anything, it would be preventing OpenGL from swapping parts 
of a huge surface (of which only a part at a time is used) out of 
VRAM, to leave room for other data that is actually used every frame.

Then again, texture binding has a significant cost on some cards, 
which makes this a balance act. Limit max texture size to twice the 
size of the screen? Limit it so one texture uses less than 30% of the 
available VRAM? Other ideas?

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---

More information about the SDL mailing list