From: "Michel Dänzer" <michel.daenzer@mailbox.org>
To: "Christian König" <christian.koenig@amd.com>,
"Ray Strode" <halfline@gmail.com>
Cc: alexander.deucher@amd.com, daniel.vetter@ffwll.ch,
Xinhui.Pan@amd.com, dri-devel@lists.freedesktop.org,
airlied@redhat.com
Subject: Re: [PATCH] drm/atomic: Perform blocking commits on workqueue
Date: Thu, 28 Sep 2023 17:19:29 +0200 [thread overview]
Message-ID: <9772fbd3-be44-a799-fb21-b4ab50418f6a@mailbox.org> (raw)
In-Reply-To: <2e19a4a1-d42e-4e89-a0c1-c89e44d05819@amd.com>
On 9/28/23 16:51, Christian König wrote:
> Am 28.09.23 um 15:37 schrieb Michel Dänzer:
>> On 9/28/23 14:59, Ray Strode wrote:
>>> On Thu, Sep 28, 2023 at 5:43 AM Michel Dänzer
>>> <michel.daenzer@mailbox.org> wrote:
>>>>>>> When it's really not desirable to account the CPU overhead to the
>>>>>>> process initiating it then you probably rather want to use an non
>>>>>>> blocking commit plus a dma_fence to wait for the work to end from userspace.
>>>>>> Well, first I don't think that's very convenient. You're talking about
>>>>>> a per-plane property, so there would need to be a separate file
>>>>>> descriptor allocated for every plane, right? and user-space would have
>>>>>> to block on all of them before proceeding?
>>>> OUT_FENCE_PTR is a per-CRTC property, not per-plane.
>>> Okay, sure.
>>>
>>>> Also, at least in this particular case, a single sync file (not dma_fence) for any CRTC might suffice.
>>> I don't see how we could rely on that given the provided api and
>>> multitude of drivers. It might work and then break randomly.
>> If it's supposed to work from the KMS API PoV, any bugs to the contrary should be fixed.
>>
>> I'm not really seeing the big difference between using a single fence or multiple, anyway.
>
> The big difference is that a standard modeset can take some time, e.g. setting up power levels, waiting for PLLs to settle, waiting for a vblank etc..
Right (starting a game shouldn't involve such a modeset though in a Wayland session).
What I mean is there's no significant difference for user space between using a single out fence or multiple. Just slightly different bookkeeping.
> But in the case of turning thing off, what should we wait for?
The atomic commit to finish, so it's safe to submit another one without hitting EBUSY. (What we use the completion events for with page flips)
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
next prev parent reply other threads:[~2023-09-28 15:19 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-26 17:05 [PATCH] drm/atomic: Perform blocking commits on workqueue Ray Strode
2023-09-27 8:04 ` Christian König
2023-09-27 20:25 ` Ray Strode
2023-09-28 6:56 ` Christian König
2023-09-28 9:43 ` Michel Dänzer
2023-09-28 12:59 ` Ray Strode
2023-09-28 13:37 ` Michel Dänzer
2023-09-28 14:51 ` Christian König
2023-09-28 15:19 ` Michel Dänzer [this message]
2023-09-28 12:46 ` Ray Strode
2023-09-28 13:23 ` Christian König
2023-09-28 13:58 ` Michel Dänzer
2023-09-28 15:02 ` Christian König
2023-09-28 14:20 ` Ray Strode
2023-09-28 15:03 ` Ville Syrjälä
2023-09-28 19:33 ` Ray Strode
2023-10-04 17:27 ` Ville Syrjälä
2023-10-04 19:38 ` Ray Strode
2023-10-05 9:57 ` Daniel Vetter
2023-10-05 10:16 ` Ville Syrjälä
2023-10-10 11:36 ` Daniel Vetter
2023-10-05 11:51 ` Christian König
2023-10-05 21:04 ` Ray Strode
2023-10-06 7:12 ` Christian König
2023-10-06 18:48 ` Ray Strode
2023-10-08 10:37 ` Michel Dänzer
2023-10-09 6:42 ` Christian König
2023-10-09 12:19 ` Ville Syrjälä
2023-10-09 12:36 ` Christian König
2023-10-10 11:41 ` Daniel Vetter
2023-10-12 18:19 ` Ray Strode
2023-10-13 9:41 ` Daniel Vetter
2023-10-13 10:22 ` Michel Dänzer
2023-10-17 7:32 ` Daniel Vetter
2023-10-17 7:55 ` Christian König
2023-10-13 14:04 ` Ray Strode
2023-10-17 7:37 ` 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=9772fbd3-be44-a799-fb21-b4ab50418f6a@mailbox.org \
--to=michel.daenzer@mailbox.org \
--cc=Xinhui.Pan@amd.com \
--cc=airlied@redhat.com \
--cc=alexander.deucher@amd.com \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=halfline@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