> The framebuffer (including color, Z, stencil, etc) > Pbuffers > Renderbuffer/Framebuffer objects > Pixel/Vertex buffer objects > Texture images > OpenGL miscellaneous (e.g. vertex/fragment programs) > X server miscellaneous (pixmap cache, etc)
Most of these are fairly static objects. > 1. The location of the object in memory (perhaps the framebuffer has > to be at the start of memory). > 2. Particular byte/word alignments > 3. Can we use VRAM and/or AGP memory for the object? > 4. Can the object can be lost asynchronously (Pbuffers)? and textures. > 3. Blocks should get automatically freed when the process that creates > them terminates (unless they're shared w/ another process, perhaps). We normally refcount objects. You have to do that anyway to deal with horrible cases that crop up where you can't just recover an object on the spot because of DMA and the like. > 6. There should be a mechanism for the allocator to notify a process > when one of its blocks is moved/ejected/changed. Architecturally hard from the kernel side and almost always going to cause bugs. Better that the lock() request discovers the the object is gone than a notification system. > 7. The public interface to the allocator should be OS-independent so > that it can be implemented on Linux, FreeBSD, etc. Perhaps the public > API would be exposed through a library which wraps an OS-specific > interface based on ioctls, etc. The natural way to express it in Linux would be mmap and some kind of device or filesystem perhaps not dissimilar to posix shared memory support. Most of the properties just "happen" when you have such an interface - refcounting, callbacks on exit, address assignment etc. How about BSD - similar ? ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
