Keith, Keith Packard wrote:
>On Tue, 2007-12-04 at 23:42 +0100, Thomas Hellström wrote: > > > >>Kernel mapping of buffer object doesn't wait for fences to pass, however >>the kernel code needs to make sure before mapping, that the buffer is >>either on the unfenced list or validated with NO_EVICT, since a buffer >>must not move while the kernel has it mapped. >> >> > >How can this possibly work then? I'm about to write relocations to this >buffer, so presumably it must await a fence. > > 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. 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. 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? The important thing is that kernel bo mapping is not implicitly waiting for buffer idle. > > >>Is this meant to be backwards compatible with an older kernel? In that case >>we should bump DRM_BO_INIT_MINOR. If not, we should put the new member >>with the other 64-bit members at the top of the struct and bump >>DRM_BO_INIT_MAJOR. >> >> > >Yes, it should be backward compatible. The req is smaller than the rep, >so adding new members won't change the alignment. Also, as the flag >indicates whether the additional data is present, older clients won't >accidentally trigger the optimization. Furthermore, as this is purely an >optimization, newer clients needn't even bother to check for the kernel >version. We can bump the minor version, but I'm not going to add checks >for it. > > > OK. No bother bumping then. /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
