Le 30 avril 2024 11:22:31 GMT+03:00, flow gg a écrit :
>Since the number of stores is controlled by a3 and not by zero, it doesn't
>have to be exactly 16 bytes ?
Yeah ok, I get it now
>
>Rémi Denis-Courmont 于2024年4月30日周二 14:40写道：
>
>>
>>
>> Le 30 avril 2024 03:26:25 GMT+03:00, flow gg a
>> é
Since the number of stores is controlled by a3 and not by zero, it doesn't
have to be exactly 16 bytes ？
Rémi Denis-Courmont 于2024年4月30日周二 14:40写道：
>
>
> Le 30 avril 2024 03:26:25 GMT+03:00, flow gg a
> écrit :
> >Hi, I initially used a loop, but according to libavcodec/blockdsp.h,
> >
> >the m
Le 30 avril 2024 03:26:25 GMT+03:00, flow gg a écrit :
>Hi, I initially used a loop, but according to libavcodec/blockdsp.h,
>
>the maximum is 8x16 = 128 bytes, so using ff_get_rv_vlenb() >= 16 and m8
>does not require a loop.
It's okay to assume that VLENB is at least 16 bytes (as long as it's
Since there is no 8x16, I changed m8 to m4, and updated it in the reply
flow gg 于2024年4月30日周二 08:26写道：
> Hi, I initially used a loop, but according to libavcodec/blockdsp.h,
>
> the maximum is 8x16 = 128 bytes, so using ff_get_rv_vlenb() >= 16 and m8
> does not require a loop.
>
> ```
> /* add
Hi, I initially used a loop, but according to libavcodec/blockdsp.h,
the maximum is 8x16 = 128 bytes, so using ff_get_rv_vlenb() >= 16 and m8
does not require a loop.
```
/* add and put pixel (decoding)
* Block sizes for op_pixels_func are 8x4,8x8 16x8 16x16.
* h for op_pixels_func is limited t
Le maanantaina 29. huhtikuuta 2024, 10.09.41 EEST flow gg a écrit :
>
Are you sure that this works with all vector lengths?
The block8 code looks odd.
--
レミ・デニ-クールモン
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://
