magenta wrote:
On Fri, Jan 17, 2003 at 08:13:05PM -0600, Jeff Hartmann wrote:
There is one subtle, but important, difference. The can-swap bit needs to be updated when the fence is completed. If the fence value is stored in the block when the fence is set, no further update is required. This was one of the problems in my original post. If only a can-swap bit is used, how do you prevent clients from forgetting to set the bit when it can be set?I think we're running into some terminology problems here. In the existing memory manager, the age is a "when was it last used" variable. In the new proposals, the age is a fence. There are still wrap-around issues. :(Actually if it is a straight monotonically increasing unsigned 32-bit counter we can do the signed comparision: (s32)current_age_counter - (s32)buffer_age < 0Assuming 'current age counter' is a time value for 'expire everything older than this,' then yes, that works, as long as you have fewer than 2^32 objects in the memory pool (which I don't see as a problem in the forseeable future). :) I thought that the age counter was just going to be something for finding a minimum value for LRU. But if you use a wraparound counter based on, say, the number of events which have occurred, then you'd might as well just use the clock algorithm instead, and require only one bit for the 'purge_okay' flag. It'll have the same results.
I'm still not 100% convinced that it is the best sollution, but it is a sollution. :)
[snip]
This is the way most of the DRM currently works. I suspect that it will be possible to continue doing so.It is always a balance, putting things in the kernel and userspace. I'm fairly confident we will need some kernel support for this project, if we want to acheive our goal. I think we will try and keep the requirements on the kernel well defined though, and not too exotic. Perhaps too we will allow some/most of the benefits of the code to run on some operating systems, while we get full usage only on systems that support certain features we need. As the system gets designed I suppose we will just have to try and keep these issues in mind I guess.I'm a big fan of abstraction layers, myself... why not define an abstraction layer which provides the various functionality needed by the memory manager, and then put OS-specific stuff into the implementation? Surely the model won't be so different between any two OSes that it can't be boiled down to a single common set of higher-level functions... Or is that me being too naive again? (I'm a graphics programmer, not a kernel programmer, and I know just enough about systems level stuff to be dangerous. :)
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
