Re: Amber branch plan

2022-02-22 Thread Adam Jackson
At the moment 21.3.8 is the last planned Mesa 21.3.Z. So I kind of
imagine 21.3.9 being the first "amber-only" release where we flip the
meson option for amber to true by default, and we'd keep that branch
going for as long as people want to keep it compiling and fixing bugs
in it.

- ajax

On Fri, Feb 18, 2022 at 6:35 AM Timo Aaltonen  wrote:
>
> Dylan Baker kirjoitti 7.12.2021 klo 1.51:
> > Since classic is gone,  I thought I'd lay out my thinking for Amber.
> >
> > I'm assuming that we'll branch Amber from the 21.3 branch, after that
> > reaches normal EOL. That gives us the benefit of developing on top of a
> > known good state for classic drivers, and should minimize friction for
> > distros dealing with classic. If anyone wants to backport changes from
> > main to amber they can obviously do so.
> >
> > Are there any objections to that plan?
> >
> > Dylan
>
> Is there going to be a separate tarball release of Amber?
>
>
> --
> t
>



RE: [PATCH 2/2] drm/doc: add rfc section for small BAR uapi

2022-02-22 Thread Abodunrin, Akeem G


> -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 I915_GEM_CREATE_EXT_PROTECT