On Thu, Oct 22, 2015 at 03:15:55PM +0100, Tvrtko Ursulin wrote: > > Hi, > > On 21/10/15 16:24, Chris Wilson wrote: > >Our GPUs impose certain requirements upon buffers that depend upon how > >exactly they are used. Typically this is expressed as that they require > >a larger surface than would be naively computed by pitch * height. > >Normally such requirements are hidden away in the userspace driver, but > >when we accept pointers from strangers and later impose extra conditions > >on them, the original client allocator has no idea about the > >monstrosities in the GPU and we require the userspace driver to inform > >the kernel how many padding pages are required beyond the client > >allocation. > > > >v2: Long time, no see > > [snip] > > >diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > >index 08e047cba76a..678f7d5320ae 100644 > >--- a/include/uapi/drm/i915_drm.h > >+++ b/include/uapi/drm/i915_drm.h > >@@ -691,10 +691,11 @@ struct drm_i915_gem_exec_object2 { > > #define EXEC_OBJECT_NEEDS_GTT (1<<1) > > #define EXEC_OBJECT_WRITE (1<<2) > > #define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3) > >-#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_SUPPORTS_48B_ADDRESS<<1) > >+#define EXEC_OBJECT_PAD_TO_SIZE (1<<4) > >+#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PAD_TO_SIZE<<1) > > __u64 flags; > > > >- __u64 rsvd1; > >+ __u64 rsvd1; /* pad_to_size */ > > __u64 rsvd2; > > }; > > What do you think about: > > union { > __u64 pad_to_size; > __u64 rsvd1; > } ? > > Kind of like a migration path for userspace? Hmm, I think that just might work. Clang? Does clang support anonymous unions yet? Do we care if it doesn't? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx