path: root/include/uapi/drm/i915_drm.h
diff options
authorChris Wilson <>2015-12-08 11:55:07 +0000
committerTvrtko Ursulin <>2015-12-09 10:20:17 +0000
commit506a8e87d8d2746b9e9d2433503fe237c54e4750 (patch)
treeef8712f9deffc5f3c1aa35b7d0f8008fff898051 /include/uapi/drm/i915_drm.h
parent0f55564406d7005c2d681b14e2b7e2248d8c412d (diff)
drm/i915: Add soft-pinning API for execbuffer
Userspace can pass in an offset that it presumes the object is located at. The kernel will then do its utmost to fit the object into that location. The assumption is that userspace is handling its own object locations (for example along with full-ppgtt) and that the kernel will rarely have to make space for the user's requests. Signed-off-by: Chris Wilson <> v2: Fixed incorrect eviction found by Michal Winiarski - fix suggested by Chris Wilson. Fixed incorrect error paths causing crash found by Michal Winiarski. (Not published externally) v3: Rebased because of trivial conflict in object_bind_to_vm. Fixed eviction to allow eviction of soft-pinned objects when another soft-pinned object used by a subsequent execbuffer overlaps reported by Michal Winiarski. (Not published externally) v4: Moved soft-pinned objects to the front of ordered_vmas so that they are pinned first after an address conflict happens to avoid repeated conflicts in rare cases (Suggested by Chris Wilson). Expanded comment on drm_i915_gem_exec_object2.offset to cover this new API. v5: Added I915_PARAM_HAS_EXEC_SOFTPIN parameter for detecting this capability (Kristian). Added check for multiple pinnings on eviction (Akash). Made sure buffers are not considered misplaced without the user specifying EXEC_OBJECT_SUPPORTS_48B_ADDRESS. User must assume responsibility for any addressing workarounds. Updated object2.offset field comment again to clarify NO_RELOC case (Chris). checkpatch cleanup. v6: Trivial rebase on latest drm-intel-nightly v7: Catch attempts to pin above the max virtual address size and return EINVAL (Tvrtko). Decouple EXEC_OBJECT_SUPPORTS_48B_ADDRESS and EXEC_OBJECT_PINNED flags, user must pass both flags in any attempt to pin something at an offset above 4GB (Chris, Daniel Vetter). Cc: Chris Wilson <> Cc: Akash Goel <> Cc: Vinay Belgaumkar <> Cc: Michal Winiarski <> Cc: Zou Nanhai <> Cc: Kristian Høgsberg <> Cc: Tvrtko Ursulin <> Reviewed-by: Michel Thierry <> Acked-by: PDT Signed-off-by: Thomas Daniel <> Signed-off-by: Tvrtko Ursulin <> Link:
Diffstat (limited to 'include/uapi/drm/i915_drm.h')
1 files changed, 9 insertions, 3 deletions
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 67ef73a5d6eb..d727b49f07ac 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -356,6 +356,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_EU_TOTAL 34
#define I915_PARAM_HAS_GPU_RESET 35
typedef struct drm_i915_getparam {
__s32 param;
@@ -682,8 +683,12 @@ struct drm_i915_gem_exec_object2 {
__u64 alignment;
- * Returned value of the updated offset of the object, for future
- * presumed_offset writes.
+ * When the EXEC_OBJECT_PINNED flag is specified this is populated by
+ * the user with the GTT offset at which this object will be pinned.
+ * When the I915_EXEC_NO_RELOC flag is specified this must contain the
+ * presumed_offset of the object.
+ * During execbuffer2 the kernel populates it with the value of the
+ * current GTT offset of the object, for future presumed_offset writes.
__u64 offset;
@@ -691,7 +696,8 @@ struct drm_i915_gem_exec_object2 {
#define EXEC_OBJECT_NEEDS_GTT (1<<1)
#define EXEC_OBJECT_WRITE (1<<2)
+#define EXEC_OBJECT_PINNED (1<<4)
__u64 flags;
__u64 rsvd1;