On Mon, 03 Mar 2003 10:38:40 -0800 Ian Romanick <[EMAIL PROTECTED]> wrote:
> Not too many updates this time. > > There are a few issues that I really want to discuss & work out before > any coding begins. > > 1. Felix Kuhling asked, basically, how does a process manage the memory > blocks that it has claimed. The issue is that each process "owns" a set > of memory_blocks that may or may not be full. How do we manage > allocations within those blocks? A related issue is with assigning > block IDs. How would we handle a situation where we could allocate an > object that spans the end of a memory_block with on ID value and the > start of another memory_block with a different ID value? If the driver wants to allocate a new object which doesn't fit in any memory_block already allocated then you're saying that it should be possible to allocate another memory_block so that the new object spans from the end of the old block into the beginning of the new one. That requires that both blocks are adjacent in address space. It would make the memory reclaim algorithm a bit more complicated if you trade off contiguous block allocation (memory efficient) versus whatever logic that minimizes the need for paging or refilling of blocks. You could have some sort of a threshold of reclaim priority. If the adjacent block's reclaim priority is below that threshold you'd rather allocate a new block. The simple alternative would be to always allocate a new memory_block if an object doesn't fit into one that is already allocated. How expensive in terms of wasted memory would this be? The worst case scenario would be a series of allocations of exactly block_size+1 words per object. For each one you would have to allocate two new memory_blocks. So you'd waste a bit less than half the memory. But that is the *worst* case. > > 2. Issues 3.1 & 3.2. Basically, what extra data needs to be tracked in > the memory_block so that we can make decide which blocks to reclaim? > > 3. Issue 3.11. Where should the device independent, client-side code > live? lib/GL/dri and lib/GL/mesa/src/drv/common are two candidates. > > I think if we can resolve these issues, we can reasonably start doing > some coding. Thoughts? > I have one more question. You defined a driBufferRelease function. But it can only free a block if all buffers in that block were released. How does one know when a released buffer was the last one in a block? If the prev,next pointers link driMemoryBuffers in one memory_block or sequence of memory_blocks with the same ID then they could be used. Was that the idea? In that case with respect to the problem discussed above, a buffer that spans two memory_blocks with different IDs would have to be in two separate lists, one for each memory_block. Otherwise you would end up extending the same list all the time. When a block becomes "empty" the list will already contain buffers in the next block. So empty blocks could not be detected and freed. With the current layout you cannot have a driMemoryBuffer in more than one linked list. Now spin all the argument backwards and you get "Buffers spaning adjacent memory_blocks don't work", at least not with the design from 2003/02/24. Regards, Felix ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, Kühling (_____\Ä/____/ /_____/ /________) just not everything [EMAIL PROTECTED] \___/ \___/ U at the same time. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
