Le 1 juin 2024 04:03:37 GMT+03:00, James Almer <jamr...@gmail.com> a écrit :
>On 5/31/2024 3:18 PM, Rémi Denis-Courmont wrote:
>> ---
>> tests/checkasm/aacencdsp.c | 37 +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>>
>> diff --git a/tests/checkasm/aacencdsp.c b/tests/checkasm/aacencdsp.c
>> index 1756c4ecd5..756f92fd8f 100644
>> --- a/tests/checkasm/aacencdsp.c
>> +++ b/tests/checkasm/aacencdsp.c
>> @@ -22,7 +22,9 @@
>> #include "libavutil/mem_internal.h"
>> +#include "libavcodec/aacenc_utils.h"
>> #include "libavcodec/aacencdsp.h"
>> +#include "libavcodec/aactab.h"
>> #include "checkasm.h"
>> @@ -35,6 +37,8 @@
>> } \
>> } while (0)
>> +#define randomize_elem(tab) (tab[rnd() % FF_ARRAY_ELEMS(tab)])
>> +
>> static void test_abs_pow34(AACEncDSPContext *s)
>> {
>> #define BUF_SIZE 1024
>> @@ -60,6 +64,38 @@ static void test_abs_pow34(AACEncDSPContext *s)
>> report("abs_pow34");
>> }
>> +static void test_quant_bands(AACEncDSPContext *s)
>> +{
>> + int maxval = randomize_elem(aac_cb_maxval);
>> + float q34 = randomize_elem(ff_aac_pow34sf_tab);
>> + float rounding = (rnd() & 1) ? ROUND_TO_ZERO : ROUND_STANDARD;
>> + LOCAL_ALIGNED_32(float, in, [BUF_SIZE]);
>> + LOCAL_ALIGNED_32(float, scaled, [BUF_SIZE]);
>> +
>> + declare_func(void, int *, const float *, const float *, int, int, int,
>> + const float, const float);
>> +
>> + randomize_float(in, BUF_SIZE);
>> + randomize_float(scaled, BUF_SIZE);
>> +
>> + for (int sign = 0; sign <= 1; sign++) {
>> + if (check_func(s->quant_bands, "quant_bands_%s",
>> + sign ? "signed" : "unsigned")) {
>> + LOCAL_ALIGNED_32(int, out, [BUF_SIZE]);
>> + LOCAL_ALIGNED_32(int, out2, [BUF_SIZE]);
>
>Does your RVV implementation expect out to be 32 byte aligned? Because looking
>at aaccoder.c, quant_bands() is called with AACEncContext.qcoefs as argument
>for out, which is 16 byte aligned.
The RVV code requires 32-*bit* alignment for all pointers, i.e. natural
alignment for int and float. I will fix the test case.
(IMO 32 byte alignment is counter-productive on non-x86, but that's a more
general problem.)
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
