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]

Attachment: 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

Reply via email to