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?
Right. The X server may create/allocate an off-screen window that a
direct rendering client draws into and a compositing manager also
binds as a texture for compositing/display. That makes three parties
interested in that buffer.
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 guess I don't understand how particular "ranges" within a "region"
would become dirty. It sounds like there's two-levels of allocation
going on.
It would seem to make sense to put all the images which constitute a
texture object into one region (a mipmapped cube texture might have 60
or more images). But what about multiple texture objects in one region?
If allocations are slow/expensive, the GL driver might make
allocations in large-ish chunks that it divides up for multiple
texture objects by itself.
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.
-Brian
-------------------------------------------------------
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
