On Wed, 2007-12-05 at 08:47 +0100, Thomas Hellström wrote: > In the case of a re-used batch-buffer, user-space mapping will wait for > the right fence before filling it, so when the buffer is submitted to > the super-ioctl and validated, it's put on the unfenced list, cannot > move while patched up, and everything is fine. This is the only case > we've dealt with so far, and should be OK for i915.
Right, the batch buffer will have been modified in user space, and hence fenced nicely. > If it happens to be a reused state buffer that is not mapped by > user-space in between command submissions, the code should call > drm_bo_wait() (bo mutex locked) before actually writing to the buffer. 965 state buffers will refer to other objects which may move. Of course, those other objects should be fenced along with the state buffer, so things 'should' work out fine. > Since it's still on the unfenced list (but at the same time retaining > its old fence if any) until submitted or an error occurs, it can't be > evicted at this point. > This is not done in the current Intel code, and will be needed for i965 > if this case occurs? Ok, I'll look at adding this then; it 'should' be free as any ability for the state buffer to need updating will be predicated on the referenced object moving, which would have required the relevant fence to have passed. > The important thing is that kernel bo mapping is not implicitly waiting > for buffer idle. This seems wrong to me; we must wait for the buffer to be idle before writing to it from the CPU. With relocation caching, this shouldn't cause additional waits if the application is working properly, but it seems like you're breaking the mapping invariant here. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
