From: Simon Ser <contact@emersion.fr>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: daniel.vetter@ffwll.ch, amd-gfx@lists.freedesktop.org,
mwen@igalia.com, dri-devel@lists.freedesktop.org,
alexander.deucher@amd.com, hwentlan@amd.com,
nicholas.kazlauskas@amd.com, joshua@froggi.es
Subject: Re: [PATCH 4/4] amd/display: indicate support for atomic async page-flips on DCN
Date: Tue, 30 Aug 2022 07:07:57 +0000 [thread overview]
Message-ID: <2uZ8U_CJxQ9zlnv1lIRhMtwKYU-uuOuhzef2hbvONDPGN-t9Pm4fSejJNLm3ThkJIj1ZkDZwizu49Xactvx-ykn-0Rc23CzsBUXe3Xg_-XI=@emersion.fr> (raw)
In-Reply-To: <CADnq5_NMHWGOdW5Gfr4wK6o5j7PnYKW57Gg6UbbUJfnONdHY1w@mail.gmail.com>
On Friday, August 26th, 2022 at 16:39, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Fri, Aug 26, 2022 at 3:38 AM Simon Ser <contact@emersion.fr> wrote:
> >
> > On Thursday, August 25th, 2022 at 20:22, Alex Deucher <alexdeucher@gmail.com> wrote:
> >
> > > On Wed, Aug 24, 2022 at 11:09 AM Simon Ser contact@emersion.fr wrote:
> > >
> > > > amdgpu_dm_commit_planes already sets the flip_immediate flag for
> > > > async page-flips. This flag is used to set the UNP_FLIP_CONTROL
> > > > register. Thus, no additional change is required to handle async
> > > > page-flips with the atomic uAPI.
> > > >
> > > > Note, async page-flips are still unsupported on DCE with the atomic
> > > > uAPI. The mode_set_base callbacks unconditionally set the
> > > > GRPH_SURFACE_UPDATE_H_RETRACE_EN field of the GRPH_FLIP_CONTROL
> > > > register to 0, which disables async page-flips.
> > >
> > > Can you elaborate a bit on this? We don't use hsync flips at all, even
> > > in non-atomic, as far as I recall. The hardware can also do immediate
> > > flips which take effect as soon as you update the base address
> > > register which is what we use for async updates today IIRC.
> >
> > When user-space performs a page-flip with the legacy KMS uAPI on DCE
> > ASICs, amdgpu_display_crtc_page_flip_target() is called. This function
> > checks for the DRM_MODE_PAGE_FLIP_ASYNC flag, sets work->async, which
> > is then passed as an argument to adev->mode_info.funcs->page_flip() by
> > amdgpu_display_flip_work_func(). Looking at an implementation, for
> > instance dce_v10_0_page_flip(), the async flag is used to set that
> > GRPH_FLIP_CONTROL register:
> >
> > /* flip at hsync for async, default is vsync */
> > tmp = RREG32(mmGRPH_FLIP_CONTROL + amdgpu_crtc->crtc_offset);
> > tmp = REG_SET_FIELD(tmp, GRPH_FLIP_CONTROL,
> > GRPH_SURFACE_UPDATE_H_RETRACE_EN, async ? 1 : 0);
> > WREG32(mmGRPH_FLIP_CONTROL + amdgpu_crtc->crtc_offset, tmp);
> >
> > I don't know how the hardware works, but I assumed it would be
> > necessary to do the same in the atomic uAPI code-path as well. However
> > dce_v10_0_crtc_do_set_base() has this code block:
> >
> > /* Make sure surface address is updated at vertical blank rather than
> > * horizontal blank
> > */
> > tmp = RREG32(mmGRPH_FLIP_CONTROL + amdgpu_crtc->crtc_offset);
> > tmp = REG_SET_FIELD(tmp, GRPH_FLIP_CONTROL,
> > GRPH_SURFACE_UPDATE_H_RETRACE_EN, 0);
> > WREG32(mmGRPH_FLIP_CONTROL + amdgpu_crtc->crtc_offset, tmp);
> >
> > Which unconditionally sets that same register.
> >
> > Either way, it's not a very big deal for this patch series, DCE and DCN
> > are separate, DCE can be sorted out separately.
> >
> > Am I completely mistaken here?
>
> I checked the code and it looks like only DCE11 and newer support
> immediate flips. E.g.,
>
> /* flip immediate for async, default is vsync */
> tmp = RREG32(mmGRPH_FLIP_CONTROL + amdgpu_crtc->crtc_offset);
> tmp = REG_SET_FIELD(tmp, GRPH_FLIP_CONTROL,
> GRPH_SURFACE_UPDATE_IMMEDIATE_EN, async ? 1 : 0);
>
> in dce_v11_0.c.
>
> Either way, the non-DC display code is not atomic anyway, so I don't
> think this is an issue. We still support async flips via the
> non-atomic API. I agree this is not blocking for the patch series,
> just thinking out loud mostly.
Michel pointed out that DC can drive both DCN and DCE. This was a
misunderstanding on my end, I thought DC could only drive DCN. I'll reword the
commit message to refer to DC instead of DCN.
This begs the question, should we bother to set the
atomic_async_page_flip_not_supported flag on non-atomic drivers? I've just
slapped the flag everywhere for simplicity's sake, but maybe it would make more
sense to just set it for atomic-capable drivers. Especially if the long-term
goal is to convert all atomic drivers to support async flips and eventually
remove atomic_async_page_flip_not_supported.
Thanks for the hint regarding DCE10. It sounds like it may be worthwhile to
unset drm_mode_config.async_page_flip on DCE10 and earlier, to indicate to
user-space that async page-flips are not supported on these ASICs? Right now it
seems like we indicate that we support them, and then ignore the ASYNC_FLIP
flag?
next prev parent reply other threads:[~2022-08-30 7:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-24 15:08 [PATCH 0/4] Add support for atomic async page-flips Simon Ser
2022-08-24 15:08 ` [PATCH 1/4] drm: introduce drm_mode_config.atomic_async_page_flip_not_supported Simon Ser
2022-08-24 15:08 ` [PATCH 2/4] drm: allow DRM_MODE_PAGE_FLIP_ASYNC for atomic commits Simon Ser
2022-08-24 15:08 ` [PATCH 3/4] drm: introduce DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP Simon Ser
2022-08-26 8:19 ` Ville Syrjälä
2022-08-29 16:01 ` Simon Ser
2022-08-30 8:08 ` Ville Syrjälä
2022-08-30 8:40 ` Pekka Paalanen
2022-08-30 10:24 ` Ville Syrjälä
2022-08-30 12:40 ` Simon Ser
2022-08-30 12:33 ` Simon Ser
2022-08-30 8:41 ` Michel Dänzer
2022-08-30 12:58 ` Simon Ser
2022-08-24 15:08 ` [PATCH 4/4] amd/display: indicate support for atomic async page-flips on DCN Simon Ser
2022-08-25 18:22 ` Alex Deucher
2022-08-26 7:38 ` Simon Ser
2022-08-26 14:39 ` Alex Deucher
2022-08-30 7:07 ` Simon Ser [this message]
2022-08-30 14:06 ` Alex Deucher
2022-08-30 14:23 ` Simon Ser
2022-08-30 14:42 ` Alex Deucher
2022-08-30 15:06 ` Simon Ser
2022-08-24 16:42 ` [PATCH 0/4] Add support for atomic async page-flips 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='2uZ8U_CJxQ9zlnv1lIRhMtwKYU-uuOuhzef2hbvONDPGN-t9Pm4fSejJNLm3ThkJIj1ZkDZwizu49Xactvx-ykn-0Rc23CzsBUXe3Xg_-XI=@emersion.fr' \
--to=contact@emersion.fr \
--cc=alexander.deucher@amd.com \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hwentlan@amd.com \
--cc=joshua@froggi.es \
--cc=mwen@igalia.com \
--cc=nicholas.kazlauskas@amd.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).