All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Stone <daniel@fooishbar.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Rob Clark" <robdclark@chromium.org>,
	"Daniel Stone" <daniels@collabora.com>,
	"Michel Dänzer" <michel@daenzer.net>,
	"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
	"Kevin Wang" <kevin1.wang@amd.com>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"Christian König" <christian.koenig@amd.com>,
	"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>,
	"ML mesa-dev" <mesa-dev@lists.freedesktop.org>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Dennis Li" <Dennis.Li@amd.com>,
	"Deepak R Varma" <mh12gx2825@gmail.com>
Subject: Re: [Mesa-dev] [PATCH] dma-buf: Document dma-buf implicit fencing/resv fencing rules
Date: Thu, 24 Jun 2021 12:08:11 +0100	[thread overview]
Message-ID: <CAPj87rN_P7u5JGWBOHc5BEXiz1Znek6fDTyj-uVr2nwEcGX_XA@mail.gmail.com> (raw)
In-Reply-To: <20210623161955.3371466-1-daniel.vetter@ffwll.ch>

Hi,

On Wed, 23 Jun 2021 at 17:20, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> +        *
> +        * IMPLICIT SYNCHRONIZATION RULES:
> +        *
> +        * Drivers which support implicit synchronization of buffer access as
> +        * e.g. exposed in `Implicit Fence Poll Support`_ should follow the
> +        * below rules.

'Should' ... ? Must.

> +        * - Drivers should add a shared fence through
> +        *   dma_resv_add_shared_fence() for anything the userspace API
> +        *   considers a read access. This highly depends upon the API and
> +        *   window system: E.g. OpenGL is generally implicitly synchronized on
> +        *   Linux, but explicitly synchronized on Android. Whereas Vulkan is
> +        *   generally explicitly synchronized for everything, and window system
> +        *   buffers have explicit API calls (which then need to make sure the
> +        *   implicit fences store here in @resv are updated correctly).
> +        *
> +        * - [...]

Mmm, I think this is all right, but it could be worded much more
clearly. Right now it's a bunch of points all smashed into one, and
there's a lot of room for misinterpretation.

Here's a strawman, starting with most basic and restrictive, working
through to when you're allowed to wriggle your way out:

Rule 1: Drivers must add a shared fence through
dma_resv_add_shared_fence() for any read accesses against that buffer.
This appends a fence to the shared array, ensuring that any future
non-read access will be synchronised against this operation to only
begin after it has completed.

Rule 2: Drivers must add an exclusive fence through
dma_resv_add_excl_fence() for any write accesses against that buffer.
This replaces the exclusive fence with the new operation, ensuring
that all future access will be synchronised against this operation to
only begin after it has completed.

Rule 3: Drivers must synchronise all accesses to buffers against
existing implicit fences. Read accesses must synchronise against the
exclusive fence (read-after-write), and write accesses must
synchronise against both the exclusive (write-after-write) and shared
(write-after-read) fences.

Note 1: Users like OpenGL and window systems on non-Android userspace
are generally implicitly synchronised. An implicitly-synchronised
userspace is unaware of fences from prior operations, so the kernel
mediates scheduling to create the illusion that GPU work is FIFO. For
example, an application will flush and schedule GPU write work to
render its image, then immediately tell the window system to display
that image; the window system may immediately flush and schedule GPU
read work to display that image, with neither waiting for the write to
have completed. The kernel provides coherence by synchronising the
read access against the write fence in the exclusive slot, so that the
image displayed is correct.

Note 2: Users like Vulkan and Android window system are generally
explicitly synchronised. An explicitly-synchronised userspace is
responsible for tracking its own read and write access and providing
the kernel with synchronisation barriers. For instance, a Vulkan
application rendering to a buffer and subsequently using it as a read
texture, must annotate the read operation with a read-after-write
synchronisation barrier.

