On Mon, 2007-12-10 at 13:27 +0000, Keith Whitwell wrote: > OK, it sounds like you're talking about situations where the driver is > modifying state in buffers *only* through changes to the relocations?
Yes, although I also don't expect this to be common. > It's probably not surprising the fence is not implemented as I'd > normally think that those relocation changes would be associated with > some changes to the other data, and that would imply mapping the buffer > (and hence the wait). If the buffer was mapped (and waited for) by the client, then the kernel 'wait' will be free. > I do understand the examples though and can see > where you're trying to take this. Ok, thanks for thinking it through. > Anyway, I'm hopeful that this won't break other usages... I think the interesting usage that you point out is where the application "knows" that a wait isn't necessary as the previously referenced data will not be re-used, and only new portions of the buffer need relocations. Given the choice between avoiding waits for cases we have today vs avoiding waits for cases we may try in the future, it seems reasonable to solve what we're using now. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
