Dave Airlie wrote: > 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. > All needs I can see for NO_MOVE semantics, In particular the case where hardware might store buffer offsets in-between calls can be handled by the pre-validate case described above, but there is a problem with user-space pools.
For some zone rendering hardware, one would probably like to have a pool of NO_MOVE buffers. This means that the underlying drm buffer object needs to be NO_MOVE, and chances are that the GPU will always be working with parts of this buffer object. Pre-validate wouldn't be sufficient in this case. Also, pre-validate doesn't get rid of the DOS problem. A client can potentially pre-validate a number of buffers and just don't flush them. The NO_MOVE semantics as discussed in the BOF allows for NO_MOVE buffers to be evicted, in practice they never are except at VT switching. Also, a NO_EVICT buffer can never share aperture space with a NO_MOVE buffer. Further, we need to have the restriction that NO_MOVE buffers are not shareable, which seems OK. This means that clients (as identified by the drm file ) can evict other client's NO_MOVE buffers. Implementing this is a bit complicated, but doable. Still, we'll have a DOS problem unless we restrict the GPU virtual space available to NO_MOVE buffers. Thomas. ------------------------------------------------------------------------- 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
