RE: [PATCH v4] drm/doc: add rfc section for small BAR uapi
> -Original Message- > From: Tvrtko Ursulin > Sent: Tuesday, May 17, 2022 6:49 AM > To: Auld, Matthew ; intel-...@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org; Thomas Hellström > ; Landwerlin, Lionel G > ; Bloomfield, Jon ; > Daniel Vetter ; Justen, Jordan L > ; Kenneth Graunke ; > Abodunrin, Akeem G ; mesa- > d...@lists.freedesktop.org > Subject: Re: [PATCH v4] drm/doc: add rfc section for small BAR uapi > > > On 17/05/2022 11:52, Matthew Auld wrote: > > Add an entry for the new uapi needed for small BAR on DG2+. > > > > v2: > >- Some spelling fixes and other small tweaks. (Akeem & Thomas) > >- Rework error capture interactions, including no longer needing > > NEEDS_CPU_ACCESS for objects marked for capture. (Thomas) > >- Add probed_cpu_visible_size. (Lionel) > > v3: > >- Drop the vma query for now. > >- Add unallocated_cpu_visible_size as part of the region query. > >- Improve the docs some more, including documenting the expected > > behaviour on older kernels, since this came up in some offline > > discussion. > > v4: > >- Various improvements all over. (Tvrtko) > > You can ignore my previous reply, the clarifications from v4 read good to me. > > Acked-by: Tvrtko Ursulin The patch looks good to me as well... Acked-by: Akeem G Abodunrin > > Regards, > > Tvrtko > > > > > Signed-off-by: Matthew Auld > > Cc: Thomas Hellström > > Cc: Lionel Landwerlin > > Cc: Tvrtko Ursulin > > Cc: Jon Bloomfield > > Cc: Daniel Vetter > > Cc: Jon Bloomfield > > Cc: Jordan Justen > > Cc: Kenneth Graunke > > Cc: Akeem G Abodunrin > > Cc: mesa-dev@lists.freedesktop.org > > --- > > Documentation/gpu/rfc/i915_small_bar.h | 189 > +++ > > Documentation/gpu/rfc/i915_small_bar.rst | 47 ++ > > Documentation/gpu/rfc/index.rst | 4 + > > 3 files changed, 240 insertions(+) > > create mode 100644 Documentation/gpu/rfc/i915_small_bar.h > > create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst > > > > diff --git a/Documentation/gpu/rfc/i915_small_bar.h > > b/Documentation/gpu/rfc/i915_small_bar.h > > new file mode 100644 > > index ..c676640b23ef > > --- /dev/null > > +++ b/Documentation/gpu/rfc/i915_small_bar.h > > @@ -0,0 +1,189 @@ > > +/** > > + * struct __drm_i915_memory_region_info - Describes one region as > > +known to the > > + * driver. > > + * > > + * Note this is using both struct drm_i915_query_item and struct > drm_i915_query. > > + * For this new query we are adding the new query id > > +DRM_I915_QUERY_MEMORY_REGIONS > > + * at _i915_query_item.query_id. > > + */ > > +struct __drm_i915_memory_region_info { > > + /** @region: The class:instance pair encoding */ > > + struct drm_i915_gem_memory_class_instance region; > > + > > + /** @rsvd0: MBZ */ > > + __u32 rsvd0; > > + > > + /** > > +* @probed_size: Memory probed by the driver (-1 = unknown) > > +* > > +* Note that it should not be possible to ever encounter a zero value > > +* here, also note that no current region type will ever return -1 here. > > +* Although for future region types, this might be a possibility. The > > +* same applies to the other size fields. > > +*/ > > + __u64 probed_size; > > + > > + /** > > +* @unallocated_size: Estimate of memory remaining (-1 = unknown) > > +* > > +* Requires CAP_PERFMON or CAP_SYS_ADMIN to get reliable > accounting. > > +* Without this (or if this is an older kernel) the value here will > > +* always equal the @probed_size. Note this is only currently tracked > > +* for I915_MEMORY_CLASS_DEVICE regions (for other types the value > here > > +* will always equal the @probed_size). > > +*/ > > + __u64 unallocated_size; > > + > > + union { > > + /** @rsvd1: MBZ */ > > + __u64 rsvd1[8]; > > + struct { > > + /** > > +* @probed_cpu_visible_size: Memory probed by the > driver > > +* that is CPU accessible. (-1 = unknown). > > +* > > +* This will be always be <= @probed_size, and the > > +* remainder (if there is any) will not be CPU > > +* accessible. > > +* > > +
RE: [PATCH v2] drm/doc: add rfc section for small BAR uapi
> -Original Message- > From: Landwerlin, Lionel G > Sent: Monday, May 2, 2022 12:55 AM > To: Auld, Matthew ; intel-...@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org; Thomas Hellström > ; Bloomfield, Jon > ; Daniel Vetter ; Justen, > Jordan L ; Kenneth Graunke > ; Abodunrin, Akeem G > ; mesa-dev@lists.freedesktop.org > Subject: Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi > > On 20/04/2022 20:13, Matthew Auld wrote: > > Add an entry for the new uapi needed for small BAR on DG2+. > > > > v2: > >- Some spelling fixes and other small tweaks. (Akeem & Thomas) > >- Rework error capture interactions, including no longer needing > > NEEDS_CPU_ACCESS for objects marked for capture. (Thomas) > >- Add probed_cpu_visible_size. (Lionel) > > > > Signed-off-by: Matthew Auld > > Cc: Thomas Hellström > > Cc: Lionel Landwerlin > > Cc: Jon Bloomfield > > Cc: Daniel Vetter > > Cc: Jordan Justen > > Cc: Kenneth Graunke > > Cc: Akeem G Abodunrin > > Cc: mesa-dev@lists.freedesktop.org > > --- > > Documentation/gpu/rfc/i915_small_bar.h | 190 > +++ > > Documentation/gpu/rfc/i915_small_bar.rst | 58 +++ > > Documentation/gpu/rfc/index.rst | 4 + > > 3 files changed, 252 insertions(+) > > create mode 100644 Documentation/gpu/rfc/i915_small_bar.h > > create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst > > > > diff --git a/Documentation/gpu/rfc/i915_small_bar.h > > b/Documentation/gpu/rfc/i915_small_bar.h > > new file mode 100644 > > index ..7bfd0cf44d35 > > --- /dev/null > > +++ b/Documentation/gpu/rfc/i915_small_bar.h > > @@ -0,0 +1,190 @@ > > +/** > > + * struct __drm_i915_memory_region_info - Describes one region as > > +known to the > > + * driver. > > + * > > + * Note this is using both struct drm_i915_query_item and struct > drm_i915_query. > > + * For this new query we are adding the new query id > > +DRM_I915_QUERY_MEMORY_REGIONS > > + * at _i915_query_item.query_id. > > + */ > > +struct __drm_i915_memory_region_info { > > + /** @region: The class:instance pair encoding */ > > + struct drm_i915_gem_memory_class_instance region; > > + > > + /** @rsvd0: MBZ */ > > + __u32 rsvd0; > > + > > + /** @probed_size: Memory probed by the driver (-1 = unknown) */ > > + __u64 probed_size; > > + > > + /** @unallocated_size: Estimate of memory remaining (-1 = unknown) > */ > > + __u64 unallocated_size; > > + > > + union { > > + /** @rsvd1: MBZ */ > > + __u64 rsvd1[8]; > > + struct { > > + /** > > +* @probed_cpu_visible_size: Memory probed by the > driver > > +* that is CPU accessible. (-1 = unknown). > > +* > > +* This will be always be <= @probed_size, and the > > +* remainder(if there is any) will not be CPU > > +* accessible. > > +*/ > > + __u64 probed_cpu_visible_size; > > + }; > > > Trying to implement userspace support in Vulkan for this, I have an additional > question about the value of probed_cpu_visible_size. > > When is it set to -1? I believe it is set to -1 if it is unknown, and/or not cpu accessible... Cheers! ~Akeem > > I'm guessing before there is support for this value it'll be 0 (MBZ). > > After after it should either be the entire lmem or something smaller. > > > -Lionel > > > > + }; > > +}; > > + > > +/** > > + * struct __drm_i915_gem_create_ext - Existing gem_create behaviour, > > +with added > > + * extension support using struct i915_user_extension. > > + * > > + * Note that new buffer flags should be added here, at least for the > > +stuff that > > + * is immutable. Previously we would have two ioctls, one to create > > +the object > > + * with gem_create, and another to apply various parameters, however > > +this > > + * creates some ambiguity for the params which are considered > > +immutable. Also in > > + * general we're phasing out the various SET/GET ioctls. > > + */ > > +struct __drm_i915_gem_create_ext { > > + /** > > +* @size: Requested size for the object. > > +* > > +* The (page-aligned) allocated size for the object will be returned. &g
RE: [PATCH 2/2] drm/doc: add rfc section for small BAR uapi
> -Original Message- > From: dri-devel On Behalf Of > Thomas Hellström > Sent: Tuesday, February 22, 2022 2:36 AM > To: Auld, Matthew ; intel-...@lists.freedesktop.org > Cc: Daniel Vetter ; dri-de...@lists.freedesktop.org; > Kenneth Graunke ; Bloomfield, Jon > ; Justen, Jordan L ; > mesa-dev@lists.freedesktop.org > Subject: Re: [PATCH 2/2] drm/doc: add rfc section for small BAR uapi > > > On 2/18/22 12:22, Matthew Auld wrote: > > Add an entry for the new uapi needed for small BAR on DG2+. > > > > Signed-off-by: Matthew Auld > > Cc: Thomas Hellström > > Cc: Jon Bloomfield > > Cc: Daniel Vetter > > Cc: Jordan Justen > > Cc: Kenneth Graunke > > Cc: mesa-dev@lists.freedesktop.org > > --- > > Documentation/gpu/rfc/i915_small_bar.h | 153 > +++ > > Documentation/gpu/rfc/i915_small_bar.rst | 40 ++ > > Documentation/gpu/rfc/index.rst | 4 + > > 3 files changed, 197 insertions(+) > > create mode 100644 Documentation/gpu/rfc/i915_small_bar.h > > create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst > > > > diff --git a/Documentation/gpu/rfc/i915_small_bar.h > > b/Documentation/gpu/rfc/i915_small_bar.h > > new file mode 100644 > > index ..fa65835fd608 > > --- /dev/null > > +++ b/Documentation/gpu/rfc/i915_small_bar.h > > @@ -0,0 +1,153 @@ > > +/** > > + * struct __drm_i915_gem_create_ext - Existing gem_create behaviour, > > +with added > > + * extension support using struct i915_user_extension. > > + * > > + * Note that in the future we want to have our buffer flags here, > > Does this sentence need updating, with the flags member? > > > > at least for > > + * the stuff that is immutable. Previously we would have two ioctls, > > +one to > > + * create the object with gem_create, and another to apply various > > +parameters, > > + * however this creates some ambiguity for the params which are > > +considered > > + * immutable. Also in general we're phasing out the various SET/GET ioctls. > > + */ > > +struct __drm_i915_gem_create_ext { > > + /** > > +* @size: Requested size for the object. > > +* > > +* The (page-aligned) allocated size for the object will be returned. > > +* > > +* Note that for some devices we have might have further minimum > > +* page-size restrictions(larger than 4K), like for device local-memory. > > +* However in general the final size here should always reflect any > > +* rounding up, if for example using the > I915_GEM_CREATE_EXT_MEMORY_REGIONS > > +* extension to place the object in device local-memory. > > +*/ > > + __u64 size; > > + /** > > +* @handle: Returned handle for the object. > > +* > > +* Object handles are nonzero. > > +*/ > > + __u32 handle; > > + /** > > +* @flags: Optional flags. > > +* > > +* Supported values: > > +* > > +* I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the > kernel that > > +* the object will need to be accessed via the CPU. > > +* > > +* Only valid when placing objects in I915_MEMORY_CLASS_DEVICE, > and > > +* only strictly required on platforms where only some of the device > > +* memory is directly visible or mappable through the CPU, like on DG2+. > > +* > > +* One of the placements MUST also be I915_MEMORY_CLASS_SYSTEM, > to > > +* ensure we can always spill the allocation to system memory, if we > > +* can't place the object in the mappable part of > > +* I915_MEMORY_CLASS_DEVICE. > > +* > > +* Note that buffers that need to be captured with > EXEC_OBJECT_CAPTURE, > > +* will need to enable this hint, if the object can also be placed in > > +* I915_MEMORY_CLASS_DEVICE, starting from DG2+. The execbuf call > will > > +* throw an error otherwise. This also means that such objects will need > > +* I915_MEMORY_CLASS_SYSTEM set as a possible placement. > > +* > > +* Without this hint, the kernel will assume that non-mappable > > +* I915_MEMORY_CLASS_DEVICE is preferred for this object. Note that > the > > +* kernel can still migrate the object to the mappable part, as a last > > +* resort, if userspace ever CPU faults this object, but this might be > > +* expensive, and so ideally should be avoided. > > +*/ > > +#define I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS (1 << 0) > > + __u32 flags; > > + /** > > +* @extensions: The chain of extensions to apply to this object. > > +* > > +* This will be useful in the future when we need to support several > > +* different extensions, and we need to apply more than one when > > +* creating the object. See struct i915_user_extension. > > +* > > +* If we don't supply any extensions then we get the same old > gem_create > > +* behaviour. > > +* > > +* For I915_GEM_CREATE_EXT_MEMORY_REGIONS usage see > > +* struct drm_i915_gem_create_ext_memory_regions. > > +* > > +* For