Note 3: Implicit and explicit userspace can coexist. For instance, an
explicitly-synchronised Vulkan application may be running as a client
of an implicitly-synchronised window system which uses OpenGL for
composition; an implicitly-synchronised OpenGL application may be
running as a client of a window system which uses Vulkan for
composition.

Note 4: Some subsystems, for example V4L2, do not pipeline operations,
and instead only return to userspace when the scheduled work against a
buffer has fully retired.

Exemption 1: Fully self-coherent userspace may skip implicit
synchronisation barriers. For instance, accesses between two
Vulkan-internal buffers allocated by a single application do not need
to synchronise against each other's implicit fences, as the client is
responsible for explicitly providing barriers for access. A
self-contained OpenGL userspace also has no need to implicitly
synchronise its access if the driver instead tracks all access and
inserts the appropriate synchronisation barriers.

Exemption 2: When implicit and explicit userspace coexist, the
explicit side may skip intermediate synchronisation, and only place
synchronisation barriers at transition points. For example, a Vulkan
compositor displaying a buffer from an OpenGL application would need
to synchronise its first access against the fence placed in the
exclusive implicit-synchronisation slot. Once this read has fully
retired, the compositor has no need to participate in implicit
synchronisation until it is ready to return the buffer to the
application, at which point it must insert all its non-retired
accesses into the shared slot, which the application will then
synchronise future write accesses against.

Cheers,
Daniel

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Stone <daniel@fooishbar.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "Rob Clark" <robdclark@chromium.org>,
	"Daniel Stone" <daniels@collabora.com>,
	"Michel Dänzer" <michel@daenzer.net>,
	"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
	"Kevin Wang" <kevin1.wang@amd.com>,
	"DRI Development" <dri-devel@lists.freedesktop.org>,
	"Christian König" <christian.koenig@amd.com>,
	"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>,
	"ML mesa-dev" <mesa-dev@lists.freedesktop.org>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Dennis Li" <Dennis.Li@amd.com>,
	"Deepak R Varma" <mh12gx2825@gmail.com>
Subject: Re: [Intel-gfx] [Mesa-dev] [PATCH] dma-buf: Document dma-buf implicit fencing/resv fencing rules
Date: Thu, 24 Jun 2021 12:08:11 +0100	[thread overview]
Message-ID: <CAPj87rN_P7u5JGWBOHc5BEXiz1Znek6fDTyj-uVr2nwEcGX_XA@mail.gmail.com> (raw)
In-Reply-To: <20210623161955.3371466-1-daniel.vetter@ffwll.ch>

Hi,

On Wed, 23 Jun 2021 at 17:20, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> +        *
> +        * IMPLICIT SYNCHRONIZATION RULES:
> +        *
> +        * Drivers which support implicit synchronization of buffer access as
> +        * e.g. exposed in `Implicit Fence Poll Support`_ should follow the
> +        * below rules.

'Should' ... ? Must.

> +        * - Drivers should add a shared fence through
> +        *   dma_resv_add_shared_fence() for anything the userspace API
> +        *   considers a read access. This highly depends upon the API and
> +        *   window system: E.g. OpenGL is generally implicitly synchronized on
> +        *   Linux, but explicitly synchronized on Android. Whereas Vulkan is
> +        *   generally explicitly synchronized for everything, and window system
> +        *   buffers have explicit API calls (which then need to make sure the
> +        *   implicit fences store here in @resv are updated correctly).
> +        *
> +        * - [...]

Mmm, I think this is all right, but it could be worded much more
clearly. Right now it's a bunch of points all smashed into one, and
there's a lot of room for misinterpretation.

Here's a strawman, starting with most basic and restrictive, working
through to when you're allowed to wriggle your way out:

Rule 1: Drivers must add a shared fence through
dma_resv_add_shared_fence() for any read accesses against that buffer.
This appends a fence to the shared array, ensuring that any future
non-read access will be synchronised against this operation to only
begin after it has completed.

