Keith Packard wrote: >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. > > > Keith, I have nothing against wrapping the drm_bo_kmap() function with a wait for fence and another function name, but the current version is just a convenience function to find the right pages to map and map them in the right way, instead of using ioremap etc. directly. It relies on the driver writer knowing what to do and doing it.
Mapping in the kernel is different from mapping from user-space in that the buffer must not move while mapped, except in some very special cases. There are cases for example in the poulsbo driver where one needs to access a buffer in the middle of command processing while it's fenced and obviously waiting for the fence to expire here would cause a deadlock. /Thomas ------------------------------------------------------------------------- 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
