From: Manasi Navare <manasi.d.navare@intel.com>
To: bhanuprakash.modem@intel.com
Cc: igt-dev@lists.freedesktop.org, pichika.uday.kiran@intel.com
Subject: Re: [igt-dev] [RFC PATCH 1/2] tests/kms_vrr: Use atomic API for page flip
Date: Tue, 2 Jun 2020 12:11:03 -0700 [thread overview]
Message-ID: <20200602191102.GA6277@intel.com> (raw)
In-Reply-To: <20200511062647.9514-2-bhanuprakash.modem@intel.com>
On Mon, May 11, 2020 at 11:56:46AM +0530, bhanuprakash.modem@intel.com wrote:
> From: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
>
> We should avoid using drmModePageFlip as it'll only be used for
> legacy drivers, instead, use igt_display_commit_atomic() API to
> page flip for atomic display code path.
>
> Cc: Harry Wentland <harry.wentland@amd.com>
> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
> Cc: Manasi Navare <manasi.d.navare@intel.com>
> Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
I have tested this on i915 and the page flips are captured correctly with
non blocking page flip requests using atomic_commit call.
@Harry, @Nicholas could you test this on AMD driver to make
sure its not breaking anything?
Manasi
> ---
> tests/kms_vrr.c | 39 ++++++++++-----------------------------
> 1 file changed, 10 insertions(+), 29 deletions(-)
>
> diff --git a/tests/kms_vrr.c b/tests/kms_vrr.c
> index 73115fef..0fe28931 100644
> --- a/tests/kms_vrr.c
> +++ b/tests/kms_vrr.c
> @@ -126,11 +126,11 @@ static range_t get_vrr_range(data_t *data, igt_output_t *output)
> }
>
> /* Returns a suitable vrr test frequency. */
> -static uint32_t get_test_rate_ns(data_t *data, igt_output_t *output)
> +static uint64_t get_test_rate_ns(data_t *data, igt_output_t *output)
> {
> drmModeModeInfo *mode = igt_output_get_mode(output);
> range_t range;
> - uint32_t vtest;
> + uint64_t vtest;
>
> /*
> * The frequency with the fastest convergence speed should be
> @@ -210,32 +210,18 @@ wait_for_vblank(data_t *data, enum pipe pipe)
> return get_vblank_event_ns(data);
> }
>
> -/* Performs an asynchronous non-blocking page-flip on a pipe. */
> -static int
> +/* Performs an atomic non-blocking page-flip on a pipe. */
> +static void
> do_flip(data_t *data, enum pipe pipe_id, igt_fb_t *fb)
> {
> - igt_pipe_t *pipe = &data->display.pipes[pipe_id];
> - int ret;
> -
> igt_set_timeout(1, "Scheduling page flip\n");
>
> - /*
> - * Only the legacy flip ioctl supports async flips.
> - * It's also non-blocking, but returns -EBUSY if flipping too fast.
> - * 2x monitor tests will need async flips in the atomic API.
> - */
> - do {
> - ret = drmModePageFlip(data->drm_fd, pipe->crtc_id,
> - fb->fb_id,
> - DRM_MODE_PAGE_FLIP_EVENT |
> - DRM_MODE_PAGE_FLIP_ASYNC,
> - data);
> - } while (ret == -EBUSY);
> -
> - igt_assert_eq(ret, 0);
> - igt_reset_timeout();
> + igt_display_commit_atomic(&data->display,
> + DRM_MODE_ATOMIC_NONBLOCK |
> + DRM_MODE_PAGE_FLIP_EVENT,
> + NULL);
>
> - return 0;
> + igt_reset_timeout();
> }
>
> /*
> @@ -246,11 +232,6 @@ do_flip(data_t *data, enum pipe pipe_id, igt_fb_t *fb)
> * can arbitrarily restrict the bounds further than the absolute
> * min and max range. But VRR is really about extending the flip
> * to prevent stuttering or to match a source content rate.
> - *
> - * The only way to "present" at a fixed rate like userspace in a vendor
> - * neutral manner is to do it with async flips. This avoids the need
> - * to wait for next vblank and it should eventually converge at the
> - * desired rate.
> */
> static uint32_t
> flip_and_measure(data_t *data, igt_output_t *output, enum pipe pipe,
> @@ -271,7 +252,7 @@ flip_and_measure(data_t *data, igt_output_t *output, enum pipe pipe,
> front = !front;
> do_flip(data, pipe, front ? &data->fb1 : &data->fb0);
>
> - vblank_ns = get_vblank_event_ns(data);
> + vblank_ns = wait_for_vblank(data, pipe);
> diff_ns = rate_ns - (vblank_ns - last_vblank_ns);
> last_vblank_ns = vblank_ns;
>
> --
> 2.24.1.1.gb6d4d82bd5
>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2020-06-02 19:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-11 6:26 [igt-dev] [RFC PATCH 0/2] New subtest for VRR Flipline mode bhanuprakash.modem
2020-05-11 6:26 ` [igt-dev] [RFC PATCH 1/2] tests/kms_vrr: Use atomic API for page flip bhanuprakash.modem
2020-06-02 19:11 ` Manasi Navare [this message]
2020-07-02 4:16 ` Modem, Bhanuprakash
2020-08-03 22:17 ` Navare, Manasi
2020-08-04 16:10 ` Kazlauskas, Nicholas
2020-08-05 7:59 ` Modem, Bhanuprakash
2020-08-05 18:35 ` [igt-dev] [PATCH v2 " Bhanuprakash Modem
2020-08-05 19:11 ` Navare, Manasi
2020-08-06 7:02 ` Modem, Bhanuprakash
2020-08-13 23:21 ` Navare, Manasi
2020-08-14 4:04 ` Modem, Bhanuprakash
2020-05-11 6:26 ` [igt-dev] [RFC PATCH 2/2] tests/kms_vrr: Add new subtest to validate Flipline mode bhanuprakash.modem
2020-06-03 19:47 ` Manasi Navare
2020-06-03 19:50 ` Kazlauskas, Nicholas
2020-06-03 20:04 ` Manasi Navare
2020-08-05 18:35 ` [igt-dev] [PATCH v2 " Bhanuprakash Modem
2020-05-11 7:05 ` [igt-dev] ✓ Fi.CI.BAT: success for New subtest for VRR " Patchwork
2020-05-11 8:45 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
2020-08-05 11:51 ` [igt-dev] ✓ Fi.CI.BAT: success for New subtest for VRR Flipline mode (rev3) Patchwork
2020-08-05 15:39 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2020-08-05 18:35 ` [igt-dev] [PATCH v2 0/2] New subtest for VRR Flipline mode Bhanuprakash Modem
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=20200602191102.GA6277@intel.com \
--to=manasi.d.navare@intel.com \
--cc=bhanuprakash.modem@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=pichika.uday.kiran@intel.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 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.