On Wed, Sep 09, 2015 at 04:07:09PM +0200, Michał Winiarski wrote:
From: Chris Wilson chris@chris-wilson.co.uk
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.
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_48BBADDRESS. User must assume responsibility for any addressing workarounds. Updated object2.offset field comment again to clarify NO_RELOC case (Chris). checkpatch cleanup.
v6: Rebase on top of current nightly. Dropped any references to EXEC_OBJECT_SUPPORTS_48BBADDRESS since those don't exist in upstream yet, and are not a dependency.
Cc: Chris Wilson chris@chris-wilson.co.uk Cc: Akash Goel akash.goel@intel.com Cc: Vinay Belgaumkar vinay.belgaumkar@intel.com Cc: Michal Winiarski michal.winiarski@intel.com Cc: Zou Nanhai nanhai.zou@intel.com Cc: Kristian Høgsberg hoegsberg@gmail.com Signed-off-by: Chris Wilson chris@chris-wilson.co.uk Signed-off-by: Thomas Daniel thomas.daniel@intel.com Signed-off-by: Michał Winiarski michal.winiarski@intel.com
Again, the precursors are not included in this series or upstream, so NAK. -Chris