DirectQ doesn't use the classic Quake "Hunk", but instead has it's own memory subsystem. The reason why I wrote this is because I wanted to remove the dependency on setting a specific value of -heapsize; in fact the -heapsize command-line option has been completely removed from the engine.
The advantage of this approach is that the engine can load any map or mod irrespective of memory requirements and with no special handling needed. It only allocates as much memory as is needed, so if a map that requires 60MB is followed up by a map that requires 8MB, things don't suffer for the 8MB map.
One disadvantage is that certain parts of the game code may assume that all allocated memory is contiguous. This doesn't apply to items that used to go in the cache, like alias models, but anything that went through the old Hunk_AllocName function might need it. I'm pretty certain that leafs and nodes need to be in contiguous memory, for example, although somehow I've gotten away with it so far.
Another disadvantage is that it's prone to the "lots of small allocations" syndrome. This is a great convenience for development - just allocate the memory you need when you need it without having to worry about anything. It's not so good for production, however; lots of small allocations are SLOW.
So far, as I indicated a few posts earlier, I've batched up some of these allocations, but that's something that I've consciously been doing outside of the memory subsystem. This is a wrong approach - the memory subsystem should be able to cope with this internally and in a totally transparent manner.
Where all of this is leading is that I'm going to do a minor rewrite. The interface will remain the same, but internally I'm thinking that I'm going to take a step both backwards and sideways, and move it to a "multiple mini-Hunks" approach. This will have the advantage of retaining the lack of a hard limit, but also of being able to allocate memory faster owing to having initial allocations of large blocks that can fill up.
Friday, June 26, 2009
DirectQ Memory Allocations
Posted by
mhquake
at
1:07 PM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment