All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Cc: "Rob Clark" <robdclark@chromium.org>,
	"Daniel Stone" <daniels@collabora.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
	"Kevin Wang" <kevin1.wang@amd.com>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"moderated list:DMA BUFFER SHARING FRAMEWORK"
	<linaro-mm-sig@lists.linaro.org>,
	"Luben Tuikov" <luben.tuikov@amd.com>,
	"Kristian H . Kristensen" <hoegsberg@google.com>,
	"Chen Li" <chenli@uniontech.com>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	mesa-dev <mesa-dev@lists.freedesktop.org>,
	"Michel Dänzer" <michel@daenzer.net>,
	"Dennis Li" <Dennis.Li@amd.com>,
	"Deepak R Varma" <mh12gx2825@gmail.com>
Subject: Re: [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
Date: Fri, 21 May 2021 17:16:26 +0200	[thread overview]
Message-ID: <YKfOymXrB7O4cYVb@phenom.ffwll.local> (raw)
In-Reply-To: <CAP+8YyG0o58dQt_tvnJ2ESbeqo02xxvFdifpMwnhz2VYNk8HUw@mail.gmail.com>

On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote:
> On Fri, May 21, 2021 at 4:37 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote:
> > > On Fri, May 21, 2021 at 11:10 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > ---
> > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > > index 88a24a0b5691..cc8426e1e8a8 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > > @@ -617,8 +617,8 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
> > > >         amdgpu_bo_list_for_each_entry(e, p->bo_list) {
> > > >                 struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo);
> > > >
> > > > -               /* Make sure we use the exclusive slot for shared BOs */
> > > > -               if (bo->prime_shared_count)
> > > > +               /* Make sure we use the exclusive slot for all potentially shared BOs */
> > > > +               if (!(bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID))
> > > >                         e->tv.num_shared = 0;
> > >
> > > I think it also makes sense to skip this with
> > > AMDGPU_GEM_CREATE_EXPLICIT_SYNC? It can be shared but I don't think
> > > anyone expects implicit sync to happen with those.
> >
> > Ah yes, I missed this entirely. So the "no implicit flag" is already
> > there, and the _only_ thing that's missing really is a way to fish out the
> > implicit fences, and set them.
> >
> > https://lore.kernel.org/dri-devel/20210520190007.534046-1-jason@jlekstrand.net/
> >
> > So I think all that's really needed in radv is not setting
> > RADEON_FLAG_IMPLICIT_SYNC for winsys buffers when Jason's dma-buf ioctl
> > are present (means you need to do some import/export and keep the fd
> > around for winsys buffers, but shouldn't be too bad), and then control the
> > implicit fences entirely explicitly like vk expects.
> 
> That is the part I'm less sure about. This is a BO wide flag so we are
> also disabling implicit sync in the compositor. If the compositor does
> only do read stuff that is ok, as the inserted exclusive fence will
> work for that. But as I learned recently the app provided buffer may
> end up being written to by the X server which open a whole can of
> potential problems if implicit sync gets disabled between Xserver
> operations on the app provided buffer. Hence setting that on the WSI
> buffer is a whole new can of potential problems and hence I've said a
> submission based flag would be preferred.
> 
> I can certainly try it out though.

Hm yeah that's the wrong flag. We need a flag on the drm_file which the
explicit userspace sets. And which is valid only for itself.

There's a nice flags field when creating a ctx, but it's not validated and
there's already a comment that we have to filter out garbage priority, so
that's not use. I'll whip up something entirely untested just as a draft.
-Daniel



> 
> >
> > Are you bored enough to type this up for radv? I'll give Jason's kernel
> > stuff another review meanwhile.
> > -Daniel
> >
> > > >                 e->bo_va = amdgpu_vm_bo_find(vm, bo);
> > > >         }
> > > > --
> > > > 2.31.0
> > > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Cc: "Rob Clark" <robdclark@chromium.org>,
	"Daniel Stone" <daniels@collabora.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
	"Kevin Wang" <kevin1.wang@amd.com>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"moderated list:DMA BUFFER SHARING FRAMEWORK"
	<linaro-mm-sig@lists.linaro.org>,
	"Luben Tuikov" <luben.tuikov@amd.com>,
	"Kristian H . Kristensen" <hoegsberg@google.com>,
	"Chen Li" <chenli@uniontech.com>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	mesa-dev <mesa-dev@lists.freedesktop.org>,
	"Michel Dänzer" <michel@daenzer.net>,
	"Dennis Li" <Dennis.Li@amd.com>,
	"Deepak R Varma" <mh12gx2825@gmail.com>
Subject: Re: [Intel-gfx] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
Date: Fri, 21 May 2021 17:16:26 +0200	[thread overview]
Message-ID: <YKfOymXrB7O4cYVb@phenom.ffwll.local> (raw)
In-Reply-To: <CAP+8YyG0o58dQt_tvnJ2ESbeqo02xxvFdifpMwnhz2VYNk8HUw@mail.gmail.com>

On Fri, May 21, 2021 at 05:00:46PM +0200, Bas Nieuwenhuizen wrote:
> On Fri, May 21, 2021 at 4:37 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Fri, May 21, 2021 at 11:46:23AM +0200, Bas Nieuwenhuizen wrote:
> > > On Fri, May 21, 2021 at 11:10 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > ---
> > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > > index 88a24a0b5691..cc8426e1e8a8 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > > > @@ -617,8 +617,8 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
> > > >         amdgpu_bo_list_for_each_entry(e, p->bo_list) {
> > > >                 struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo);
> > > >
> > > > -               /* Make sure we use the exclusive slot for shared BOs */
> > > > -               if (bo->prime_shared_count)
> > > > +               /* Make sure we use the exclusive slot for all potentially shared BOs */
> > > > +               if (!(bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID))
> > > >                         e->tv.num_shared = 0;
> > >
> > > I think it also makes sense to skip this with
> > > AMDGPU_GEM_CREATE_EXPLICIT_SYNC? It can be shared but I don't think
> > > anyone expects implicit sync to happen with those.
> >
> > Ah yes, I missed this entirely. So the "no implicit flag" is already
> > there, and the _only_ thing that's missing really is a way to fish out the
> > implicit fences, and set them.
> >
> > https://lore.kernel.org/dri-devel/20210520190007.534046-1-jason@jlekstrand.net/
> >
> > So I think all that's really needed in radv is not setting
> > RADEON_FLAG_IMPLICIT_SYNC for winsys buffers when Jason's dma-buf ioctl
> > are present (means you need to do some import/export and keep the fd
> > around for winsys buffers, but shouldn't be too bad), and then control the
> > implicit fences entirely explicitly like vk expects.
> 
> That is the part I'm less sure about. This is a BO wide flag so we are
> also disabling implicit sync in the compositor. If the compositor does
> only do read stuff that is ok, as the inserted exclusive fence will
> work for that. But as I learned recently the app provided buffer may
> end up being written to by the X server which open a whole can of
> potential problems if implicit sync gets disabled between Xserver
> operations on the app provided buffer. Hence setting that on the WSI
> buffer is a whole new can of potential problems and hence I've said a
> submission based flag would be preferred.
> 
> I can certainly try it out though.

Hm yeah that's the wrong flag. We need a flag on the drm_file which the
explicit userspace sets. And which is valid only for itself.

There's a nice flags field when creating a ctx, but it's not validated and
there's already a comment that we have to filter out garbage priority, so
that's not use. I'll whip up something entirely untested just as a draft.
-Daniel



> 
> >
> > Are you bored enough to type this up for radv? I'll give Jason's kernel
> > stuff another review meanwhile.
> > -Daniel
> >
> > > >                 e->bo_va = amdgpu_vm_bo_find(vm, bo);
> > > >         }
> > > > --
> > > > 2.31.0
> > > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-05-21 15:16 UTC|newest]

