-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Paul wrote: > Nicolai Hähnle wrote: >> Am Monday 27 July 2009 02:28:00 schrieb Brian Paul: >>> The GLSL compiler uses a similar memory allocator. See slang_mem.c. >>> We should probably lift this code up into src/mesa/main/ and rename >>> the functions to make it re-usable in drivers, etc. >> Ah, cool, I missed that. > > Would you mind doing the work of lifting slang_mem.[ch] to > src/mesa/main/mempool.[ch] or similar?
I'm not sure this is the kind of allocator we really want, but I haven't yet looked at the one that Nicolai wrote. Usually for compilers and their kin, you allocate a ton of identically sized objects that need some common "construction". This is usually where people use slab allocators. Slab allocators give the convenience of using one call to free many allocations, and they tend to be really, really fast. We'd probably want to layer an allocator with an interface like slang_mem.c on top of the slab allocator. The Linux kernel has something like this, and they call it a cache allocator. Writing a slab allocator is on my current to-do list. If somebody gets to it first, that would be awesome. :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpuSXIACgkQX1gOwKyEAw8CnwCfcTSFGxEfOG9hKaScr6JK2Fcb 4LEAnjyLtuFSP5VRsGVCS6smnx7/EZnv =pPh8 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
