linux-kernel - Re: [PATCH 2/2] drm/vkms: Use a simpler composition function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240207104407.7b06bac2@eldfell>
Date: Wed, 7 Feb 2024 10:44:07 +0200
From: Pekka Paalanen <pekka.paalanen@...oniitty.fi>
To: Arthur Grillo <arthurgrillo@...eup.net>
Cc: Miquel Raynal <miquel.raynal@...tlin.com>, Maíra Canal
 <mairacanal@...eup.net>, Maxime Ripard <mripard@...nel.org>, Louis Chauvet
 <louis.chauvet@...tlin.com>, Rodrigo Siqueira
 <rodrigosiqueiramelo@...il.com>, Melissa Wen <melissa.srw@...il.com>,
 Haneen Mohammed <hamohammed.sa@...il.com>, Daniel Vetter <daniel@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Thomas Zimmermann
 <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
 marcheu@...gle.com, seanpaul@...gle.com, nicolejadeyee@...gle.com,
 dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 thomas.petazzoni@...tlin.com
Subject: Re: [PATCH 2/2] drm/vkms: Use a simpler composition function

On Tue, 6 Feb 2024 14:57:48 -0300
Arthur Grillo <arthurgrillo@...eup.net> wrote:

> On 02/02/24 16:45, Pekka Paalanen wrote:

..

> > Would it be possible to have a standardised benchmark specifically
> > for performance rather than correctness, in IGT or where-ever it
> > would make sense? Then it would be simple to tell contributors to
> > run this and report the numbers before and after.
> > 
> > I would propose this kind of KMS layout:
> > 
> > - CRTC size 3841 x 2161
> > - primary plane, XRGB8888, 3639 x 2161 @ 101,0
> > - overlay A, XBGR2101010, 3033 x 1777 @ 201,199
> > - overlay B, ARGB8888, 1507 x 1400 @ 1800,250
> > 
> > The sizes and positions are deliberately odd to try to avoid happy
> > alignment accidents. The planes are big, which should let the pixel
> > operations easily dominate performance measurement. There are
> > different pixel formats, both opaque and semi-transparent. There is
> > lots of plane overlap. The planes also do not cover the whole CRTC
> > leaving the background visible a bit.
> > 
> > There should be two FBs per each plane, flipped alternatingly each
> > frame. Writeback should be active. Run this a number of frames, say,
> > 100, and measure the kernel CPU time taken. It's supposed to take at
> > least several seconds in total.
> > 
> > I think something like this should be the base benchmark. One can
> > add more to it, like rotated planes, YUV planes, etc. or switch
> > settings on the existing planes. Maybe even FB_DAMAGE_CLIPS. Maybe
> > one more overlay that is very tall and thin.
> > 
> > Just an idea, what do you all think?  
> 
> Hi Pekka,
> 
> I just finished writing this proposal using IGT.
> 
> I got pretty interesting results:
> 
> The mentioned commit 8356b97906503a02125c8d03c9b88a61ea46a05a took
> around 13 seconds. While drm-misc/drm-misc-next took 36 seconds.
> 
> I'm currently bisecting to be certain that the change to the
> pixel-by-pixel is the culprit, but I don't see why it wouldn't be.
> 
> I just need to do some final touches on the benchmark code and it
> will be ready for revision.

Awesome, thank you very much for doing that!
pq

Content of type "application/pgp-signature" skipped