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. > 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. -- [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