On Mer, 2005-08-24 at 11:18 -0600, Brian Paul wrote: > > 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?
If you make the API return a bitmap at some sane granularity (say 256K ?) then you can implement 1.0 the naiive way and have the API just continue to work once the underlying code is smarter. ------------------------------------------------------- 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
