-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian Paul wrote:
> Ian Romanick wrote:
>
>> 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?
It's not too bad for the user. It basically amounts to doing:
base_address = get_card_address( region_id );
while ( (dirty = get_next_dirty( region_id )) != NULL ) {
upload_data( base_address + dirty->offset,
backing_store + dirty->offset,
dirty->size );
destroy_dirty( dirty );
}
In the implementation it can get a little messy, but it's not that bad
there for the most part. That said, a 1.0 (or 0.9) could just always
have a single dirty that corresponds to the entire region. In fact,
that is what happens the first time a region is committed to memory anyway.
Of course, there's nothing to prevent a driver from just always
re-uploading the entire object anytime there's any dirty ranges.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDDK42X1gOwKyEAw8RAixmAJ9ymqVQml3GMpWaaLsZ5GebkiQSbgCffRlm
ddBx7tmoVdnazrnC13A6oBE=
=lObb
-----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
