Re: [Intel-gfx] [RFC v2 02/12] drm/i915/svm: Runtime (RT) allocator support

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

 



On Fri, Dec 13, 2019 at 04:58:42PM -0600, Jason Ekstrand wrote:

    +/**
    + * struct drm_i915_gem_vm_bind
    + *
    + * Bind an object in a vm's page table.

  First off, this is something I've wanted for a while for Vulkan, it's just
  never made its way high enough up the priority list.  However, it's going
  to have to come one way or another soon.  I'm glad to see kernel API for
  this being proposed.
  I do, however, have a few high-level comments/questions about the API:
   1. In order to be useful for sparse memory support, the API has to go the
  other way around so that it binds a VA range to a range within the BO.  It
  also needs to be able to handle overlapping where two different VA ranges
  may map to the same underlying bytes in the BO.  This likely means that
  unbind needs to also take a VA range and only unbind that range.
   2. If this is going to be useful for managing GL's address space where we
  have lots of BOs, we probably want it to take a list of ranges so we
  aren't making one ioctl for each thing we want to bind.

Hi Jason,

Yah, some of these requirements came up.
They are not being done here due to time and effort involved in defining
those requirements, implementing and validating.

However, this ioctl can be extended in a backward compatible way to handle
those requirements if required.

   3. Why are there no ways to synchronize this with anything?  For binding,
  this probably isn't really needed as long as the VA range you're binding
  is empty.  However, if you want to move bindings around or unbind
  something, the only option is to block in userspace and then call
  bind/unbind.  This can be done but it means even more threads in the UMD
  which is unpleasant.  One could argue that that's more or less what the
kernel is going to have to do so we may as well do it in userspace. However, I'm not 100% convinced that's true.
  --Jason


Yah, that is the thought.
But as SVM feature evolves, I think we can consider handling some such cases
if hadling those in driver does make whole lot sense.
Thanks,
Niranjana


    + */
    +struct drm_i915_gem_vm_bind {
    +       /** VA start to bind **/
    +       __u64 start;
    +
    +       /** Type of memory to [un]bind **/
    +       __u32 type;
    +#define I915_GEM_VM_BIND_SVM_OBJ      0
    +
    +       /** Object handle to [un]bind for I915_GEM_VM_BIND_SVM_OBJ type
    **/
    +       __u32 handle;
    +
    +       /** vm to [un]bind **/
    +       __u32 vm_id;
    +
    +       /** Flags **/
    +       __u32 flags;
    +#define I915_GEM_VM_BIND_UNBIND      (1 << 0)
    +#define I915_GEM_VM_BIND_READONLY    (1 << 1)
    +};
    +
     #if defined(__cplusplus)
     }
     #endif
    --
    2.21.0.rc0.32.g243a4c7e27

    _______________________________________________
    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