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

[Niranjan Vishwanathapura]

On Tue, Nov 26, 2019 at 03:59:31PM +0200, Joonas Lahtinen wrote:
>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.
>

Thanks Joonas.
Ok, makes sense. I will make it as such.

>> 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...
>

Though current patchset only supports migrating pages from
host to device memory, I intend to support migrating from device
to host memory as well with same ioctl. User would want that.
Not sure what would be a good name then, _MIGRATE/_PREFETCH/_MOVE?

Also, migrating gem objects is currently handled by separate ioctl
which is part of LMEM patch series. I am open to merging these
ioctls together (similart to VM_BIND) into a single MIGRATE ioctl.

Niranjana

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