From: Rob Clark <robdclark@gmail.com>
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>,
"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>,
"Christian König" <christian.koenig@amd.com>,
"Dennis Li" <Dennis.Li@amd.com>,
"Deepak R Varma" <mh12gx2825@gmail.com>
Subject: Re: [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
Date: Fri, 21 May 2021 07:58:57 -0700 [thread overview]
Message-ID: <CAF6AEGvr_CWDGgKFTNGQTiApbg=kyOn=uBrRM_H3DO8UBq-W5g@mail.gmail.com> (raw)
In-Reply-To: <20210521090959.1663703-1-daniel.vetter@ffwll.ch>
On Fri, May 21, 2021 at 2:10 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT,
> but because it doesn't use the drm/scheduler it handles fences from
> the wrong context with a synchronous dma_fence_wait. See
> submit_fence_sync() leading to msm_gem_sync_object(). Investing into
> a scheduler might be a good idea.
Yeah, drm/scheduler is (along with a lot of other things) on the TODO
list. But this isn't quite as bad as it sounds because userspace uses
a u_queue thread to call the submit ioctl rather than blocking the
driver. (It also offloads some other work from the driver thread,
like submit merging to reduce # of ioctls. Coincidentally that
arrangement was a step towards preparing userspace for some
hypothetical non-ioctl uapi ;-))
OTOH it would be good to move blocking until the system can free
enough pages to repin bo's out of the ioctl path to better handle some
memory pressure corner cases without having to be interruptable over a
lot more of the submit path.. Running chrome+android on devices
without a lot of memory is fun..
BR,
-R
next prev parent reply other threads:[~2021-05-21 14:55 UTC|newest]
Thread overview: 53+ 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 ` [PATCH 02/11] drm/panfrost: Remove sched_lock Daniel Vetter
2021-05-21 9:32 ` Lucas Stach
2021-05-21 14:49 ` Daniel Vetter
2021-05-21 9:09 ` [PATCH 03/11] drm/panfrost: Use xarray and helpers for depedency tracking Daniel Vetter
2021-06-02 14:06 ` Steven Price
2021-06-02 18:51 ` Daniel Vetter
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 12:22 ` Daniel Stone
2021-05-21 12:28 ` [Linaro-mm-sig] " Christian König
2021-05-21 12:54 ` Daniel Stone
2021-05-21 13:09 ` Christian König
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 ` [PATCH 06/11] drm/<driver>: drm_gem_plane_helper_prepare_fb is now " Daniel Vetter
2021-05-21 9:38 ` Lucas Stach
2021-05-21 12:20 ` Heiko Stübner
2021-05-21 12:22 ` Paul Cercueil
2021-05-21 15:53 ` Jernej Škrabec
2021-05-21 23:18 ` Chun-Kuang Hu
2021-05-23 12:17 ` Martin Blumenstingl
2021-05-24 7:54 ` Tomi Valkeinen
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 ` [PATCH 08/11] drm/vram-helpers: Create DRM_GEM_VRAM_PLANE_HELPER_FUNCS Daniel Vetter
2021-05-21 9:33 ` tiantao (H)
2021-05-21 9:09 ` [PATCH 09/11] drm/omap: Follow implicit fencing in prepare_fb Daniel Vetter
2021-05-24 7:53 ` 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-25 17:48 ` Noralf Trønnes
2021-05-25 17:53 ` 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 13:41 ` David Lechner
2021-05-21 14:09 ` Noralf Trønnes
2021-05-25 16:05 ` Daniel Vetter
2021-05-21 14:13 ` Oleksandr Andrushchenko
2021-05-28 0:38 ` Linus Walleij
2021-05-21 9:46 ` [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules Bas Nieuwenhuizen
2021-05-21 14:37 ` Daniel Vetter
2021-05-21 15:00 ` Bas Nieuwenhuizen
2021-05-21 15:16 ` Daniel Vetter
2021-05-21 18:08 ` [Mesa-dev] " Christian König
2021-05-21 18:31 ` Daniel Vetter
2021-05-22 8:30 ` Christian König
2021-05-25 13:05 ` Daniel Vetter
2021-05-25 15:05 ` Christian König
2021-05-25 15:23 ` Daniel Vetter
2021-05-26 13:32 ` Christian König
2021-05-26 13:51 ` Daniel Vetter
2021-05-21 11:22 ` Christian König
2021-05-21 14:58 ` Rob Clark [this message]
2021-05-21 14:58 ` [Mesa-dev] " Daniel Vetter
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='CAF6AEGvr_CWDGgKFTNGQTiApbg=kyOn=uBrRM_H3DO8UBq-W5g@mail.gmail.com' \
--to=robdclark@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).