From cac1b6f085231f245e8e8367f05793442b9ebd9b Mon Sep 17 00:00:00 2001 From: Sergey Fedorov Date: Sat, 15 Aug 2026 20:35:37 +0000 Subject: [PATCH 32/38] avcodec/ppc: tuning pass 3 from PowerVLC's real-7447A bench PowerVLC (github.com/Olsro/powervlc) ships this tree's AltiVec series in their VLC PowerPC port and ran a full checkasm --bench of all 507 registered kernels on a real 1.42 GHz 7447A Mac mini G4 (2026-08-07) -- the patched-G4 data our per-CPU gates had been waiting for. Registration changes only; every kernel stays compiled. Off everywhere (was off on the 970 only, now measured losing on the G4 too): - aacpsdsp hybrid_analysis: 0.63x vs C on the 7447A (127.6 vs 80.6 ticks); was 0.46x on the 970. - vp8dsp put_vp8_pixels16: 0.64x vs C on the 7447A (12.1 vs 7.8 ticks, with the byte-precise store), +4.3% CPU end-to-end on a 480p VP8 decode before they dropped it; was 0.46x on the 970. - h264qpel put 8-wide mc00 (ff_put_pixels8_altivec underneath): PowerVLC measured their own variant of the same plain copy -- with a cheaper lvsr+stvewx store than our read-modify-write splice -- at 0.75x on the 7447A, so ours can only do worse; was 0.42x on the 970. The avg mc00 entry was already C everywhere; now put is too, and the save/restore in ff_h264qpel_init_ppc is unconditional. The hpeldsp registration of the same kernel is dropped in the following commit. Confirmed correct by the same data, no change needed: - VP9 TX_4X4 itxfm family: WINS on the 7447A (adst_adst 1.35x, dct_adst 1.26x, dct_dct sub2/sub4 1.18x; only the eob==1 DC path 0.82x), so the existing #ifndef _ARCH_PWR4 gate (on for G4, off for G5) is exactly right. - hpeldsp avg_pixels8 0.69x and h264dsp h_loop_filter_luma 0.66x on the 7447A: both already unregistered everywhere. - idct_add16intra measured 1.07x on their 7447A build vs 0.52x on our stock-G4 run -- cross-build noise on a small-tick entry; stays unregistered (tiny stakes either way). G5 note: PowerVLC builds their shared contribs with -mcpu=7400, so their G5-side numbers reflect G4 scheduling and are not used here; all G5 decisions continue to rest on our own +G5 benches. Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_01PRRFPPzH3qXUcq8Ask5LZh --- libavcodec/ppc/aacpsdsp.c | 12 +++++++----- libavcodec/ppc/h264qpel.c | 14 ++++++-------- libavcodec/ppc/vp8dsp_altivec.c | 12 ++++++++---- 3 files changed, 21 insertions(+), 17 deletions(-) diff --git a/libavcodec/ppc/aacpsdsp.c b/libavcodec/ppc/aacpsdsp.c index 35063ba..b79da14 100644 --- a/libavcodec/ppc/aacpsdsp.c +++ b/libavcodec/ppc/aacpsdsp.c @@ -129,10 +129,12 @@ av_cold void ff_psdsp_init_ppc(PSDSPContext *s) return; s->add_squares = ps_add_squares_altivec; -#ifndef _ARCH_PWR4 /* 970: 0.46x vs C (strong scalar FPU, and the kernel - * gathers its filter taps element-wise); 7447A data - * pending */ - s->hybrid_analysis = ps_hybrid_analysis_altivec; -#endif + /* hybrid_analysis is NOT registered on any CPU: 0.46x vs C on a 970 + * (strong scalar FPU, and the kernel gathers its filter taps + * element-wise), and the 7447A data point now exists — 0.63x vs C + * (127.6 vs 80.6 ticks), measured by PowerVLC (github.com/Olsro/powervlc) + * with checkasm --bench on a 1.42 GHz Mac mini G4, 2026-08-07. A loss on + * both target CPUs, so the former G5-only gate becomes unconditional. + * The kernel stays compiled (av_unused) for a one-line revert. */ #endif } diff --git a/libavcodec/ppc/h264qpel.c b/libavcodec/ppc/h264qpel.c index d04cacc..ede4a44 100644 --- a/libavcodec/ppc/h264qpel.c +++ b/libavcodec/ppc/h264qpel.c @@ -372,19 +372,17 @@ av_cold void ff_h264qpel_init_ppc(H264QpelContext *c, int bit_depth) #if HAVE_BIGENDIAN { /* 8-wide mc00 is a plain 8x8 copy/avg (ff_put/avg_pixels8_altivec - * underneath): put loses to C on the 970 (0.42x); avg loses on - * both (7447A 0.80x; 970 0.51x on the 2026-07-30 re-bench — - * an earlier 2.46x reading did not reproduce) — keep the C - * entries there. */ -#ifdef _ARCH_PWR4 + * underneath) and loses to C on both target CPUs: put 0.42x / + * avg 0.51x on the 970; on the 7447A, avg measured 0.80x here + * and PowerVLC (github.com/Olsro/powervlc) measured put 0.75x / + * avg 0.82x (2026-08-07) for their variant with a cheaper + * lvsr+stvewx store, so ours can only do worse. Keep the C + * entries for both. */ qpel_mc_func put8_mc00_c = c->put_h264_qpel_pixels_tab[1][0]; -#endif qpel_mc_func avg8_mc00_c = c->avg_h264_qpel_pixels_tab[1][0]; dspfunc(put_h264_qpel, 1, 8); dspfunc(avg_h264_qpel, 1, 8); -#ifdef _ARCH_PWR4 c->put_h264_qpel_pixels_tab[1][0] = put8_mc00_c; -#endif c->avg_h264_qpel_pixels_tab[1][0] = avg8_mc00_c; } #endif diff --git a/libavcodec/ppc/vp8dsp_altivec.c b/libavcodec/ppc/vp8dsp_altivec.c index f25742e..b86b365 100644 --- a/libavcodec/ppc/vp8dsp_altivec.c +++ b/libavcodec/ppc/vp8dsp_altivec.c @@ -363,10 +363,14 @@ av_cold void ff_vp78dsp_init_ppc(VP8DSPContext *c) if (!PPC_ALTIVEC(av_get_cpu_flags())) return; -#ifndef _ARCH_PWR4 /* 970: 0.46x vs C (with the byte-precise unaligned store; - * an aligned-dst fast path could win it back — future work) */ - c->put_vp8_epel_pixels_tab[0][0][0] = put_vp8_pixels16_altivec; -#endif + /* put_vp8_pixels16 is NOT registered on any CPU: 0.46x vs C on a 970 + * (with the byte-precise unaligned store), and now also 0.64x vs C on a + * 7447A (12.1 vs 7.8 ticks) — measured by PowerVLC + * (github.com/Olsro/powervlc) with checkasm --bench on a 1.42 GHz Mac + * mini G4, 2026-08-07, who also saw +4.3% CPU end-to-end on a 480p VP8 + * decode before dropping it. A loss on both target CPUs, so the former + * G5-only gate becomes unconditional. An aligned-dst fast path could win + * it back on both — future work; the kernel stays compiled (av_unused). */ c->put_vp8_epel_pixels_tab[0][0][2] = put_vp8_epel16_h6_altivec; c->put_vp8_epel_pixels_tab[0][2][0] = put_vp8_epel16_v6_altivec; c->put_vp8_epel_pixels_tab[0][2][2] = put_vp8_epel16_h6v6_altivec; -- 2.43.0