[Intel-gfx] [RFC 03/13] drm/i915/svm: Runtime (RT) allocator support

Joonas Lahtinen joonas.lahtinen at linux.intel.com
Tue Nov 26 13:59:31 UTC 2019


Quoting Niranjan Vishwanathapura (2019-11-25 18:40:57)
> On Mon, Nov 25, 2019 at 09:59:37AM +0000, Chris Wilson wrote:
> >Quoting Niranjana Vishwanathapura (2019-11-22 20:57:24)
> >> Shared Virtual Memory (SVM) runtime allocator support allows
> >> binding a shared virtual address to a buffer object (BO) in the
> >> device page table through an ioctl call.
> >
> >The ioctl though is not svm specific, it is to do with "bulk residency"
> >and can be used to reduce execbuf traffic to provide virtual address
> >layout controls to e.g. Vulkan clients.
> >
> >I915_VM_BIND {
> >       uint32_t vm_id;
> >       int32_t fd; /* or -1 for anon, or buf depending on flags */
> >       uint64_t flags;
> >       uint64_t offset; /* offset info fd [page aligned] */
> >       uint64_t length; /* page aligned */
> >       uint64_t iova; /* page aligned */
> >       uint64_t extensions;
> >}; /* where page aligned is actually more I915_GTT_PAGE_ALIGNMENT */
> >
> >as I recall. I also recall it being part of a future command stream
> >interface to reduce ioctls, but that is another story.
> 
> Thanks Chris.
> I will change I915_BIND to I915_VM_BIND.

We're very much depending on GEM VM even if BOs wouldn't be used,
so this is best called I915_GEM_VM_BIND to match I915_GEM_VM_CREATE
and avoid user confusion.

> Currently, it is only addressing binding SVM system (buffer) and runtime (BOs)
> allocations. But it can be expanded for other bindings. I have 'type' field
> instead of 'fd' and 'extensions' & 'iov' can be added later if required.

We should try to have the uAPI as final as early as possible. The
change process is harder the later it is done, even for RFC :)

On the same note, I'm inclined to have I915_SVM_MIGRATE called
I915_GEM_VM_PREFAULT from the start, as I already have got some
confused questions from folks who mix it with memory pressure
initiated migration. And it's inherently racy as anybody could
race with it, so PREFAULT would give an impression of that.

And I think I915_GEM_VM_PREFAULT would be a generally applicable
function, just like I915_GEM_VM_BIND. So we should use a struct
member names that are close to I915_GEM_VM_BIND.

Better ideas for name to emphasis the nature of what is being
done? I915_GEM_VM_FAULT/I915_GEM_VM_{M,}ADVICE...

Regards, Joonas

> Is that OK?
> 
> >-Chris
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx


More information about the dri-devel mailing list