Re: [FFmpeg-devel] [PATCH 1/4] lavc/vp8dsp: R-V V 256 bilin,epel

[flow gg <hlefthleft@gmail.com>]

Hi, these four patches have v2 (although the first one seems to be the
same).

From my understanding, moving from supporting only 128b to adding 256b
versions can simultaneously improve LMUL and solve some issues related to
insufficient vector registers (vvc, vp9).
This can be very helpful in certain situations.

If we continue to support 512, 1024, ..., it almost exclusively improves
LMUL. Therefore, 256b is the most worthwhile addition, and we can skip
adding 512b, 1024b, etc.

Additionally, even though longer hardware will continually be developed,
the most used will probably still be 128b and 256b.
If someone complains that FFmpeg's RVV doesn't support 1024b well, it can
be said that it's not just RISC-V that lacks good support.
However, if the 256b performance is not good, then it seems like an issue
with RISC-V. :)

I think maybe we can give some preference to the two smallest lengths?

Rémi Denis-Courmont <remi@remlab.net> 于2024年7月29日周一 22:45写道：

>         Hi,
>
> Le lauantaina 22. kesäkuuta 2024, 18.58.03 EEST uk7b@foxmail.com a écrit :
> > From: sunyuechi <sunyuechi@iscas.ac.cn>
>
> In my opinion, we can't keep on like this. By the end of year, there will
> also
> be 512-bit vector hardware. In the worst case, specialisation on vector
> length
> could require 7 variants of every function, as many as legal LMUL values.
>
> Generating the LMUL at run time or initialisation time is too slow for
> fixed-
> size functions, so I can only see two viable options here:
>
> 1) We ignore this problem entirely and only optimise to 128-bit or to the
> current minimum VLEN. The intent of the specification is ostensibly that
> processing should scale according to the current value of VL, not
> VTYPE.LMUL.
> That is why the minimum legal LMUL value is SEW/ELEN rather than 1/VLMAX
> (and
> draft versions did not even have fractional multipliers).
>
> 2) The specialisation code is heavily factored, including in the C
> initialisation side.
>
> Personally, I prefer to ignore the problem until we see more mature and
> varied
> hardware. I do note that SiFive is ostensibly not specialising their code
> by
> VLEN, which tends to confirm that this is just a case of immature design
> from
> T-Head.
>
> --
> 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".
>
_______________________________________________
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".