From: Dmitry Osipenko <digetx@gmail.com> To: Thierry Reding <thierry.reding@gmail.com>, Mikko Perttunen <cyndis@kapsi.fi> Cc: Mikko Perttunen <mperttunen@nvidia.com>, jonathanh@nvidia.com, airlied@linux.ie, daniel@ffwll.ch, linux-tegra@vger.kernel.org, dri-devel@lists.freedesktop.org, talho@nvidia.com, bhuntsman@nvidia.com Subject: Re: [PATCH v5 00/21] Host1x sync point UAPI should not be used for tracking DRM jobs Date: Fri, 29 Jan 2021 20:30:07 +0300 [thread overview] Message-ID: <1ff922b2-161d-c8b9-7b08-4454ff7329f8@gmail.com> (raw) In-Reply-To: <YBLtPv/1mGXwtibX@ulmo> 28.01.2021 19:58, Thierry Reding пишет: > On Thu, Jan 28, 2021 at 01:08:54PM +0200, Mikko Perttunen wrote: >> On 1/27/21 11:20 PM, Dmitry Osipenko wrote: >>> 26.01.2021 05:45, Mikko Perttunen пишет: >>>>> 2. We will probably need a dedicated drm_tegra_submit_cmd for sync point >>>>> increments. The job's sync point will be allocated dynamically when job >>>>> is submitted. We will need a fag for the sync_incr and wait_syncpt >>>>> commands, saying "it's a job's sync point increment/wait" >>>> >>>> Negative. Like I have explained in previous discussions, with the >>>> current way the usage of hardware resources is much more deterministic >>>> and obvious. I disagree on the point that this is much more complicated >>>> for the userspace. Separating syncpoint and channel allocation is one of >>>> the primary motivations of this series for me. >>> >>> Sync points are a limited resource. The most sensible way to work around >>> it is to keep sync points within kernel as much as possible. This is not >>> only much simpler for user space, but also allows to utilize DRM API >>> properly without re-inventing what already exists and it's easier to >>> maintain hardware in a good state. >> >> I've spent the last few years designing for automotive and industrial >> products, where we don't want to at runtime notice that the system is out of >> free syncpoints and because of that we can only process the next camera >> frame in a second or two instead of 16 milliseconds. We need to know that >> once we have allocated the resource, it is there. The newer chips are also >> designed to support this. >> >> Considering Linux is increasingly being used for such applications, and they >> are important target markets for NVIDIA, these need to be supported. >> >> Because of the above design constraint the userspace software that runs in >> these environments also expects resources to be allocated up front. This >> isn't a matter of having to design that software according to what kind of >> allocation API we decide do at Linux level -- it's no use designing for >> dynamic allocation if it leads to you not meeting the safety requirement of >> needing to ensure you have all resources allocated up front. >> >> This isn't a good design feature just in a car, but in anything that needs >> to be reliable. However, it does pose some tradeoffs, and if you think that >> running out of syncpoints on T20-T114 because of upfront allocation is an >> actual problem, I'm not opposed to having both options available. The word "reliable" contradicts to the error-prone approach. On the other hand, it should be very difficult to change the stubborn downstream firmware and we want driver to be usable as much as possible, so in reality not much can be done about it. > I think that's a fair point. I don't see why we can't support both > implicit and explicit syncpoint requests. If most of the use-cases can > work with implicit syncpoints and let the kernel handle all aspects of > it, that's great. But there's no reason we can't provide more explicit > controls for cases where it's really important that all the resources > are allocated upfront. > > Ultimately this is very specific to each use-case, so I think having > both options will provide us with the most flexibility. It should be fine to support both. This will add complexity to the driver, thus it needs to be done wisely. I'll need more time to think about it.
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com> To: Thierry Reding <thierry.reding@gmail.com>, Mikko Perttunen <cyndis@kapsi.fi> Cc: airlied@linux.ie, dri-devel@lists.freedesktop.org, jonathanh@nvidia.com, talho@nvidia.com, bhuntsman@nvidia.com, linux-tegra@vger.kernel.org, Mikko Perttunen <mperttunen@nvidia.com> Subject: Re: [PATCH v5 00/21] Host1x sync point UAPI should not be used for tracking DRM jobs Date: Fri, 29 Jan 2021 20:30:07 +0300 [thread overview] Message-ID: <1ff922b2-161d-c8b9-7b08-4454ff7329f8@gmail.com> (raw) In-Reply-To: <YBLtPv/1mGXwtibX@ulmo> 28.01.2021 19:58, Thierry Reding пишет: > On Thu, Jan 28, 2021 at 01:08:54PM +0200, Mikko Perttunen wrote: >> On 1/27/21 11:20 PM, Dmitry Osipenko wrote: >>> 26.01.2021 05:45, Mikko Perttunen пишет: >>>>> 2. We will probably need a dedicated drm_tegra_submit_cmd for sync point >>>>> increments. The job's sync point will be allocated dynamically when job >>>>> is submitted. We will need a fag for the sync_incr and wait_syncpt >>>>> commands, saying "it's a job's sync point increment/wait" >>>> >>>> Negative. Like I have explained in previous discussions, with the >>>> current way the usage of hardware resources is much more deterministic >>>> and obvious. I disagree on the point that this is much more complicated >>>> for the userspace. Separating syncpoint and channel allocation is one of >>>> the primary motivations of this series for me. >>> >>> Sync points are a limited resource. The most sensible way to work around >>> it is to keep sync points within kernel as much as possible. This is not >>> only much simpler for user space, but also allows to utilize DRM API >>> properly without re-inventing what already exists and it's easier to >>> maintain hardware in a good state. >> >> I've spent the last few years designing for automotive and industrial >> products, where we don't want to at runtime notice that the system is out of >> free syncpoints and because of that we can only process the next camera >> frame in a second or two instead of 16 milliseconds. We need to know that >> once we have allocated the resource, it is there. The newer chips are also >> designed to support this. >> >> Considering Linux is increasingly being used for such applications, and they >> are important target markets for NVIDIA, these need to be supported. >> >> Because of the above design constraint the userspace software that runs in >> these environments also expects resources to be allocated up front. This >> isn't a matter of having to design that software according to what kind of >> allocation API we decide do at Linux level -- it's no use designing for >> dynamic allocation if it leads to you not meeting the safety requirement of >> needing to ensure you have all resources allocated up front. >> >> This isn't a good design feature just in a car, but in anything that needs >> to be reliable. However, it does pose some tradeoffs, and if you think that >> running out of syncpoints on T20-T114 because of upfront allocation is an >> actual problem, I'm not opposed to having both options available. The word "reliable" contradicts to the error-prone approach. On the other hand, it should be very difficult to change the stubborn downstream firmware and we want driver to be usable as much as possible, so in reality not much can be done about it. > I think that's a fair point. I don't see why we can't support both > implicit and explicit syncpoint requests. If most of the use-cases can > work with implicit syncpoints and let the kernel handle all aspects of > it, that's great. But there's no reason we can't provide more explicit > controls for cases where it's really important that all the resources > are allocated upfront. > > Ultimately this is very specific to each use-case, so I think having > both options will provide us with the most flexibility. It should be fine to support both. This will add complexity to the driver, thus it needs to be done wisely. I'll need more time to think about it. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-01-29 17:34 UTC|newest] Thread overview: 195+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-11 12:59 [PATCH v5 00/21] Host1x/TegraDRM UAPI Mikko Perttunen 2021-01-11 12:59 ` Mikko Perttunen 2021-01-11 12:59 ` [PATCH v5 01/21] gpu: host1x: Use different lock classes for each client Mikko Perttunen 2021-01-11 12:59 ` Mikko Perttunen 2021-03-22 14:46 ` Thierry Reding 2021-03-22 14:46 ` Thierry Reding 2021-03-22 14:48 ` Dmitry Osipenko 2021-03-22 14:48 ` Dmitry Osipenko 2021-03-22 15:19 ` Mikko Perttunen 2021-03-22 15:19 ` Mikko Perttunen 2021-03-22 16:01 ` Dmitry Osipenko 2021-03-22 16:01 ` Dmitry Osipenko 2021-03-23 10:20 ` Thierry Reding 2021-03-23 10:20 ` Thierry Reding 2021-03-23 13:25 ` Dmitry Osipenko 2021-03-23 13:25 ` Dmitry Osipenko 2021-03-26 14:54 ` Mikko Perttunen 2021-03-26 14:54 ` Mikko Perttunen 2021-03-26 18:31 ` Dmitry Osipenko 2021-03-26 18:31 ` Dmitry Osipenko 2021-03-26 19:10 ` Mikko Perttunen 2021-03-26 19:10 ` Mikko Perttunen 2021-03-26 22:47 ` Dmitry Osipenko 2021-03-26 22:47 ` Dmitry Osipenko 2021-01-11 13:00 ` [PATCH v5 02/21] gpu: host1x: Allow syncpoints without associated client Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 10:10 ` Thierry Reding 2021-03-23 10:10 ` Thierry Reding 2021-03-23 10:32 ` Mikko Perttunen 2021-03-23 10:32 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 03/21] gpu: host1x: Show number of pending waiters in debugfs Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 10:16 ` Thierry Reding 2021-03-23 10:16 ` Thierry Reding 2021-03-26 14:34 ` Mikko Perttunen 2021-03-26 14:34 ` Mikko Perttunen 2021-04-01 21:19 ` Michał Mirosław 2021-04-01 21:19 ` Michał Mirosław 2021-04-02 16:02 ` Dmitry Osipenko 2021-04-02 16:02 ` Dmitry Osipenko 2021-04-08 4:13 ` Michał Mirosław 2021-04-08 4:13 ` Michał Mirosław 2021-04-08 4:25 ` Michał Mirosław 2021-04-08 4:25 ` Michał Mirosław 2021-04-08 11:58 ` Mikko Perttunen 2021-04-08 11:58 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 04/21] gpu: host1x: Remove cancelled waiters immediately Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-12 22:07 ` Dmitry Osipenko 2021-01-12 22:07 ` Dmitry Osipenko 2021-01-12 22:20 ` Mikko Perttunen 2021-01-12 22:20 ` Mikko Perttunen 2021-01-13 16:29 ` Dmitry Osipenko 2021-01-13 16:29 ` Dmitry Osipenko 2021-01-13 18:16 ` Mikko Perttunen 2021-01-13 18:16 ` Mikko Perttunen 2021-03-23 10:23 ` Thierry Reding 2021-03-23 10:23 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 05/21] gpu: host1x: Use HW-equivalent syncpoint expiration check Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 10:26 ` Thierry Reding 2021-03-23 10:26 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 06/21] gpu: host1x: Cleanup and refcounting for syncpoints Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 10:36 ` Thierry Reding 2021-03-23 10:36 ` Thierry Reding 2021-03-23 10:44 ` Mikko Perttunen 2021-03-23 10:44 ` Mikko Perttunen 2021-03-23 11:21 ` Thierry Reding 2021-03-23 11:21 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 07/21] gpu: host1x: Introduce UAPI header Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 10:52 ` Thierry Reding 2021-03-23 10:52 ` Thierry Reding 2021-03-23 11:12 ` Mikko Perttunen 2021-03-23 11:12 ` Mikko Perttunen 2021-03-23 11:43 ` Thierry Reding 2021-03-23 11:43 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 08/21] gpu: host1x: Implement /dev/host1x device node Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 11:02 ` Thierry Reding 2021-03-23 11:02 ` Thierry Reding 2021-03-23 11:15 ` Mikko Perttunen 2021-03-23 11:15 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 09/21] gpu: host1x: DMA fences and userspace fence creation Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 11:15 ` Thierry Reding 2021-03-23 11:15 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 10/21] gpu: host1x: Add no-recovery mode Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 11/21] gpu: host1x: Add job release callback Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 11:55 ` Thierry Reding 2021-03-23 11:55 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 12/21] gpu: host1x: Add support for syncpoint waits in CDMA pushbuffer Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 13/21] gpu: host1x: Reset max value when freeing a syncpoint Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 14/21] gpu: host1x: Reserve VBLANK syncpoints at initialization Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 15/21] drm/tegra: Add new UAPI to header Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-13 18:14 ` Dmitry Osipenko 2021-01-13 18:14 ` Dmitry Osipenko 2021-01-13 18:56 ` Mikko Perttunen 2021-01-13 18:56 ` Mikko Perttunen 2021-01-14 8:36 ` Dmitry Osipenko 2021-01-14 8:36 ` Dmitry Osipenko 2021-01-14 10:34 ` Mikko Perttunen 2021-01-14 10:34 ` Mikko Perttunen 2021-03-23 12:30 ` Thierry Reding 2021-03-23 12:30 ` Thierry Reding 2021-03-23 14:00 ` Dmitry Osipenko 2021-03-23 14:00 ` Dmitry Osipenko 2021-03-23 16:44 ` Thierry Reding 2021-03-23 16:44 ` Thierry Reding 2021-03-23 17:32 ` Dmitry Osipenko 2021-03-23 17:32 ` Dmitry Osipenko 2021-03-23 17:57 ` Thierry Reding 2021-03-23 17:57 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 16/21] drm/tegra: Boot VIC during runtime PM resume Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 17/21] drm/tegra: Set resv fields when importing/exporting GEMs Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 18/21] drm/tegra: Allocate per-engine channel in core code Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 12:35 ` Thierry Reding 2021-03-23 12:35 ` Thierry Reding 2021-03-23 13:15 ` Mikko Perttunen 2021-03-23 13:15 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 19/21] drm/tegra: Implement new UAPI Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-11 17:37 ` kernel test robot 2021-01-11 17:37 ` kernel test robot 2021-01-11 17:37 ` kernel test robot 2021-01-12 22:27 ` Dmitry Osipenko 2021-01-12 22:27 ` Dmitry Osipenko 2021-03-23 13:25 ` Thierry Reding 2021-03-23 13:25 ` Thierry Reding 2021-03-23 14:43 ` Mikko Perttunen 2021-03-23 14:43 ` Mikko Perttunen 2021-03-23 15:00 ` Dmitry Osipenko 2021-03-23 15:00 ` Dmitry Osipenko 2021-03-23 16:59 ` Thierry Reding 2021-03-23 16:59 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 20/21] drm/tegra: Implement job submission part of " Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 13:38 ` Thierry Reding 2021-03-23 13:38 ` Thierry Reding 2021-03-23 14:16 ` Mikko Perttunen 2021-03-23 14:16 ` Mikko Perttunen 2021-03-23 17:04 ` Thierry Reding 2021-03-23 17:04 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 21/21] drm/tegra: Add job firewall Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-19 22:29 ` [PATCH v5 00/21] Host1x/TegraDRM UAPI Dmitry Osipenko 2021-01-19 22:29 ` Dmitry Osipenko 2021-01-26 2:45 ` Mikko Perttunen 2021-01-26 2:45 ` Mikko Perttunen 2021-01-27 21:20 ` [PATCH v5 00/21] Host1x sync point UAPI should not be used for tracking DRM jobs Dmitry Osipenko 2021-01-27 21:20 ` Dmitry Osipenko 2021-01-28 11:08 ` Mikko Perttunen 2021-01-28 11:08 ` Mikko Perttunen 2021-01-28 16:58 ` Thierry Reding 2021-01-28 16:58 ` Thierry Reding 2021-01-29 17:30 ` Dmitry Osipenko [this message] 2021-01-29 17:30 ` Dmitry Osipenko 2021-02-03 11:18 ` Mikko Perttunen 2021-02-03 11:18 ` Mikko Perttunen 2021-02-27 11:19 ` Dmitry Osipenko 2021-02-27 11:19 ` Dmitry Osipenko 2021-03-01 8:19 ` Mikko Perttunen 2021-03-01 8:19 ` Mikko Perttunen 2021-03-23 18:21 ` Thierry Reding 2021-03-23 18:21 ` Thierry Reding 2021-03-23 19:57 ` Dmitry Osipenko 2021-03-23 19:57 ` Dmitry Osipenko 2021-03-23 20:13 ` Dmitry Osipenko 2021-03-23 20:13 ` Dmitry Osipenko 2021-01-27 21:26 ` [PATCH v5 00/21] Host1x/TegraDRM UAPI Dmitry Osipenko 2021-01-27 21:26 ` Dmitry Osipenko 2021-01-27 21:57 ` Mikko Perttunen 2021-01-27 21:57 ` Mikko Perttunen 2021-01-27 22:06 ` Dmitry Osipenko 2021-01-27 22:06 ` Dmitry Osipenko 2021-01-28 11:46 ` Mikko Perttunen 2021-01-28 11:46 ` Mikko Perttunen 2021-01-27 21:35 ` [PATCH v5 00/21] sync_file API is not very suitable for DRM Dmitry Osipenko 2021-01-27 21:35 ` Dmitry Osipenko 2021-01-27 21:53 ` Mikko Perttunen 2021-01-27 21:53 ` Mikko Perttunen 2021-01-27 22:26 ` Dmitry Osipenko 2021-01-27 22:26 ` Dmitry Osipenko 2021-01-27 21:52 ` [PATCH v5 00/21] support option where all commands are collected into a single,dedicated cmdstream Dmitry Osipenko 2021-01-27 21:52 ` 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=1ff922b2-161d-c8b9-7b08-4454ff7329f8@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=jonathanh@nvidia.com \ --cc=linux-tegra@vger.kernel.org \ --cc=mperttunen@nvidia.com \ --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: 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.