Ian Romanick wrote:
-----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.
This sounds fairly complicated (both for the implementor and the user).
Is there anyway we could live without that feature and just manage
things at the granularity of whole regions for version 1.0?
-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
