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

[Niranjan Vishwanathapura <niranjana.vishwanathapura@intel.com>]

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