Rule 2: Drivers must add an exclusive fence through
dma_resv_add_excl_fence() for any write accesses against that buffer.
This replaces the exclusive fence with the new operation, ensuring
that all future access will be synchronised against this operation to
only begin after it has completed.

Rule 3: Drivers must synchronise all accesses to buffers against
existing implicit fences. Read accesses must synchronise against the
exclusive fence (read-after-write), and write accesses must
synchronise against both the exclusive (write-after-write) and shared
(write-after-read) fences.

Note 1: Users like OpenGL and window systems on non-Android userspace
are generally implicitly synchronised. An implicitly-synchronised
userspace is unaware of fences from prior operations, so the kernel
mediates scheduling to create the illusion that GPU work is FIFO. For
example, an application will flush and schedule GPU write work to
render its image, then immediately tell the window system to display
that image; the window system may immediately flush and schedule GPU
read work to display that image, with neither waiting for the write to
have completed. The kernel provides coherence by synchronising the
read access against the write fence in the exclusive slot, so that the
image displayed is correct.

Note 2: Users like Vulkan and Android window system are generally
explicitly synchronised. An explicitly-synchronised userspace is
responsible for tracking its own read and write access and providing
the kernel with synchronisation barriers. For instance, a Vulkan
application rendering to a buffer and subsequently using it as a read
texture, must annotate the read operation with a read-after-write
synchronisation barrier.

Note 3: Implicit and explicit userspace can coexist. For instance, an
explicitly-synchronised Vulkan application may be running as a client
of an implicitly-synchronised window system which uses OpenGL for
composition; an implicitly-synchronised OpenGL application may be
running as a client of a window system which uses Vulkan for
composition.

Note 4: Some subsystems, for example V4L2, do not pipeline operations,
and instead only return to userspace when the scheduled work against a
buffer has fully retired.

Exemption 1: Fully self-coherent userspace may skip implicit
synchronisation barriers. For instance, accesses between two
Vulkan-internal buffers allocated by a single application do not need
to synchronise against each other's implicit fences, as the client is
responsible for explicitly providing barriers for access. A
self-contained OpenGL userspace also has no need to implicitly
synchronise its access if the driver instead tracks all access and
inserts the appropriate synchronisation barriers.

Exemption 2: When implicit and explicit userspace coexist, the
explicit side may skip intermediate synchronisation, and only place
synchronisation barriers at transition points. For example, a Vulkan
compositor displaying a buffer from an OpenGL application would need
to synchronise its first access against the fence placed in the
exclusive implicit-synchronisation slot. Once this read has fully
retired, the compositor has no need to participate in implicit
synchronisation until it is ready to return the buffer to the
application, at which point it must insert all its non-retired
accesses into the shared slot, which the application will then
synchronise future write accesses against.

Cheers,
Daniel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2021-06-24 11:08 UTC|newest]

