On Fri, Jan 17, 2003 at 08:13:05PM -0600, Jeff Hartmann wrote: > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Ian Romanick > > Sent: Friday, January 17, 2003 7:12 PM > > To: DRI developer's list > > Subject: Re: [Dri-devel] The next round of texture memory management... > > > > > [snip] > > > > Also, using an age variable leads to lots of other really > > difficult issues, > > > like what happens when it wraps around. A clock algorithm (as it was > > > called in my undergraduate courses, anyway) for paging out > > would probably > > > be better. > > > > 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 < 0
Assuming '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. > Just like the code in the linux kernel that does signed compares to deal > with timer wraps. As long as you're only comparing timer events which have happened within the past 2^32 clock ticks, sure. > [snip] > > Putting some stuff in the kernel is fine as long as we don't rely on > > exotic, Linux-specific in-kernel interfaces. Putting too heavy of a > > reliance on the new Linux AGPGART or on specifics of the Linux VM are > > likely to get us in trouble. > > > > It will also make it more difficult to port to other systems. This > > might be a good time to look at what some of our kernel issues are. I > > seem to remember a thread about porting the DRM to Solaris that > > ultimately led to despair. :( > > 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. :) -- http://trikuare.cx ------------------------------------------------------- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
