All of lore.kernel.org
 help / color / mirror / Atom feed
From: Melissa Wen <mwen@igalia.com>
To: dri-devel@lists.freedesktop.org
Cc: Emma Anholt <emma@anholt.net>, David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel@ffwll.ch>,
	Maxime Ripard <maxime@cerno.tech>,
	Boris Brezillon <boris.brezillon@collabora.com>
Subject: [PATCH 0/3] drm/v3d: add multiple in/out syncobjs support
Date: Wed, 18 Aug 2021 18:54:08 +0100	[thread overview]
Message-ID: <cover.1629307160.git.mwen@igalia.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]

Currently, v3d only supports single in/out syncobj per submission (in
v3d_submit_cl, there are two in_sync, one for bin and another for render
job); however, Vulkan queue submit operations expect multiples wait and
signal semaphores. This series extends v3d interface and job dependency
operations to handle more than one in/out syncobj.

The main difference from the RFC series[1] is that here I already worked
on top of Daniel Vetter's work for drm/scheduler[2] (even if the series
is missing a few acks).

The first patch just decouples the steps to lookup and add job
dependency from the job init code, since the operation repeats for every
syncobj that a job should wait before starting. So, the third patch of
this series will reuse it to handle multiples wait for semaphores. 

The second patch extends our interface by using a generic extension.
This approach was inspired by i915_user_extension[3] and
amd_cs_chunks[4] to give a little more flexibility in adding other
submission features in the future. Therefore, the list of extensions
would work as a hub of features that use an id to determine the
corresponding feature data type.

With this base, the third patch adds multiple wait/signal semaphores
support. For this, we add to the list of the generic extensions a new
data type (drm_v3d_multi_sync) that points to two arrays of syncobjs
(in/out) and also determines (flags) if the dependencies must be added
to the bin job or render job (in the case of v3d_submit_cl). An
auxiliary struct (v3d_submit_ext) is used when parsing submission
extensions. Finally, we reserve some space in the semaphore struct
(drm_v3d_sem) to accommodate timeline semaphores that we aim to add
support soon (same reason for already defining v3d_submit_outsync).

[1] https://patchwork.freedesktop.org/series/93388/
[2] https://patchwork.freedesktop.org/series/93413/
[3] https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/i915/i915_user_extensions.c?id=9d1305ef80b95dde0337106ed8b826604e2155ad
[4] https://cgit.freedesktop.org/drm/drm-misc/tree/include/uapi/drm/amdgpu_drm.h#n556

In the mesa side, the work related to this series is available at
https://gitlab.freedesktop.org/mwen/mesa/-/commit/77bd2b21f61a9caeced934bd13b99e675a428398
where I checked these changes using Mesa CI.

Melissa Wen (3):
  drm/v3d: decouple adding job dependencies steps from job init
  drm/v3d: add generic ioctl extension
  drm/v3d: add multiple syncobjs support

 drivers/gpu/drm/v3d/v3d_drv.c |   7 +-
 drivers/gpu/drm/v3d/v3d_drv.h |  14 ++
 drivers/gpu/drm/v3d/v3d_gem.c | 303 ++++++++++++++++++++++++++++------
 include/uapi/drm/v3d_drm.h    |  76 ++++++++-
 4 files changed, 350 insertions(+), 50 deletions(-)

-- 
2.30.2


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

             reply	other threads:[~2021-08-18 17:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18 17:54 Melissa Wen [this message]
2021-08-18 17:55 ` [PATCH 1/3] drm/v3d: decouple adding job dependencies steps from job init Melissa Wen
2021-08-18 17:56 ` [PATCH 2/3] drm/v3d: add generic ioctl extension Melissa Wen
2021-09-15 13:24   ` Iago Toral
2021-09-15 16:28     ` Melissa Wen
2021-09-15 16:32       ` Iago Toral
2021-09-16 12:19   ` Daniel Vetter
2021-09-16 20:42     ` Melissa Wen
2021-08-18 17:57 ` [PATCH 3/3] drm/v3d: add multiple syncobjs support Melissa Wen
2021-09-16 11:30   ` Iago Toral
2021-09-16 16:39     ` Melissa Wen

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=cover.1629307160.git.mwen@igalia.com \
    --to=mwen@igalia.com \
    --cc=airlied@linux.ie \
    --cc=boris.brezillon@collabora.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emma@anholt.net \
    --cc=maxime@cerno.tech \
    /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.