Thread overview: 175+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-22 16:54 [PATCH 00/15] implicit fencing/dma-resv rules for shared buffers Daniel Vetter
2021-06-22 16:54 ` [Intel-gfx] " Daniel Vetter
2021-06-22 16:54 ` [PATCH 01/15] dma-resv: Fix kerneldoc Daniel Vetter
2021-06-22 16:54   ` [Intel-gfx] " Daniel Vetter
2021-06-22 16:54   ` Daniel Vetter
2021-06-22 18:19   ` Alex Deucher
2021-06-22 18:19     ` [Intel-gfx] " Alex Deucher
2021-06-22 18:19     ` Alex Deucher
2021-06-22 18:49   ` Sam Ravnborg
2021-06-22 18:49     ` [Intel-gfx] " Sam Ravnborg
2021-06-22 19:19     ` Daniel Vetter
2021-06-22 19:19       ` [Intel-gfx] " Daniel Vetter
2021-06-22 19:19       ` Daniel Vetter
2021-06-23  8:31   ` Christian König
2021-06-23  8:31     ` [Intel-gfx] " Christian König
2021-06-23  8:31     ` Christian König
2021-06-23 15:15     ` Daniel Vetter
2021-06-23 15:15       ` [Intel-gfx] " Daniel Vetter
2021-06-23 15:15       ` Daniel Vetter
2021-06-22 16:54 ` [PATCH 02/15] dma-buf: Switch to inline kerneldoc Daniel Vetter
2021-06-22 16:54   ` [Intel-gfx] " Daniel Vetter
2021-06-22 16:54   ` Daniel Vetter
2021-06-22 18:24   ` Alex Deucher
2021-06-22 18:24     ` [Intel-gfx] " Alex Deucher
2021-06-22 18:24     ` Alex Deucher
2021-06-22 19:01   ` Sam Ravnborg
2021-06-22 19:01     ` [Intel-gfx] " Sam Ravnborg
2021-06-22 19:21     ` Daniel Vetter
2021-06-22 19:21       ` [Intel-gfx] " Daniel Vetter
2021-06-22 19:21       ` Daniel Vetter
2021-06-23  8:32   ` Christian König
2021-06-23  8:32     ` [Intel-gfx] " Christian König
2021-06-23  8:32     ` Christian König
2021-06-23 16:17   ` [PATCH] " Daniel Vetter
2021-06-23 16:17     ` [Intel-gfx] " Daniel Vetter
2021-06-23 16:17     ` Daniel Vetter
2021-06-23 17:33     ` Sam Ravnborg
2021-06-23 17:33       ` [Intel-gfx] " Sam Ravnborg
2021-06-22 16:54 ` [PATCH 03/15] dma-buf: Document dma-buf implicit fencing/resv fencing rules Daniel Vetter
2021-06-22 16:54   ` [Intel-gfx] " Daniel Vetter
2021-06-23  8:41   ` Christian König
2021-06-23  8:41     ` [Intel-gfx] " Christian König
2021-06-23 16:19   ` [PATCH] " Daniel Vetter
2021-06-23 16:19     ` [Intel-gfx] " Daniel Vetter
2021-06-24  6:59     ` Dave Airlie
2021-06-24  6:59       ` [Intel-gfx] " Dave Airlie
2021-06-24 11:08     ` Daniel Stone [this message]
2021-06-24 11:08       ` [Intel-gfx] [Mesa-dev] " Daniel Stone
2021-06-24 11:23       ` Daniel Vetter
2021-06-24 11:23         ` [Intel-gfx] " Daniel Vetter
2021-06-24 12:48     ` Daniel Vetter
2021-06-24 12:52     ` Daniel Vetter
2021-06-22 16:55 ` [PATCH 04/15] drm/panfrost: Shrink sched_lock Daniel Vetter
2021-06-22 16:55   ` [Intel-gfx] " Daniel Vetter
2021-06-23 16:52   ` Boris Brezillon
2021-06-23 16:52     ` [Intel-gfx] " Boris Brezillon
2021-06-22 16:55 ` [PATCH 05/15] drm/panfrost: Use xarray and helpers for depedency tracking Daniel Vetter
2021-06-22 16:55   ` [Intel-gfx] " Daniel Vetter
2021-06-22 16:55   ` Daniel Vetter
2021-06-23 16:51   ` Boris Brezillon
2021-06-23 16:51     ` [Intel-gfx] " Boris Brezillon
2021-06-23 16:51     ` Boris Brezillon
2021-06-22 16:55 ` [PATCH 06/15] drm/panfrost: Fix implicit sync Daniel Vetter
2021-06-22 16:55   ` [Intel-gfx] " Daniel Vetter
2021-06-22 16:55   ` Daniel Vetter
2021-06-23 16:47   ` Boris Brezillon
2021-06-23 16:47     ` [Intel-gfx] " Boris Brezillon
2021-06-23 16:47     ` Boris Brezillon
2021-06-23 19:17     ` Daniel Vetter
2021-06-23 19:17       ` [Intel-gfx] " Daniel Vetter
2021-06-23 19:17       ` Daniel Vetter
2021-06-22 16:55 ` [PATCH 07/15] drm/atomic-helper: make drm_gem_plane_helper_prepare_fb the default Daniel Vetter
2021-06-22 16:55   ` [Intel-gfx] " Daniel Vetter
2021-06-22 19:10   ` Sam Ravnborg
2021-06-22 19:10     ` [Intel-gfx] " Sam Ravnborg
2021-06-22 20:20     ` Daniel Vetter
2021-06-22 20:20       ` [Intel-gfx] " Daniel Vetter
2021-06-23 15:39       ` Sam Ravnborg
2021-06-23 15:39         ` [Intel-gfx] " Sam Ravnborg
2021-06-23 16:22   ` [PATCH] " Daniel Vetter
2021-06-23 16:22     ` [Intel-gfx] " Daniel Vetter
2021-06-22 16:55 ` [PATCH 08/15] drm/<driver>: drm_gem_plane_helper_prepare_fb is now " Daniel Vetter
2021-06-22 16:55   ` Daniel Vetter
2021-06-22 16:55   ` [Intel-gfx] " Daniel Vetter
2021-06-22 16:55   ` Daniel Vetter
2021-06-22 16:55   ` Daniel Vetter
2021-06-22 16:55   ` Daniel Vetter
2021-06-22 16:55   ` Daniel Vetter
2021-06-24  8:32   ` Philipp Zabel
2021-06-24  8:32     ` Philipp Zabel
2021-06-24  8:32     ` [Intel-gfx] " Philipp Zabel
2021-06-24  8:32     ` Philipp Zabel
2021-06-24  8:32     ` Philipp Zabel
2021-06-24  8:32     ` Philipp Zabel
2021-06-24  8:32     ` Philipp Zabel
2021-06-24  8:32     ` Philipp Zabel
2021-06-22 16:55 ` [PATCH 09/15] drm/armada: Remove prepare/cleanup_fb hooks Daniel Vetter
2021-06-22 16:55   ` [Intel-gfx] " Daniel Vetter
2021-06-24 12:46   ` Maxime Ripard
2021-06-24 12:46     ` [Intel-gfx] " Maxime Ripard
2021-06-22 16:55 ` [PATCH 10/15] drm/vram-helpers: Create DRM_GEM_VRAM_PLANE_HELPER_FUNCS Daniel Vetter
2021-06-22 16:55   ` [Intel-gfx] " Daniel Vetter
2021-06-24  7:38   ` Thomas Zimmermann
2021-06-24  7:38     ` [Intel-gfx] " Thomas Zimmermann
2021-06-24  7:46   ` Thomas Zimmermann
2021-06-24  7:46     ` [Intel-gfx] " Thomas Zimmermann
2021-06-24 13:39     ` Daniel Vetter
2021-06-24 13:39       ` [Intel-gfx] " Daniel Vetter
2021-06-22 16:55 ` [PATCH 11/15] drm/omap: Follow implicit fencing in prepare_fb Daniel Vetter
2021-06-22 16:55   ` [Intel-gfx] " Daniel Vetter
2021-06-22 16:55 ` [PATCH 12/15] drm/simple-helper: drm_gem_simple_display_pipe_prepare_fb as default Daniel Vetter
2021-06-22 16:55   ` [Intel-gfx] " Daniel Vetter
2021-06-22 19:15   ` Sam Ravnborg
2021-06-22 19:15     ` [Intel-gfx] " Sam Ravnborg
2021-06-23 16:24   ` [PATCH] " Daniel Vetter
2021-06-23 16:24     ` [Intel-gfx] " Daniel Vetter
2021-06-23 17:34     ` Sam Ravnborg
2021-06-23 17:34       ` [Intel-gfx] " Sam Ravnborg
2021-06-22 16:55 ` [PATCH 13/15] drm/tiny: drm_gem_simple_display_pipe_prepare_fb is the default Daniel Vetter
2021-06-22 16:55   ` Daniel Vetter
2021-06-22 16:55   ` [Intel-gfx] " Daniel Vetter
2021-06-22 16:55   ` Daniel Vetter
2021-06-22 16:55 ` [PATCH 14/15] drm/gem: Tiny kernel clarification for drm_gem_fence_array_add Daniel Vetter
2021-06-22 16:55   ` [Intel-gfx] " Daniel Vetter
2021-06-23  8:42   ` Christian König
2021-06-23  8:42     ` [Intel-gfx] " Christian König
2021-06-24 12:41     ` Daniel Vetter
2021-06-24 12:41       ` [Intel-gfx] " Daniel Vetter
2021-06-24 12:48       ` Christian König
2021-06-24 12:48         ` [Intel-gfx] " Christian König
2021-06-24 13:32         ` Daniel Vetter
2021-06-24 13:32           ` [Intel-gfx] " Daniel Vetter
2021-06-24 13:35           ` Christian König
2021-06-24 13:35             ` [Intel-gfx] " Christian König
2021-06-24 13:41             ` Daniel Vetter
2021-06-24 13:41               ` [Intel-gfx] " Daniel Vetter
2021-06-24 13:45               ` Christian König
2021-06-24 13:45                 ` [Intel-gfx] " Christian König
2021-06-22 16:55 ` [PATCH 15/15] RFC: drm/amdgpu: Implement a proper implicit fencing uapi Daniel Vetter
2021-06-22 16:55   ` [Intel-gfx] " Daniel Vetter
2021-06-22 23:56   ` kernel test robot
2021-06-23  9:45   ` Bas Nieuwenhuizen
2021-06-23  9:45     ` [Intel-gfx] " Bas Nieuwenhuizen
2021-06-23 12:18     ` Daniel Vetter
2021-06-23 12:18       ` [Intel-gfx] " Daniel Vetter
2021-06-23 12:59       ` Christian König
2021-06-23 12:59         ` [Intel-gfx] " Christian König
2021-06-23 13:38         ` Bas Nieuwenhuizen
2021-06-23 13:38           ` [Intel-gfx] " Bas Nieuwenhuizen
2021-06-23 13:44           ` Christian König
2021-06-23 13:44             ` [Intel-gfx] " Christian König
2021-06-23 13:49             ` Daniel Vetter
2021-06-23 13:49               ` [Intel-gfx] " Daniel Vetter
2021-06-23 14:02               ` Christian König
2021-06-23 14:02                 ` [Intel-gfx] " Christian König
2021-06-23 14:50                 ` Daniel Vetter
2021-06-23 14:50                   ` [Intel-gfx] " Daniel Vetter
2021-06-23 14:58                   ` Bas Nieuwenhuizen
2021-06-23 14:58                     ` [Intel-gfx] " Bas Nieuwenhuizen
2021-06-23 15:03                     ` Daniel Vetter
2021-06-23 15:03                       ` [Intel-gfx] " Daniel Vetter
2021-06-23 15:07                       ` Christian König
2021-06-23 15:07                         ` [Intel-gfx] " Christian König
2021-06-23 15:12                         ` Daniel Vetter
2021-06-23 15:12                           ` [Intel-gfx] " Daniel Vetter
2021-06-23 15:15                           ` Christian König
2021-06-23 15:15                             ` [Intel-gfx] " Christian König
2021-06-22 17:08 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for implicit fencing/dma-resv rules for shared buffers Patchwork
2021-06-22 17:11 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-06-22 17:38 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-06-22 19:12 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-06-23 17:05 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for implicit fencing/dma-resv rules for shared buffers (rev5) Patchwork
2021-06-23 17:07 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-06-23 17:35 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-06-23 21:04 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=CAPj87rN_P7u5JGWBOHc5BEXiz1Znek6fDTyj-uVr2nwEcGX_XA@mail.gmail.com \
    --to=daniel@fooishbar.org \
    --cc=Dennis.Li@amd.com \
    --cc=alexander.deucher@amd.com \
    --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.