On Wed, 2005-08-24 at 08:47 -0700, Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Brian Paul wrote: > > > 1. I'd like an allocator that can be used outside/independent of the > > Xserver. Specifically, an allocator that EGL and EGL drivers can use. > > > > 2. There needs to be a way to share memory blocks between processes. > > So that an off-screen "window" could be shared by the X-server and the > client-side driver? The current designs don't really account for that. > I suspect that this would just require a way to associate multiple > process IDs with a region ID (see below). The does change the way we'd > have to manage region IDs. Hmm... > > > 3. Blocks should get automatically freed when the process that creates > > them terminates (unless they're shared w/ another process, perhaps). > > > > 4. Blocks should probably be named by an opaque handle. That might help > > to support some kind of simple security model plus allow memory blocks > > to be relocated, etc. > > > > 5. Blocks would have to be locked in some manner while they were > > actually in use. We don't want to move a texture image while it's being > > used. > > > > 6. There should be a mechanism for the allocator to notify a process > > when one of its blocks is moved/ejected/changed. > > In the prototype code that I posted to the list several months ago, > these four things were handled together. Each object has an associated > "region ID". The region IDs are allocated to a process by the kernel, > and they can therefore be reclaimed when the process dies. > > When a process wants to use a region, it calls a function to conver the > region ID to an address. Two functions exist. One converts the region > ID to a CPU address, and the other, with the help of a device-specific > callback, converts the region ID to a card address. This commits the > object to memory. > > After an object is committed to memory, another function is called to > get a list of "dirty" ranges in the region. These are portions of the > region that need to be restored. In the original design the commit > routine would automatically have the kernel restore precious regions. > Since we've made the change that user-mode provides the kernel with > backing store for the region, this is no longer necessary. The > user-mode driver restores precious regions just like other regions. > > I had all this spread into 3 layers. There's a kernel layer, a > device-independent user-mode layer, and a device-dependent user-mode > layer. Almost everything should be doable in the device-independent > user-mode layer. > > > 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. > > > > 8. Try to keep both the interface and implementation as simple as > > possible with an eye toward future extensions. > > > > > > I think it would be worthwhile to start a specification document for > > this project (or perhaps a wiki page) where the requirements, issues and > > proposed interface could be recorded. Any volunteers? > > Yeah. We've got discussions going on in enough different places that we > really need to gather all the information in one place.
Could we use http://dri.freedesktop.org/wiki/DriMemoryManagerDesign ? I've added some bits on XAA/EXA and kernel swapping-out issues. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
