On Wed, Dec 09, 2015 at 10:30:41AM +0000, Tvrtko Ursulin wrote: > > On 08/12/15 18:49, Michel Thierry wrote: > >On 12/8/2015 11:55 AM, Thomas Daniel wrote: > >>From: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > >> > >>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 <chris@xxxxxxxxxxxxxxxxxx> > >> > >>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 <chris@xxxxxxxxxxxxxxxxxx> > >>Cc: Akash Goel <akash.goel@xxxxxxxxx> > >>Cc: Vinay Belgaumkar <vinay.belgaumkar@xxxxxxxxx> > >>Cc: Michal Winiarski <michal.winiarski@xxxxxxxxx> > >>Cc: Zou Nanhai <nanhai.zou@xxxxxxxxx> > >>Cc: Kristian Høgsberg <hoegsberg@xxxxxxxxx> > >>Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> > >>Signed-off-by: Thomas Daniel <thomas.daniel@xxxxxxxxx> > >>--- > >> drivers/gpu/drm/i915/i915_dma.c | 3 ++ > >> drivers/gpu/drm/i915/i915_drv.h | 2 + > >> drivers/gpu/drm/i915/i915_gem.c | 64 > >>++++++++++++++++++++---------- > >> drivers/gpu/drm/i915/i915_gem_evict.c | 39 ++++++++++++++++++ > >> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 16 +++++++- > >> include/uapi/drm/i915_drm.h | 12 ++++-- > >> 6 files changed, 111 insertions(+), 25 deletions(-) > >> > > > >Extra support from the other patch aside, v6 already had rb from Akash > >and this one, > >Reviewed-by: Michel Thierry <michel.thierry@xxxxxxxxx> > > This patch was acked by the PDT so I merged it to drm-intel-next-queued. Please revert immediately. We need to fix the ABI for canonical addressing before proceeding. Then please work on the better patch. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
