Re: Converting mesa/demos to Meson
OK, so I think enough time has passed. I have heard a few voices in support, and no voices against, so my plan is to go ahead and merge this early next week (probably Monday), if I don't hear anyone speak up soon. On Wed, 2022-05-04 at 18:38 +0200, Erik Faye-Lund wrote: > Because we've landed on using Meson in the main Mesa repository, I've > been working on converting the mesa/demos repo to Meson as well. > > I've posted an MR here: > https://gitlab.freedesktop.org/mesa/demos/-/merge_requests/60 > > This MR adds a new Meson build system to the repository, and marks > the > Autotools and CMake build systems as deprecated, similar to what we > did > for the Autotools and SCons build systems in Mesa when we > transitioned. > > After this lands, I propose that we cut a new release (we really > should > cut a new release soon anyway), then wait for a while and fix up any > problems found, and finally rip ot the old build systems. > > After removing the old build systems, we end up with this total code > reduction: > > 112 files changed, 1642 insertions(+), 4744 deletions(-) > > The removal commit is here, BTW: > https://gitlab.freedesktop.org/kusma/mesa-demos/-/commits/remove-old-buildsystems > > Thoughts? Objections? > -- Erik Faye-Lund Principal Engineer Collabora Ltd. Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, United Kingdom Registered in England & Wales, no. 5513718
Re: [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
On 02/05/2022 17:15, Ramalingam C wrote:
Capture the impact of memory region preference list of the objects, on
their memory residency and Flat-CCS capability.
v2:
Fix the Flat-CCS capability of an obj with {lmem, smem} preference
list [Thomas]
v3:
Reworded the doc [Matt]
Signed-off-by: Ramalingam C
cc: Matthew Auld
cc: Thomas Hellstrom
cc: Daniel Vetter
cc: Jon Bloomfield
cc: Lionel Landwerlin
cc: Kenneth Graunke
cc: mesa-dev@lists.freedesktop.org
cc: Jordan Justen
cc: Tony Ye
Reviewed-by: Matthew Auld
---
include/uapi/drm/i915_drm.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index a2def7b27009..b7e1c2fe08dc 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3443,6 +3443,22 @@ struct drm_i915_gem_create_ext {
* At which point we get the object handle in &drm_i915_gem_create_ext.handle,
* along with the final object size in &drm_i915_gem_create_ext.size, which
* should account for any rounding up, if required.
+ *
+ * Note that userspace has no means of knowing the current backing region
+ * for objects where @num_regions is larger than one. The kernel will only
+ * ensure that the priority order of the @regions array is honoured, either
+ * when initially placing the object, or when moving memory around due to
+ * memory pressure
+ *
+ * On Flat-CCS capable HW, compression is supported for the objects residing
+ * in I915_MEMORY_CLASS_DEVICE. When such objects (compressed) has other
+ * memory class in @regions and migrated (by I915, due to memory
+ * constrain) to the non I915_MEMORY_CLASS_DEVICE region, then I915 needs to
+ * decompress the content. But I915 dosen't have the required information to
+ * decompress the userspace compressed objects.
+ *
+ * So I915 supports Flat-CCS, only on the objects which can reside only on
+ * I915_MEMORY_CLASS_DEVICE regions.
I think it's fine to assume Flat-CSS surface will always be in lmem.
I see no issue for the Anv Vulkan driver.
Maybe Nanley or Ken can speak for the Iris GL driver?
-Lionel
*/
struct drm_i915_gem_create_ext_memory_regions {
/** @base: Extension link. See struct i915_user_extension. */
Re: [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
On 2022-05-13 05:31:00, Lionel Landwerlin wrote:
> On 02/05/2022 17:15, Ramalingam C wrote:
> > Capture the impact of memory region preference list of the objects, on
> > their memory residency and Flat-CCS capability.
> >
> > v2:
> >Fix the Flat-CCS capability of an obj with {lmem, smem} preference
> >list [Thomas]
> > v3:
> >Reworded the doc [Matt]
> >
> > Signed-off-by: Ramalingam C
> > cc: Matthew Auld
> > cc: Thomas Hellstrom
> > cc: Daniel Vetter
> > cc: Jon Bloomfield
> > cc: Lionel Landwerlin
> > cc: Kenneth Graunke
> > cc: mesa-dev@lists.freedesktop.org
> > cc: Jordan Justen
> > cc: Tony Ye
> > Reviewed-by: Matthew Auld
> > ---
> > include/uapi/drm/i915_drm.h | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index a2def7b27009..b7e1c2fe08dc 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -3443,6 +3443,22 @@ struct drm_i915_gem_create_ext {
> >* At which point we get the object handle in
> > &drm_i915_gem_create_ext.handle,
> >* along with the final object size in &drm_i915_gem_create_ext.size,
> > which
> >* should account for any rounding up, if required.
> > + *
> > + * Note that userspace has no means of knowing the current backing region
> > + * for objects where @num_regions is larger than one. The kernel will only
> > + * ensure that the priority order of the @regions array is honoured, either
> > + * when initially placing the object, or when moving memory around due to
> > + * memory pressure
> > + *
> > + * On Flat-CCS capable HW, compression is supported for the objects
> > residing
> > + * in I915_MEMORY_CLASS_DEVICE. When such objects (compressed) has other
> > + * memory class in @regions and migrated (by I915, due to memory
> > + * constrain) to the non I915_MEMORY_CLASS_DEVICE region, then I915 needs
> > to
> > + * decompress the content. But I915 dosen't have the required information
> > to
> > + * decompress the userspace compressed objects.
> > + *
> > + * So I915 supports Flat-CCS, only on the objects which can reside only on
> > + * I915_MEMORY_CLASS_DEVICE regions.
>
> I think it's fine to assume Flat-CSS surface will always be in lmem.
>
> I see no issue for the Anv Vulkan driver.
>
> Maybe Nanley or Ken can speak for the Iris GL driver?
>
Acked-by: Jordan Justen
I think Nanley has accounted for this on iris with:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/42a865730ef72574e179b56a314f30fdccc6cba8
-Jordan
