[FFmpeg-devel] [PATCH v5] lavc/vvc_mc: R-V V avg w_avg

[flow gg]

Sorry, the previous logic was indeed a bit confusing. I rewrote it,
renaming the third parameter to max_lmul.

If e16 is involved in the function, then vsetvlstatic8  uses max_lmul == m4.
If e32 is involved in the function, then vsetvlstatic8  uses max_lmul == m2.

If e16 is involved in the function, then vsetvlstatic16 uses max_lmul == m8.
If e32 is involved in the function, then vsetvlstatic16 uses max_lmul == m4.

I think it is clearer now.

Rémi Denis-Courmont <remi at remlab.net> 于2024年7月8日周一 23:41写道：

> Le maanantaina 1. heinäkuuta 2024, 19.09.01 EEST flow gg a écrit :
> > I reviewed it again, the purpose of is_w is to limit lmul to a maximum of
> > 1/4 of vlen,
>
> 1/4 of vlen? Do you mean limit to EMUL=1 for EEW=32 and EMUL=1/4 for EEW=8?
>
> Limiting LMUL to less than 1 at maximum EEW is useless from a functional
> standpoint, since fractional registers cannot be addressed individually.
> (Of
> course it might still be useful for performance reasons.)
>
> > to prevent vector register shortage, which can also be
> > considered as vset limiting lmul. I renamed it to quarter_len_limit.
>
> TBH, I don't really understand.
>
> If a lower LMUL limit is reached, then specialisations for the
> corresponding
> VLEN are simply unncessary/infeasible and the code for lower VLEN should
> be
> used.
>
> If a higher LMUL limit is reached due to register pressure (or the 8 hard
> limit), then the given VLEN cannot be supported at all, or requires some
> completely different code.
>
> Either way, I don't really follow why vsetvlfixed macros need to be
> involved.
>
> --
> 雷米‧德尼-库尔蒙
> http://www.remlab.net/
>
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>