From: "Sharma, Swati2" <swati2.sharma@intel.com>
To: Martin Peres <martin.peres@linux.intel.com>,
igt-dev@lists.freedesktop.org
Cc: petri.latvala@intel.com
Subject: Re: [igt-dev] [PATCH i-g-t] tests/kms_atomic: add test to validate immutable zpos
Date: Thu, 12 Mar 2020 13:29:03 +0530 [thread overview]
Message-ID: <9d91ab7d-db5b-09bd-8579-8a44613804c1@intel.com> (raw)
In-Reply-To: <bbc61826-330e-28ab-b1a0-938547dc3f01@linux.intel.com>
On 27-Feb-20 12:33 PM, Martin Peres wrote:
> On 2020-02-26 15:45, Swati Sharma wrote:
>> i915 implements immutable zpos property whereas the existing test
>> case is written to validate mutable zpos.
>>
>> Added new test case to validate immutable zpos and skip existing
>> test case if i915 driver is not detected.
>>
>> Issue: https://gitlab.freedesktop.org/drm/intel/issues/404
>> Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
>> ---
>> tests/kms_atomic.c | 120 ++++++++++++++++++++++++++++++++++++++++++---
>> 1 file changed, 112 insertions(+), 8 deletions(-)
>>
>> diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
>> index 8462d128..7a5edc8e 100644
>> --- a/tests/kms_atomic.c
>> +++ b/tests/kms_atomic.c
>> @@ -121,7 +121,7 @@ static void plane_check_current_state(igt_plane_t *plane, const uint64_t *values
>> }
>>
>> static void plane_commit(igt_plane_t *plane, enum igt_commit_style s,
>> - enum kms_atomic_check_relax relax)
>> + enum kms_atomic_check_relax relax)
>> {
>> igt_display_commit2(plane->pipe->display, s);
>> plane_check_current_state(plane, plane->values, relax);
>> @@ -277,9 +277,9 @@ static uint32_t plane_get_igt_format(igt_plane_t *plane)
>> }
>>
>> static void
>> -plane_primary_overlay_zpos(igt_pipe_t *pipe, igt_output_t *output,
>> - igt_plane_t *primary, igt_plane_t *overlay,
>> - uint32_t format_primary, uint32_t format_overlay)
>> +plane_primary_overlay_mutable_zpos(igt_pipe_t *pipe, igt_output_t *output,
>> + igt_plane_t *primary, igt_plane_t *overlay,
>> + uint32_t format_primary, uint32_t format_overlay)
>> {
>> struct igt_fb fb_primary, fb_overlay;
>> drmModeModeInfo *mode = igt_output_get_mode(output);
>> @@ -358,6 +358,97 @@ plane_primary_overlay_zpos(igt_pipe_t *pipe, igt_output_t *output,
>> igt_assert_eq_u64(igt_plane_get_prop(overlay, IGT_PLANE_ZPOS), 1);
>> }
>>
>> +static void
>> +plane_immutable_zpos(igt_display_t *display, igt_pipe_t *pipe,
>> + igt_output_t *output)
>> +{
>> + cairo_t *cr;
>> + int n_planes;
>> + uint32_t format;
>> + struct igt_fb fb_ref;
>> + igt_plane_t *primary;
>> + drmModeModeInfo *mode;
>> + igt_pipe_crc_t *pipe_crc;
>> + igt_crc_t ref_crc, new_crc;
>> + igt_plane_t *plane_lower, *plane_upper;
>> + uint32_t w_lower, h_lower, w_upper, h_upper;
>> +
>> + n_planes = pipe->n_planes;
>> + mode = igt_output_get_mode(output);
>> + primary = igt_pipe_get_plane_type(pipe, DRM_PLANE_TYPE_PRIMARY);
>> +
>> + /* for lower plane */
>> + w_lower = mode->hdisplay;
>> + h_lower = mode->vdisplay;
>> +
>> + /* for upper plane */
>> + w_upper = mode->hdisplay / 2;
>> + h_upper = mode->vdisplay / 2;
>> +
>> + if (intel_gen(display->drm_fd) == 3)
>> + format = DRM_FORMAT_RGB565;
>> + else
>> + format = DRM_FORMAT_ARGB8888;
>
> Let's not make this test intel-only. There should be a function in IGT
> to pick an available format supported by IGT (no matter which one).
Done in v2. I have used XRGB8888 pixel format, i could have used IGT
func to pick an available format but since formats do come with
limitations too..avoided that and used fixed XRGB8888 as used in other
IGTs since this IGT doesn't test pixel formats and format shouldn't be
constraint. Is it okay?
>
>> +
>> + igt_create_color_fb(display->drm_fd,
>> + w_lower, h_lower,
>> + format, I915_TILING_NONE,
>> + 0.0, 0.0, 0.0, &fb_ref);
>> +
>> + cr = igt_get_cairo_ctx(display->drm_fd, &fb_ref);
>> + igt_assert(cairo_status(cr) == 0);
>> + igt_paint_color(cr, 0, 0, w_lower, h_lower, 0.0, 0.0, 1.0);
>> + igt_paint_color(cr, w_upper / 2, h_upper / 2, w_upper, h_upper, 1.0, 1.0, 0.0);
>> + igt_put_cairo_ctx(display->drm_fd, &fb_ref, cr);
>> + igt_plane_set_fb(primary, &fb_ref);
>> + igt_display_commit2(display, COMMIT_ATOMIC);
>
> Isn't that something the other zpos function do too? Maybe extracting it
> into a function would be good? Or make the plane_zpos function take a
> parameter (immutable / mutable)?
No the other mutable zpos doesn't do the same thing, function definition
itself is different since it tests only 2 planes primary and overlay.
And there is no CRC based validation, so no need to drawing reference image.
>
>> +
>> + /* create the pipe_crc object for this pipe */
>> + pipe_crc = igt_pipe_crc_new(pipe->display->drm_fd, pipe->pipe,
>> + INTEL_PIPE_CRC_SOURCE_AUTO);
>> +
>> + /* get reference crc */
>> + igt_pipe_crc_start(pipe_crc);
>> + igt_pipe_crc_get_current(display->drm_fd, pipe_crc, &ref_crc);
>
> Space / tab issue here?
Done in v2
>
>> +
>> + igt_plane_set_fb(primary, NULL);
>> +
>
> A comment here explaining that we want to avoid combinatorial explosion
> and thus only check pairs of planes in an increasing fashion?
Done in v2
>
>> + for (int i = 0; i < n_planes - 1; i++) {
>> + struct igt_fb fb[2];
>> + plane_lower = &display->pipes[pipe->pipe].planes[i];
>> + plane_upper = &display->pipes[pipe->pipe].planes[i + 1];
>> +
>> + igt_require(igt_plane_has_prop(plane_lower, IGT_PLANE_ZPOS));
>> + igt_require(igt_plane_has_prop(plane_upper, IGT_PLANE_ZPOS));
>
> Isn't require leading to a skip if one plane is not supporting the zpos?
> Shouldn't we just continue instead?
Done in v2
>
>> +
>> + if ((plane_lower->type == DRM_PLANE_TYPE_CURSOR) ||
>> + (plane_upper->type == DRM_PLANE_TYPE_CURSOR))
>> + continue;
>
> Why special case the cursor plane? Because of its size?
Yes, cursor needs small buffer size, so avoided that.
>
>> +
>> + igt_create_color_fb(display->drm_fd, w_lower, h_lower,
>> + format, I915_TILING_NONE,
>> + 0.0, 0.0, 1.0, &fb[0]);
>> +
>> + igt_create_color_fb(display->drm_fd, w_upper, h_upper,
>> + format, I915_TILING_NONE,
>> + 1.0, 1.0, 0.0, &fb[1]);
>> +
>> + igt_plane_set_position(plane_lower, 0, 0);
>> + igt_plane_set_fb(plane_lower, &fb[0]);
>> +
>> + igt_plane_set_position(plane_upper, w_upper / 2, h_upper / 2);
>> + igt_plane_set_fb(plane_upper, &fb[1]);
>> +
>> + igt_display_commit2(display, COMMIT_ATOMIC);
>> + igt_pipe_crc_get_current(pipe->display->drm_fd, pipe_crc, &new_crc);
>> +
>> + igt_assert_crc_equal(&ref_crc, &new_crc);
>
> Just a though, since the lower plane is supposed to always cover
> anything under, we could set all the planes under the lower plane to a
> solid red color. This would make sure that lower planes have no
> influence over upper planes.
>
> What do you think?
Since we are validating zpos 2 planes at time, there won't be any plane
below the lower plane, so may be coloring lower planes as red not
required. I tried to accommodate it like committing with plane_max =>
yellow, small size and plane_(max-1) => blue, full screen and rest
planes as red..but for this we need to enable all planes which will lead
to BW issues. Anyhow if we validate p1 & p2, p2 & p3 it automatically
validates p1 & p3 (transitive). Is it okay?
>
>> +
>> + igt_plane_set_fb(plane_lower, NULL);
>> + igt_plane_set_fb(plane_upper, NULL);
>> + }
>> +}
>> +
>> static void plane_overlay(igt_pipe_t *pipe, igt_output_t *output, igt_plane_t *plane)
>> {
>> drmModeModeInfo *mode = igt_output_get_mode(output);
>> @@ -987,14 +1078,20 @@ igt_main
>> plane_primary(pipe_obj, primary, &fb);
>> }
>>
>> - igt_subtest("plane_primary_overlay_zpos") {
>> + igt_subtest("plane_primary_overlay_mutable_zpos") {
>> + /*
>> + * Since i915 driver doesn't support mutable zpos;
>> + * skipping.
>> + */
>> + igt_require(!is_i915_device(display.drm_fd));
>> +
>
> Let it fail / skip, no need to encode in IGT the capabilities of i915.
Done in v2
>
>> uint32_t format_primary = DRM_FORMAT_ARGB8888;
>> uint32_t format_overlay = DRM_FORMAT_ARGB1555;
>>
>> igt_plane_t *overlay =
>> igt_pipe_get_plane_type(pipe_obj, DRM_PLANE_TYPE_OVERLAY);
>> -
>> igt_require(overlay);
>> +
>> igt_require(igt_plane_has_prop(primary, IGT_PLANE_ZPOS));
>> igt_require(igt_plane_has_prop(overlay, IGT_PLANE_ZPOS));
>>
>> @@ -1002,8 +1099,14 @@ igt_main
>> igt_require(igt_plane_has_format_mod(overlay, format_overlay, 0x0));
>>
>> igt_output_set_pipe(output, pipe);
>> - plane_primary_overlay_zpos(pipe_obj, output, primary, overlay,
>> - format_primary, format_overlay);
>> + plane_primary_overlay_mutable_zpos(pipe_obj, output, primary, overlay,
>> + format_primary, format_overlay);
>> + }
>> +
>> + igt_subtest("plane_immutable_zpos") {
>> + igt_require(is_i915_device(display.drm_fd));
>> + igt_output_set_pipe(output, pipe);
>> + plane_immutable_zpos(&display, pipe_obj, output);
>> }
>
> Documentation missing for both the plane_immutable_zpos and
> plane_primary_overlay_mutable_zpos. Since you are now the expert on
> this, it would be nice for you to explain what the tests do as explained
> in
> https://drm.pages.freedesktop.org/igt-gpu-tools/igt-gpu-tools-Core.html#igt-describe
> . Something like "Test that the reported zpos of a plane is correct by
> making sure a full-screen plane covers all other planes with a lower
> zpos, and the plane with the next available zpos is indeed partially
> covering the full-screen plane".
>
Done in v2.
> Otherwise, it looks pretty good. Looks more minor improvements needed
> rather than anything big. Well done!
Thanks Martin for the review.
>
> Martin
>
>>
>> igt_subtest("test_only") {
>> @@ -1011,6 +1114,7 @@ igt_main
>>
>> test_only(pipe_obj, primary, output);
>> }
>> +
>> igt_subtest("plane_cursor_legacy") {
>> igt_plane_t *cursor =
>> igt_pipe_get_plane_type(pipe_obj, DRM_PLANE_TYPE_CURSOR);
>>
--
~Swati Sharma
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
prev parent reply other threads:[~2020-03-12 7:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-26 13:45 [igt-dev] [PATCH i-g-t] tests/kms_atomic: add test to validate immutable zpos Swati Sharma
2020-02-26 15:18 ` [igt-dev] ✗ GitLab.Pipeline: failure for " Patchwork
2020-02-26 16:48 ` [igt-dev] ✓ Fi.CI.BAT: success " Patchwork
2020-02-27 4:49 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2020-02-27 7:03 ` [igt-dev] [PATCH i-g-t] " Martin Peres
2020-02-27 7:31 ` Martin Peres
2020-03-12 8:00 ` Sharma, Swati2
2020-03-12 7:59 ` Sharma, Swati2 [this message]
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=9d91ab7d-db5b-09bd-8579-8a44613804c1@intel.com \
--to=swati2.sharma@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=martin.peres@linux.intel.com \
--cc=petri.latvala@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox