dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Mikko Perttunen <cyndis@kapsi.fi>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	sumit.semwal@linaro.org, gustavo@padovan.org
Cc: "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	talho@nvidia.com, bhuntsman@nvidia.com,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC] Host1x/TegraDRM UAPI
Date: Thu, 25 Jun 2020 03:47:53 +0300	[thread overview]
Message-ID: <10f9a8e5-9972-76bc-f60a-1bf1211e55e1@gmail.com> (raw)
In-Reply-To: <9b06b7ec-f952-2561-7afb-5653514cd5d3@kapsi.fi>

23.06.2020 15:09, Mikko Perttunen пишет:
> #define DRM_TEGRA_SUBMIT_CREATE_POST_SYNC_FILE      (1<<0)
> #define DRM_TEGRA_SUBMIT_CREATE_POST_SYNCOBJ        (1<<1)

The sync object shouldn't be created by the kernel driver and we
shouldn't need the sync-file FD.

Please consider this example of how syncobj may be used:

  1. Syncobj is created by userspace.

  2. Syncobj's handle (post_fence) is passed with the job to the kernel
driver.

  3. Userspace waits on syncobj for the job's submission.

  4. Kernel driver attaches job-completion dma-fence(s) to the syncobj
after starting to execute the job.

  5. Userspace waits on syncobj for the job's completion.

Syncobj is a superset of the sync-file fence:

  a) Syncobj doesn't have a backing file descriptor when it's created.
For example, why would you need an FD if you're not going to share fence
with other processes. It's possible to get FD out of syncobj later on,
please see [1][2].

  b) Syncobj is designed to be used with a GPU jobs. For example,
userspace passes job to the GPU driver's scheduler and then waits until
job has been started to execute on hardware, this is already supported
by syncobj.

  c) It is possible to attach sync-file's fence to a syncobj [1][2][3]
and now:

  - Userspace may attach sync-file's fence to a syncobj.

  - Userspace may use this syncobj for the job's pre-fence.

  - Kernel driver will take out the pre-fence from the syncobj during of
the job's submission and reset the syncobj's fence to NULL.

  - Job's scheduler will wait on this pre-fence before starting to
execute job.

  - Once the job is started to execute, the job's scheduler will attach
the job's completion-fence to the syncobj. Now syncobj has a post-fence!

  d) It is possible to get sync-file FD out of syncobj [1][2][4].

[1]
https://elixir.bootlin.com/linux/v5.7.2/source/include/uapi/drm/drm.h#L730
[2]
https://elixir.bootlin.com/linux/v5.7.2/source/include/uapi/drm/drm.h#L933
[3]
https://elixir.bootlin.com/linux/v5.7.2/source/drivers/gpu/drm/drm_syncobj.c#L653
[4]
https://elixir.bootlin.com/linux/v5.7.2/source/drivers/gpu/drm/drm_syncobj.c#L674

===

So, sync object can carry both pre-fence and post-fence, and they could
be sync-file FDs!

The corollary is that we can get away by using a single syncobj handle
for the job's submission IOCTL.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-06-25  7:31 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-23 12:09 [RFC] Host1x/TegraDRM UAPI Mikko Perttunen
2020-06-24 20:55 ` Dmitry Osipenko
2020-06-25  9:17   ` Mikko Perttunen
2020-06-24 22:33 ` Dmitry Osipenko
2020-06-25  9:27   ` Mikko Perttunen
2020-06-25 22:50     ` [RFC] Host1x/TegraDRM UAPI (drm_tegra_submit_relocation) Dmitry Osipenko
2020-06-26  9:01       ` Mikko Perttunen
2020-06-24 23:11 ` [RFC] Host1x/TegraDRM UAPI Dmitry Osipenko
2020-06-25  9:16   ` Mikko Perttunen
2020-06-25 23:24     ` Dmitry Osipenko
2020-06-26  9:05       ` Mikko Perttunen
2020-06-24 23:18 ` Dmitry Osipenko
2020-06-25  0:59   ` Dmitry Osipenko
2020-06-24 23:23 ` Dmitry Osipenko
2020-06-25  9:19   ` Mikko Perttunen
2020-06-25  0:47 ` Dmitry Osipenko [this message]
2020-06-25  9:23   ` Mikko Perttunen
2020-06-25 22:47 ` [RFC] Host1x/TegraDRM UAPI (drm_tegra_channel_map) Dmitry Osipenko
2020-06-26  7:34   ` Thierry Reding
2020-06-26 16:35     ` Dmitry Osipenko
2020-06-28 11:16       ` Mikko Perttunen
2020-06-28 22:59         ` Dmitry Osipenko
2020-06-30 10:55           ` Mikko Perttunen
2020-06-30 19:48             ` Dmitry Osipenko
2020-06-26 11:06 ` [RFC] Host1x/TegraDRM UAPI Karol Herbst
2020-06-26 11:13   ` Mikko Perttunen
2020-06-26 11:16     ` Karol Herbst
2020-06-26 11:40   ` Thierry Reding
2020-06-26 13:38     ` Daniel Vetter
2020-06-26 13:59       ` Dmitry Osipenko
2020-06-30  9:09         ` Daniel Vetter
2020-06-27 21:47 ` [RFC] Host1x/TegraDRM UAPI (drm_tegra_submit_syncpt_incr) Dmitry Osipenko
2020-06-28 11:10   ` Mikko Perttunen
2020-06-27 22:32 ` [RFC] Host1x/TegraDRM UAPI (drm_tegra_submit_command) Dmitry Osipenko
2020-06-28 10:28   ` Mikko Perttunen
2020-06-29  0:00     ` Dmitry Osipenko
2020-06-30 10:40       ` Mikko Perttunen
2020-06-27 23:27 ` [RFC] Host1x/TegraDRM UAPI (sync points) Dmitry Osipenko
2020-06-28  9:44   ` Mikko Perttunen
2020-06-29  2:36     ` Dmitry Osipenko
2020-06-29 10:27       ` Mikko Perttunen
2020-06-29 19:28         ` Dmitry Osipenko
2020-06-29 19:33         ` Dmitry Osipenko
2020-06-29 19:42         ` Dmitry Osipenko
2020-06-30 10:26           ` Mikko Perttunen
2020-07-01  0:22             ` Dmitry Osipenko
2020-07-02 12:10               ` Mikko Perttunen
2020-07-07 11:06                 ` Dmitry Osipenko
2020-07-08 10:06                   ` Mikko Perttunen
2020-07-09  9:28                     ` Dmitry Osipenko

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=10f9a8e5-9972-76bc-f60a-1bf1211e55e1@gmail.com \
    --to=digetx@gmail.com \
    --cc=airlied@linux.ie \
    --cc=bhuntsman@nvidia.com \
    --cc=cyndis@kapsi.fi \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo@padovan.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-tegra@vger.kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=talho@nvidia.com \
    --cc=thierry.reding@gmail.com \
    /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).