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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux