From: Keith P. <ke...@ke...> - 2007-12-05 01:46:16
|
On Tue, 2007-12-04 at 23:42 +0100, Thomas Hellstr=C3=B6m wrote: > Kernel mapping of buffer object doesn't wait for fences to pass, however=20 > the kernel code needs to make sure before mapping, that the buffer is=20 > either on the unfenced list or validated with NO_EVICT, since a buffer=20 > 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 ca= se > we should bump DRM_BO_INIT_MINOR. If not, we should put the new member=20 > with the other 64-bit members at the top of the struct and bump=20 > 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. --=20 kei...@in... |