Yeah, I'm pretty interested to come up with an 'append' type of semantic for buffer usage, particularly for things like the state pools you guys are probably playing with at the moment. It's not something that's ever going to be a *requirement* for a driver, and may not necessarily be a big win or even particularly difficult, but at this point nobody's really dug into it enough to know one way or another.
Ignoring relocation issues, an 'append' mapping semantic, as opposed to the existing read/write maps, is probably an interesting concept also as it could allow mapping a state pool buffer to add new states as required by the application, but not require a fence as the old ones won't be interfered with. Keith ----- Original Message ---- From: Keith Packard <[EMAIL PROTECTED]> To: Keith Whitwell <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED]; dri-devel <dri-devel@lists.sourceforge.net> Sent: Monday, December 10, 2007 4:44:44 PM Subject: Re: i915: wait for buffer idle before writing relocations [...] 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] ------------------------------------------------------------------------- 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
