-----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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDDJaaX1gOwKyEAw8RAtysAJsEIE/lB535melOceIMEI2vWJuIWwCdGsQd 9TmFEh93cMn9WDuT/tNqp3U= =ejuh -----END PGP SIGNATURE----- ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
