-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Paul wrote: > Ian Romanick wrote: > >> 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.
1. Video card has 8MB. 2. 1MB of the card memory is allocated for the front buffer and pinned. 3. Process A allocates (and commits) a 7MB region for a big texture. 4. Process B allocates (and commits) a 2MB region for a texture. To do this, it kick out part of process A's allocation. 5. Process A re-commits its 7MB texture. At #5 we'd much rather just upload the damaged 1MB than have to upload the whole 7MB. This is just a simple example, but the same scenario happens with larger on-card memory + AGP memory and larger textures. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDDKG+X1gOwKyEAw8RAqEIAJ0YFkTG6oe55UpfEg/T5OzhLfDz7QCfdWkb aWOOo91HZrCtcMEyvysEo7U= =3ptv -----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
