On Mon, 24 Feb 2003 11:24:14 -0800 Ian Romanick <[EMAIL PROTECTED]> wrote:
Here is the updated version of the texmem-0-0-2 design document. Hopefully everyone will have a chance to look over the changes before the #dri-devel meeting today. Sorry for getting this out so late.
While reading it again, there is one subtle issue that starts bothering me. You allow both:
1. one memory_block used by several logical objects 2. one logical object spanning several memory_blocks
To cope with the second one you have the sequence numbers that link memory_blocks used by the same logical object. The one logical object is identified by its block ID.
In the other case you would have several logical objects which share the same memory_block and must therefore share the same block ID, as the memory_block tracks only one block ID. That sharing must be handled in the user space code. But I coulnd't find any details about that.
You are correct on all those points. There are no details about that in the doc because I haven't thought of a good way to do it yet. :) My thinking is to use something like the current memHeap_t code (see lib/GL/mesa/src/drv/common/mm.[ch]). When a memory is allocated, try to assign a new ID, or propogate the existing block ID to new blocks. The tricky part is the case where the allocated memory spans the end of a block with one assigned ID and the start of a block with a different established ID.
Another thing is in section 2.2.2.1 where you stress that driBufferSetFence updates usage statistics for the reclaim strategy. You set a fence for a buffer in user space. However, the usage statistics must be tracked in the associated memory_blocks as this statistics has to be visible to the other clients that want to reclaim buffers. Probably that's what you meant and I'm just pendantic. ;) And does "usage statistics" refer to the fence value or will there be anything more?
There will probably be something more. Early on there was a lot of talk (in the #dri-devel meeings) about whether to use LRU, MRU, or something else. My person opinion is that some other mechanism should be at least tried. To do that, we need to track more information. The question is what and how. That's (the very vague) issues 3.1 and 3.2. :)
------------------------------------------------------- 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
