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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
