On 9/17/07, Keith Whitwell <[EMAIL PROTECTED]> wrote: > > I've been thinking about this a little more and wonder if we can get > away with slightly relaxed semantics compared to NO_MOVE in some cases > at least. > > In the current SWZ branch, we're pre-validating one or two buffers (VB, > indirect state) and then using the offset directly instead of relocating. > > The difference between pre-validate and full NO_MOVE is that the > pre-validated buffers are free to move once the buffers have been > flushed, and the offsets returned can't be reused over multiple frames. > > The question is -- is it easier on the kernel side to implement the > temporary-no-move semantics from pre-validation compared to the full > NO_MOVE as discussed in the BOF? > > In a lot of circumstances, the temporary semantics are sufficient. >
Would we ever need the NO_MOVE semantics? the pre-validate is probably a lot easier to do, and the thing is the buffer could move just not between a pre-validate and its fencing... probably and interface like drmBOGetValidateOffset() which we can return the offset the buffer is going to be validated at, we can probably avoid passing lists of these (I assume we don't want to use that many pre-validated buffers...) Dave. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
