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
next prev 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: linkBe 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.