Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: "Martin Storsjö" <martin@martin.st>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] checkasm: vvc_alf: Limit benchmarking to a reasonable subset of functions
Date: Tue, 21 May 2024 13:15:50 +0300 (EEST)
Message-ID: <e78192f-c8a7-d776-ae34-325de34fd16@martin.st> (raw)
In-Reply-To: <20240521100429.87090-1-martin@martin.st>

On Tue, 21 May 2024, Martin Storsjö wrote:

> Don't benchmark every single combination of widths and heights;
> only benchmark cases which are squares (like in vvc_mc.c).
>
> Contrary to vvc_mc, which increases sizes by doubling dimensions,
> vvc_alf tests all sizes in increments of 4. Limit benchmarking to
> the cases which are powers of two.
>
> This reduces the number of benchmarked cases from 3072 down to 18.
> ---
> tests/checkasm/vvc_alf.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/tests/checkasm/vvc_alf.c b/tests/checkasm/vvc_alf.c
> index 9526260598..6dd89bfafc 100644
> --- a/tests/checkasm/vvc_alf.c
> +++ b/tests/checkasm/vvc_alf.c
> @@ -103,7 +103,9 @@ static void check_alf_filter(VVCDSPContext *c, const int bit_depth)
>                     if (memcmp(dst0 + i * dst_stride, dst1 + i * dst_stride, w * SIZEOF_PIXEL))
>                         fail();
>                 }
> -                bench_new(dst1, dst_stride, src1 + offset, src_stride, w, h, filter, clip, vb_pos);
> +                // Bench only square sizes, and ones with dimensions being a power of two.
> +                if (w == h && (w & (w - 1)) == 0)
> +                    bench_new(dst1, dst_stride, src1 + offset, src_stride, w, h, filter, clip, vb_pos);
>             }
>             if (check_func(c->alf.filter[CHROMA], "vvc_alf_filter_chroma_%dx%d_%d", w, h, bit_depth)) {
>                 const int vb_pos = ctu_size - ALF_VB_POS_ABOVE_CHROMA;
> @@ -115,7 +117,8 @@ static void check_alf_filter(VVCDSPContext *c, const int bit_depth)
>                     if (memcmp(dst0 + i * dst_stride, dst1 + i * dst_stride, w * SIZEOF_PIXEL))
>                         fail();
>                 }
> -                bench_new(dst1, dst_stride, src1 + offset, src_stride, w, h, filter, clip, vb_pos);
> +                if (w == h && (w & (w - 1)) == 0)
> +                    bench_new(dst1, dst_stride, src1 + offset, src_stride, w, h, filter, clip, vb_pos);
>             }
>         }
>     }
> @@ -156,7 +159,9 @@ static void check_alf_classify(VVCDSPContext *c, const int bit_depth)
>                     fail();
>                 if (memcmp(transpose_idx0, transpose_idx1, id_size))
>                     fail();
> -                bench_new(class_idx1, transpose_idx1, src1 + offset, stride, w, h, vb_pos, alf_gradient_tmp);
> +                // Bench only square sizes, and ones with dimensions being a power of two.
> +                if (w == h && (w & (w - 1)) == 0)
> +                    bench_new(class_idx1, transpose_idx1, src1 + offset, stride, w, h, vb_pos, alf_gradient_tmp);

Note, these tests (all vvc tests) use check_func("name...%dx%d", w, h) - 
while it's common elsewhere to group them up into slightly bigger bundles, 
e.g. only including the width in the function name, assuming that this is 
the level of granularity of actual assembly implementations - e.g. I don't 
think there would be a different codepath implemented for each block 
height.

And it's possible to convey more information about exactly what failed, 
without needing to encode it into the function name - see the 
checkasm_check functions/macro, and e.g. commit 
8ff4a4a4f4f73c5e276fa0cbe6cd5a148ebdd4ae.

// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  reply	other threads:[~2024-05-21 10:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-21 10:04 Martin Storsjö
2024-05-21 10:15 ` Martin Storsjö [this message]
2024-05-21 12:38   ` Nuo Mi
2024-05-21 11:10 ` Rémi Denis-Courmont
2024-05-21 12:31   ` Nuo Mi

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=e78192f-c8a7-d776-ae34-325de34fd16@martin.st \
    --to=martin@martin.st \
    --cc=ffmpeg-devel@ffmpeg.org \
    /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

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git