From: Pekka Paalanen <pekka.paalanen@haloniitty.fi>
To: Arthur Grillo <arthurgrillo@riseup.net>
Cc: dri-devel@lists.freedesktop.org, igt-dev@lists.freedesktop.org,
"Petri Latvala" <adrinael@adrinael.net>,
"Arkadiusz Hiler" <arek@hiler.eu>,
"Kamil Konieczny" <kamil.konieczny@linux.intel.com>,
"Juha-Pekka Heikkila" <juhapekka.heikkila@gmail.com>,
"Bhanuprakash Modem" <bhanuprakash.modem@intel.com>,
"Ashutosh Dixit" <ashutosh.dixit@intel.com>,
"Louis Chauvet" <louis.chauvet@bootlin.com>,
"Rodrigo Siqueira" <rodrigosiqueiramelo@gmail.com>,
"Melissa Wen" <melissa.srw@gmail.com>,
"Maíra Canal" <mairacanal@riseup.net>,
"Haneen Mohammed" <hamohammed.sa@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>
Subject: Re: [PATCH i-g-t] benchmarks: Add VKMS benchmark
Date: Fri, 9 Feb 2024 10:32:11 +0200 [thread overview]
Message-ID: <20240209103211.4f7e9fc6@eldfell> (raw)
In-Reply-To: <738490ac-56a9-4408-8de7-63de059d0a54@riseup.net>
[-- Attachment #1: Type: text/plain, Size: 4599 bytes --]
On Thu, 8 Feb 2024 16:38:31 -0300
Arthur Grillo <arthurgrillo@riseup.net> wrote:
> On 08/02/24 06:50, Pekka Paalanen wrote:
> > On Wed, 07 Feb 2024 17:17:15 -0300
> > Arthur Grillo <arthurgrillo@riseup.net> wrote:
> >
> >> Create a benchmark for the VKMS driver. Use a KMS layout with deliberate
> >> odd sizes to try to avoid alignment accidents and run it for FRAME_COUNT
> >> frames flipping framebuffers in each plane.
> >>
> >> Link: https://lore.kernel.org/all/20240202214527.1d97c881@ferris.localdomain/
> >> Suggested-by: Pekka Paalanen <pekka.paalanen@haloniitty.fi>
> >> Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net>
> >> ---
> >> This benchmark was suggested by Pekka Paalanen on [1] to better analyse
> >> possible performance regression on the Virtual Kernel Modesetting(VKMS)
> >> driver.
> >>
> >> With this benchmark I was able to determine two performance regression:
> >>
> >> - 322d716a3e8a ("drm/vkms: isolate pixel conversion functionality")
> >> - cc4fd2934d41 ("drm/vkms: Isolate writeback pixel conversion functions")
> >>
> >> [1]: https://lore.kernel.org/all/20240202214527.1d97c881@ferris.localdomain/
> >> ---
> >> benchmarks/meson.build | 1 +
> >> benchmarks/vkms_stress.c | 203 +++++++++++++++++++++++++++++++++++++++++++++++
> >> 2 files changed, 204 insertions(+)
> >>
> >> diff --git a/benchmarks/meson.build b/benchmarks/meson.build
> >> index c451268bc44f..3aa66d6dffe2 100644
> >> --- a/benchmarks/meson.build
> >> +++ b/benchmarks/meson.build
> >> @@ -20,6 +20,7 @@ benchmark_progs = [
> >> 'kms_vblank',
> >> 'prime_lookup',
> >> 'vgem_mmap',
> >> + 'vkms_stress',
> >> ]
> >>
> >> benchmarksdir = join_paths(libexecdir, 'benchmarks')
> >> diff --git a/benchmarks/vkms_stress.c b/benchmarks/vkms_stress.c
> >> new file mode 100644
> >> index 000000000000..b9128c208861
> >> --- /dev/null
> >> +++ b/benchmarks/vkms_stress.c
...
> >> +
> >> +igt_simple_main
> >> +{
> >> + struct data_t data;
> >> + enum pipe pipe = PIPE_NONE;
> >> +
> >> + data.kms = default_kms;
> >> +
> >
> > Hi Arthur,
> >
> > all the above looks really good!
> >
> > Some things below look strange to me, but I don't know the igt API.
> >
> >> + data.fd = drm_open_driver_master(DRIVER_ANY);
> >> +
> >> + igt_display_require(&data.display, data.fd);
> >> +
> >> + kmstest_set_vt_graphics_mode();
> >> +
> >> + igt_display_require(&data.display, data.fd);
> >
> > Are you supposed to call igt_display_require twice?
> >
>
> Only this way the writeback connector appears. I took this from
> `tests/kms_writeback.c`.
>
> I now did a bit of lore.kernel.org archaeology and found why this is
> necessary:
>
> Rodrigo Siqueira sent this patch:
> https://lore.kernel.org/all/20190306213005.7hvbnwl7dohr3vuv@smtp.gmail.com/
>
> It places drmSetClientCap() before drmModeGetResources(). (The patch
> description is wrong, as noted by [1])
>
> Without this, you don't need to call igt_display_require() twice. I
> don't know if this patch is wrong, but it is good to bring it up for
> discussion.
Hi Arthur,
did you mean "*With* this, you don't need to call igt_display_require()
twice."?
All DRM client caps do need to be set before any call to GetResources
or anything else, exactly because the client caps change the kernel
side behaviour. Client caps may also hide things, not only expose
things, at least in the future if not already (color pipelines will
replace legacy color properties).
If you need to check DRM (kernel) caps, that should be done immediately
after setting DRM client caps. I think that's the most logical and
safest order.
Thanks,
pq
>
> [1]: https://lore.kernel.org/all/20190318104128.GH26454@e110455-lin.cambridge.arm.com/
>
> >> + igt_require(data.display.is_atomic);
> >> +
> >> + igt_display_require_output(&data.display);
> >> +
> >> + igt_require(data.wb_output);
> >> + igt_display_reset(&data.display);
> >> +
> >> + data.wb_output = find_wb_output(&data);
> >
> > Should igt_require(data.wb_output) be after find_wb_output?
> >
> >> +
> >> + for_each_pipe(&data.display, pipe) {
> >> + igt_debug("Selecting pipe %s to %s\n",
> >> + kmstest_pipe_name(pipe),
> >> + igt_output_name(data.wb_output));
> >> + igt_output_set_pipe(data.wb_output, pipe);
> >
> > Isn't this strange if there are multiple pipes?
>
> Yeah, I forgot to place a `break;` there.
>
> All the others comments will be addressed on v2.
>
> Best Regards,
> ~Arthur Grillo
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-02-09 8:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-07 20:17 [PATCH i-g-t] benchmarks: Add VKMS benchmark Arthur Grillo
2024-02-07 21:10 ` ✓ CI.xeBAT: success for " Patchwork
2024-02-07 21:16 ` ✓ Fi.CI.BAT: " Patchwork
2024-02-08 1:29 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-02-08 9:50 ` [PATCH i-g-t] " Pekka Paalanen
2024-02-08 19:38 ` Arthur Grillo
2024-02-09 8:32 ` Pekka Paalanen [this message]
2024-02-09 17:29 ` Arthur Grillo
2024-02-12 8:43 ` Pekka Paalanen
2024-02-08 11:25 ` Kamil Konieczny
2024-02-08 12:51 ` Juha-Pekka Heikkila
2024-02-08 14:05 ` Kamil Konieczny
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=20240209103211.4f7e9fc6@eldfell \
--to=pekka.paalanen@haloniitty.fi \
--cc=adrinael@adrinael.net \
--cc=arek@hiler.eu \
--cc=arthurgrillo@riseup.net \
--cc=ashutosh.dixit@intel.com \
--cc=bhanuprakash.modem@intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hamohammed.sa@gmail.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=juhapekka.heikkila@gmail.com \
--cc=kamil.konieczny@linux.intel.com \
--cc=louis.chauvet@bootlin.com \
--cc=mairacanal@riseup.net \
--cc=melissa.srw@gmail.com \
--cc=rodrigosiqueiramelo@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