Thread overview: 175+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21  9:09 [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules Daniel Vetter
2021-05-21  9:09 ` [Intel-gfx] " Daniel Vetter
2021-05-21  9:09 ` [PATCH 02/11] drm/panfrost: Remove sched_lock Daniel Vetter
2021-05-21  9:09   ` [Intel-gfx] " Daniel Vetter
2021-05-21  9:32   ` Lucas Stach
2021-05-21  9:32     ` [Intel-gfx] " Lucas Stach
2021-05-21 14:49     ` Daniel Vetter
2021-05-21 14:49       ` [Intel-gfx] " Daniel Vetter
2021-05-21  9:09 ` [PATCH 03/11] drm/panfrost: Use xarray and helpers for depedency tracking Daniel Vetter
2021-05-21  9:09   ` [Intel-gfx] " Daniel Vetter
2021-05-21  9:09   ` Daniel Vetter
2021-06-02 14:06   ` Steven Price
2021-06-02 14:06     ` [Intel-gfx] " Steven Price
2021-06-02 14:06     ` Steven Price
2021-06-02 18:51     ` Daniel Vetter
2021-06-02 18:51       ` [Intel-gfx] " Daniel Vetter
2021-06-02 18:51       ` Daniel Vetter
2021-06-03  7:48       ` Steven Price
2021-06-03  7:48         ` [Intel-gfx] " Steven Price
2021-06-03  7:48         ` Steven Price
2021-05-21  9:09 ` [PATCH 04/11] drm/panfrost: Fix implicit sync Daniel Vetter
2021-05-21  9:09   ` [Intel-gfx] " Daniel Vetter
2021-05-21  9:09   ` Daniel Vetter
2021-05-21 12:22   ` Daniel Stone
2021-05-21 12:22     ` [Intel-gfx] " Daniel Stone
2021-05-21 12:22     ` Daniel Stone
2021-05-21 12:28     ` [Linaro-mm-sig] " Christian König
2021-05-21 12:28       ` [Intel-gfx] " Christian König
2021-05-21 12:54       ` Daniel Stone
2021-05-21 12:54         ` [Intel-gfx] " Daniel Stone
2021-05-21 12:54         ` Daniel Stone
2021-05-21 13:09         ` Christian König
2021-05-21 13:09           ` [Intel-gfx] " Christian König
2021-05-21 13:09           ` Christian König
2021-05-21 13:23           ` Daniel Stone
2021-05-21 13:23             ` [Intel-gfx] " Daniel Stone
2021-05-21 13:23             ` Daniel Stone
2021-05-21  9:09 ` [PATCH 05/11] drm/atomic-helper: make drm_gem_plane_helper_prepare_fb the default Daniel Vetter
2021-05-21  9:09   ` [Intel-gfx] " Daniel Vetter
2021-05-21  9:09 ` [PATCH 06/11] drm/<driver>: drm_gem_plane_helper_prepare_fb is now " Daniel Vetter
2021-05-21  9:09   ` Daniel Vetter
2021-05-21  9:09   ` [Intel-gfx] " Daniel Vetter
2021-05-21  9:09   ` Daniel Vetter
2021-05-21  9:09   ` Daniel Vetter
2021-05-21  9:09   ` Daniel Vetter
2021-05-21  9:09   ` Daniel Vetter
2021-05-21  9:38   ` Lucas Stach
2021-05-21  9:38     ` Lucas Stach
2021-05-21  9:38     ` [Intel-gfx] " Lucas Stach
2021-05-21  9:38     ` Lucas Stach
2021-05-21  9:38     ` Lucas Stach
2021-05-21  9:38     ` Lucas Stach
2021-05-21  9:38     ` Lucas Stach
2021-05-21 12:20   ` Heiko Stübner
2021-05-21 12:20     ` Heiko Stübner
2021-05-21 12:20     ` [Intel-gfx] " Heiko Stübner
2021-05-21 12:20     ` Heiko Stübner
2021-05-21 12:20     ` Heiko Stübner
2021-05-21 12:20     ` Heiko Stübner
2021-05-21 12:20     ` Heiko Stübner
2021-05-21 12:22   ` Paul Cercueil
2021-05-21 12:22     ` Paul Cercueil
2021-05-21 12:22     ` [Intel-gfx] " Paul Cercueil
2021-05-21 12:22     ` Paul Cercueil
2021-05-21 12:22     ` Paul Cercueil
2021-05-21 12:22     ` Paul Cercueil
2021-05-21 12:22     ` Paul Cercueil
2021-05-21 15:53   ` Jernej Škrabec
2021-05-21 15:53     ` Jernej Škrabec
2021-05-21 15:53     ` [Intel-gfx] " Jernej Škrabec
2021-05-21 15:53     ` Jernej Škrabec
2021-05-21 15:53     ` Jernej Škrabec
2021-05-21 15:53     ` Jernej Škrabec
2021-05-21 15:53     ` Jernej Škrabec
2021-05-21 23:18   ` Chun-Kuang Hu
2021-05-21 23:18     ` Chun-Kuang Hu
2021-05-21 23:18     ` [Intel-gfx] " Chun-Kuang Hu
2021-05-21 23:18     ` Chun-Kuang Hu
2021-05-21 23:18     ` Chun-Kuang Hu
2021-05-21 23:18     ` Chun-Kuang Hu
2021-05-21 23:18     ` Chun-Kuang Hu
2021-05-23 12:17   ` Martin Blumenstingl
2021-05-23 12:17     ` Martin Blumenstingl
2021-05-23 12:17     ` [Intel-gfx] " Martin Blumenstingl
2021-05-23 12:17     ` Martin Blumenstingl
2021-05-23 12:17     ` Martin Blumenstingl
2021-05-23 12:17     ` Martin Blumenstingl
2021-05-23 12:17     ` Martin Blumenstingl
2021-05-24  7:54   ` Tomi Valkeinen
2021-05-24  7:54     ` Tomi Valkeinen
2021-05-24  7:54     ` [Intel-gfx] " Tomi Valkeinen
2021-05-24  7:54     ` Tomi Valkeinen
2021-05-24  7:54     ` Tomi Valkeinen
2021-05-24  7:54     ` Tomi Valkeinen
2021-05-24  7:54     ` Tomi Valkeinen
2021-05-28  9:55   ` Philippe CORNU
2021-05-28  9:55     ` Philippe CORNU
2021-05-28  9:55     ` [Intel-gfx] " Philippe CORNU
2021-05-28  9:55     ` Philippe CORNU
2021-05-28  9:55     ` Philippe CORNU
2021-05-28  9:55     ` Philippe CORNU
2021-05-28  9:55     ` Philippe CORNU
2021-05-21  9:09 ` [PATCH 07/11] drm/armada: Remove prepare/cleanup_fb hooks Daniel Vetter
2021-05-21  9:09   ` [Intel-gfx] " Daniel Vetter
2021-05-21  9:09 ` [PATCH 08/11] drm/vram-helpers: Create DRM_GEM_VRAM_PLANE_HELPER_FUNCS Daniel Vetter
2021-05-21  9:09   ` [Intel-gfx] " Daniel Vetter
2021-05-21  9:33   ` tiantao (H)
2021-05-21  9:33     ` [Intel-gfx] " tiantao (H)
2021-05-21  9:09 ` [PATCH 09/11] drm/omap: Follow implicit fencing in prepare_fb Daniel Vetter
2021-05-21  9:09   ` [Intel-gfx] " Daniel Vetter
2021-05-24  7:53   ` Tomi Valkeinen
2021-05-24  7:53     ` [Intel-gfx] " Tomi Valkeinen
2021-05-21  9:09 ` [PATCH 10/11] drm/simple-helper: drm_gem_simple_display_pipe_prepare_fb as default Daniel Vetter
2021-05-21  9:09   ` [Intel-gfx] " Daniel Vetter
2021-05-25 17:48   ` Noralf Trønnes
2021-05-25 17:48     ` [Intel-gfx] " Noralf Trønnes
2021-05-25 17:53     ` Daniel Vetter
2021-05-25 17:53       ` [Intel-gfx] " Daniel Vetter
2021-05-21  9:09 ` [PATCH 11/11] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default Daniel Vetter
2021-05-21  9:09   ` Daniel Vetter
2021-05-21  9:09   ` [Intel-gfx] " Daniel Vetter
2021-05-21  9:09   ` Daniel Vetter
2021-05-21 13:41   ` David Lechner
2021-05-21 13:41     ` David Lechner
2021-05-21 13:41     ` [Intel-gfx] " David Lechner
2021-05-21 13:41     ` David Lechner
2021-05-21 14:09   ` Noralf Trønnes
2021-05-21 14:09     ` Noralf Trønnes
2021-05-21 14:09     ` [Intel-gfx] " Noralf Trønnes
2021-05-21 14:09     ` Noralf Trønnes
2021-05-25 16:05     ` Daniel Vetter
2021-05-25 16:05       ` Daniel Vetter
2021-05-25 16:05       ` [Intel-gfx] " Daniel Vetter
2021-05-25 16:05       ` Daniel Vetter
2021-05-21 14:13   ` Oleksandr Andrushchenko
2021-05-21 14:13     ` Oleksandr Andrushchenko
2021-05-21 14:13     ` [Intel-gfx] " Oleksandr Andrushchenko
2021-05-21 14:13     ` Oleksandr Andrushchenko
2021-05-28  0:38   ` Linus Walleij
2021-05-28  0:38     ` Linus Walleij
2021-05-28  0:38     ` [Intel-gfx] " Linus Walleij
2021-05-28  0:38     ` Linus Walleij
2021-05-21  9:18 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/amdgpu: Comply with implicit fencing rules Patchwork
2021-05-21  9:20 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-05-21  9:45 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-05-21  9:46 ` [PATCH 01/11] " Bas Nieuwenhuizen
2021-05-21  9:46   ` [Intel-gfx] " Bas Nieuwenhuizen
2021-05-21 14:37   ` Daniel Vetter
2021-05-21 14:37     ` [Intel-gfx] " Daniel Vetter
2021-05-21 15:00     ` Bas Nieuwenhuizen
2021-05-21 15:00       ` [Intel-gfx] " Bas Nieuwenhuizen
2021-05-21 15:16       ` Daniel Vetter [this message]
2021-05-21 15:16         ` Daniel Vetter
2021-05-21 18:08         ` [Mesa-dev] " Christian König
2021-05-21 18:08           ` [Intel-gfx] " Christian König
2021-05-21 18:31           ` Daniel Vetter
2021-05-21 18:31             ` [Intel-gfx] " Daniel Vetter
2021-05-22  8:30             ` Christian König
2021-05-22  8:30               ` [Intel-gfx] " Christian König
2021-05-25 13:05               ` Daniel Vetter
2021-05-25 13:05                 ` [Intel-gfx] " Daniel Vetter
2021-05-25 15:05                 ` Christian König
2021-05-25 15:23                   ` Daniel Vetter
2021-05-25 15:23                     ` [Intel-gfx] " Daniel Vetter
2021-05-26 13:32                     ` Christian König
2021-05-26 13:32                       ` [Intel-gfx] " Christian König
2021-05-26 13:51                       ` Daniel Vetter
2021-05-26 13:51                         ` [Intel-gfx] " Daniel Vetter
2021-05-21 11:22 ` Christian König
2021-05-21 11:22   ` [Intel-gfx] " Christian König
2021-05-21 14:58 ` [Mesa-dev] " Rob Clark
2021-05-21 14:58   ` [Intel-gfx] " Rob Clark
2021-05-21 14:58   ` Daniel Vetter
2021-05-21 14:58     ` [Intel-gfx] " Daniel Vetter
2021-05-23  5:00 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/11] " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YKfOymXrB7O4cYVb@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=Dennis.Li@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=bas@basnieuwenhuizen.nl \
    --cc=chenli@uniontech.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hoegsberg@google.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kevin1.wang@amd.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=luben.tuikov@amd.com \
    --cc=mesa-dev@lists.freedesktop.org \
    --cc=mh12gx2825@gmail.com \
    --cc=michel@daenzer.net \
    --cc=robdclark@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.