Thank you for the detailed explanation. One more question: I understand
that assembly code needs to be further broken down, but what's the issue
with adding this code to the init section of the C code here? I think this
C code is just mimicking the init section of the C code in x86.
Rémi Denis-Cou
Le tiistaina 30. heinäkuuta 2024, 20.57.28 EEST flow gg a écrit :
> 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).
To the contrary, if vectors are too sho
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 certa
Hi,
Le lauantaina 22. kesäkuuta 2024, 18.58.03 EEST u...@foxmail.com a écrit :
> From: sunyuechi
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 eve
From: sunyuechi
X60 new
vp8_put_bilin16_h_c: 42.542.5
vp8_put_bilin16_h_rvv_i32 :4.7 3.2
vp8_put_bilin16_hv_c : 71.571.7
vp8_put_bili
