Re: [FFmpeg-devel] [PATCH] lavc/pixblockdsp: specialise aligned 16-bit get_pixels - Rémi Denis-Courmont

From: "Rémi Denis-Courmont" <remi@remlab.net>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] lavc/pixblockdsp: specialise aligned 16-bit get_pixels
Date: Thu, 25 Jul 2024 19:50:03 +0300
Message-ID: <2363450.mWMiMU8PXi@basile.remlab.net> (raw)
In-Reply-To: <70b707b4-eafd-44a2-b418-6b56dfd07841@gmail.com>

Le torstaina 25. heinäkuuta 2024, 19.16.21 EEST James Almer a écrit :
> On 7/25/2024 12:53 PM, Rémi Denis-Courmont wrote:
> > The current code assumes that we have unaligned rows, which hurts on
> > platforms with slower unaligned accesses. (Also, this lets the compiler
> > unroll manually, which it seems to do in practice.)
> > ---
> > 
> >   libavcodec/pixblockdsp.c | 9 ++++++++-
> >   1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/pixblockdsp.c b/libavcodec/pixblockdsp.c
> > index bbbeca1618..1fff244511 100644
> > --- a/libavcodec/pixblockdsp.c
> > +++ b/libavcodec/pixblockdsp.c
> > @@ -26,6 +26,13 @@
> > 
> >   static void get_pixels_16_c(int16_t *restrict block, const uint8_t
> >   *pixels,
> >   
> >                               ptrdiff_t stride)
> 
> Is there a way to hint the compiler that block is 16 byte aligned? GCC
> 14 at least emits unaligned loads and stores for these.

We don't have uint128_t, so the best we could do is cast to uint64_t *. Though 
GCC 13 emits 64-bit loads and stores on RV64 here with the given code. Is this 
maybe a problem with the COPY128 macro definition on x86?

-- 
Rémi Denis-Courmont
http://www.remlab.net/

_______________________________________________
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".