send them, or just by
implementation accident.
--
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-
Le tiistaina 14. marraskuuta 2023, 17.56.24 EET Tomas Härdin a écrit :
> Ballots should be public IMO, secret voting is cowardice.
The French (XIXth century) Empire used notoriously public ballots, and the
results were skewed to say the least. There is a good reason why ballots are
supposed to
Le tiistaina 14. marraskuuta 2023, 20.44.18 EET Nicolas George a écrit :
> Nothing prevents their boss from telling them how to vote, even if the
> ballots are secret.
Ultimately, nothing prevents their boss from literally telling them how to
vote. But obviously unless the boss is actively
flac_decorrelate_indep2_32_c: 981.7
flac_decorrelate_indep2_32_rvv_i32: 183.7
flac_decorrelate_indep4_32_c: 1749.7
flac_decorrelate_indep4_32_rvv_i32: 362.5
flac_decorrelate_indep6_32_c: 2517.7
flac_decorrelate_indep6_32_rvv_i32: 715.2
flac_decorrelate_indep8_32_c: 3285.7
flac_decorrelate_indep2_16_c:981.7
flac_decorrelate_indep2_16_rvv_i32: 199.2
flac_decorrelate_indep4_16_c: 1749.7
flac_decorrelate_indep4_16_rvv_i32: 401.2
flac_decorrelate_indep6_16_c: 2517.7
flac_decorrelate_indep6_16_rvv_i32: 858.0
flac_decorrelate_indep8_16_c:
Le 15 novembre 2023 00:27:29 GMT+02:00, "Kumar, Rahul via ffmpeg-devel"
a écrit :
>Hi All,
>
>I am trying to reduce the size of ffmpeg.exe for using it to convert RTSP
>streams to HLS.
That is a complex matter that requires professional support. So please consider
hiring a consultant. You
) += riscv/pixblockdsp_init.o \
diff --git a/libavcodec/riscv/llauddsp_init.c b/libavcodec/riscv/llauddsp_init.c
new file mode 100644
index 00..ea023f73e6
--- /dev/null
+++ b/libavcodec/riscv/llauddsp_init.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright © 2023 Rémi Denis-Courmont.
+ *
+ * This file
scalarproduct_and_madd_int32_c: 10899.7
scalarproduct_and_madd_int32_rvv_i32: 1749.0
---
libavcodec/riscv/llauddsp_init.c | 4
libavcodec/riscv/llauddsp_rvv.S | 26 ++
2 files changed, 30 insertions(+)
diff --git a/libavcodec/riscv/llauddsp_init.c
Better performance can probably be achieved with a more intricate
unrolled loop, but this is a start:
add_hfyu_left_pred_bgr32_c: 15084.0
add_hfyu_left_pred_bgr32_rvv_i32: 10280.2
This would actually be cleaner with the RISC-V P extension, but that is
not ratified yet (I think?) and usually not
---
tests/checkasm/huffyuvdsp.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/tests/checkasm/huffyuvdsp.c b/tests/checkasm/huffyuvdsp.c
index 6ba27e267f..a08f5a8391 100644
--- a/tests/checkasm/huffyuvdsp.c
+++ b/tests/checkasm/huffyuvdsp.c
@@ -64,6 +64,34 @@
---
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/llauddsp.c | 115 ++
4 files changed, 120 insertions(+)
create mode 100644 tests/checkasm/llauddsp.c
diff --git
Hi,
This seems to show that the SSSE3 optimisation is no better than the SSE2, at
least on my AMD Ryzen. Does anyone know why it's there? Should it be purged?
Br,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Le 13 novembre 2023 11:07:21 GMT+02:00, Paul B Mahol a écrit
:
>On Mon, Nov 13, 2023 at 7:42 AM Rémi Denis-Courmont wrote:
>
>> Hi,
>>
>> This seems to show that the SSSE3 optimisation is no better than the SSE2,
>> at least on my AMD Ryzen. Does anyo
Hi,
Le maanantaina 13. marraskuuta 2023, 11.43.01 EET flow gg a écrit :
> Sorry for the long delay in responding.
No problem. Working with T-Head C910 (or C920?) cores is very tedious. I gave
up on that and switched over to Kendryte K230 (based on C908) now.
> How is the modified patch now?
Le maanantaina 13. marraskuuta 2023, 11.17.57 EET Rémi Denis-Courmont a écrit
:
> Le 13 novembre 2023 11:07:21 GMT+02:00, Paul B Mahol a
écrit :
> >On Mon, Nov 13, 2023 at 7:42 AM Rémi Denis-Courmont
wrote:
> >> Hi,
> >>
> >> This seems to show that the
Le lauantaina 11. marraskuuta 2023, 13.15.37 EET Nicolas George a écrit :
> Rémi Denis-Courmont (12023-11-11):
> > 1) As far as was communicated, the total of alleged discrepancies in the
> > voter list could not affect the result. That makes the vote valid in my
> > book,
Le sunnuntaina 5. marraskuuta 2023, 12.02.05 EET Anton Khirnov a écrit :
> Anyone else wishing to volunteer for TC or CC, please reply to this
> email.
I hereby "volunteer" for the CC.
For those who don't know me, I am a research engineer in system software
working for a large telecommunication
should go without spelling it out but such community-hostile attitude seems
very ill-advised to me for somebody who is running for CC election or
reelection.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@f
Le torstaina 9. marraskuuta 2023, 18.50.52 EET Michael Niedermayer a écrit :
> that said, i checked ML subscribers and found
> 16 of the people above to be currently subscribed with email addresses
> that i found by greping their name. (not posting the list due to privacy
> concerns)
Thing is, if
With explicit unrolling, we can skip half of the sign bit flips, and
the compiler is then better able to optimise the scalar loop:
predictor_c: 31376.0 (before)
predictor_c: 23703.0 (after)
---
libavcodec/exrdsp.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff
Hi,
How did you test it? As per
http://ffmpeg.org/pipermail/ffmpeg-devel/2023-June/310720.html we still don't
have a FATE instance set up with the RISC-V Vector extension. The only testing
consists of my manual runs of checkasm on a K230 board. (We *do* have Zba and
Zbb now though, hence the
uldn't exist.
>
>> ALU right before dependent conditional branch should be avoided.
>
>Should the sub be moved forward? I've modified it.
>
>> SHxADD can be used advantageously.
>
>Okay, I've made the modification
>
>Rémi Denis-Courmont 于2023年11月22日周三 21:41写道：
&
Hi,
+
+.macro bilin_h_load dst len
+.ifc \len,4
+vsetivlizero, 5, e8, mf2, ta, ma
Don't use fractional multipliers if you don't mix element widths.
+.elseif \len == 8
+vsetivlizero, 9, e8, m1, ta, ma
+.else
+vsetivlizero, 17, e8, m2, ta, ma
Le 17 avril 2024 21:58:32 GMT+08:00, Michael Niedermayer
a écrit :
>Hi all
>
>The pace of inovation in FFmpeg has been slowing down.
>Most work is concentarted nowadays on code refactoring, and adding
>support for new codecs and formats.
OSS projects of age similar to FFmpeg are either mature
Hi,
I have been dragged privately into this issue so for the sake of transparency,
I will just sum up my side here.
Le 17 avril 2024 07:21:18 GMT+08:00, Devin Heitmueller
a écrit :
>Hello all,
>
>I wasn't looking to start trouble, but I didn't see any discussion of
>this on the mailing list
sting_003f-1
>
>
>> Le 22 avril 2024 04:25:20 GMT+08:00, Thilo Borgmann via ffmpeg-devel
>> a écrit :
>>> Hi,
>>>
>>> On 21.04.24 10:47, Rémi Denis-Courmont wrote:
>>>> Hi,
>>>>
>>>> I have been dragged privately into
Hi,
Thilo is calling Kieran, myself and presumably Derek and JB trolls.
This seems to be a pattern against anyone who disagrees with him.
Le 22 avril 2024 04:25:20 GMT+08:00, Thilo Borgmann via ffmpeg-devel
a écrit :
>Hi,
>
>On 21.04.24 10:47, Rémi Denis-Courmont wrote:
>> H
Le 21 avril 2024 23:40:08 GMT+03:00, Michael Niedermayer
a écrit :
>On Sun, Apr 21, 2024 at 05:11:36PM +0800, Rémi Denis-Courmont wrote:
>>
>>
>> Le 17 avril 2024 21:58:32 GMT+08:00, Michael Niedermayer
>> a écrit :
>> >Hi all
>> >
>> >
h },
> * but never larger than 16 and never smaller than 4. */
>typedef void (*op_fill_func)(uint8_t *block /* align width (8 or 16) */,
> uint8_t value, ptrdiff_t line_size, int h);
>```
>
>Rémi Denis-Courmont 于2024年4月30日周二 01:31写道：
>
>>
secure. But even if you don't agree with that
assessment, the fact of the matter is that they are not portable.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg
Le sunnuntaina 7. huhtikuuta 2024, 8.38.54 EEST flow gg a écrit :
> ping
I have been away for a while, and catching up takes time, sorry.
--
レミ・デニ-クールモン
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
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
Le 28 avril 2024 23:11:48 GMT+03:00, Lynne a écrit :
>Apr 28, 2024, 20:15 by r...@remlab.net:
>
>> Le torstaina 11. huhtikuuta 2024, 10.50.01 EEST Lynne a écrit :
>>
>>> Is there a reason why we can't switch to IPv4 addresses mapped
>>> in IPv6 and just use the IPv6 API everywhere?
>>>
>>
>>
Le 29 avril 2024 11:20:24 GMT+03:00, Lynne a écrit :
>> >They were they deprecated?
>>
>> They caused more bugs than they solved problems (because what we need is to
>> add IPv6 to IPv4 apps, not IPv4 to IPv6 apps).
>>
>
>What bugs did they cause?
Obviously anything that assumes IPv6
vcodec/riscv/ac3dsp_rvvb.S b/libavcodec/riscv/ac3dsp_rvvb.S
new file mode 100644
index 00..64766b56be
--- /dev/null
+++ b/libavcodec/riscv/ac3dsp_rvvb.S
@@ -0,0 +1,43 @@
+/*
+ * Copyright © 2023 Rémi Denis-Courmont.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redis
---
Makefile | 2 +-
configure | 3 +++
doc/APIchanges| 3 +++
ffbuild/arch.mak | 1 +
libavutil/cpu.c | 1 +
libavutil/cpu.h | 1 +
libavutil/tests/cpu.c | 1 +
tests/checkasm/checkasm.c | 1 +
8 files changed, 12
This requires Linux kernel version 6.8 or later.
---
libavutil/riscv/cpu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
index 69d1afe853..3cf4e25bc9 100644
--- a/libavutil/riscv/cpu.c
+++ b/libavutil/riscv/cpu.c
@@ -54,6 +54,10 @@ int
Le 3 mai 2024 14:28:59 GMT+03:00, "Ronald S. Bultje" a
écrit :
>Hi,
>
>On Fri, May 3, 2024 at 1:53 AM Rémi Denis-Courmont wrote:
>
>> Le 2 mai 2024 21:38:13 GMT+03:00, "Ronald S. Bultje"
>> a écrit :
>> >On Thu, May 2, 2024 at 1:4
Le 3 mai 2024 15:58:50 GMT+03:00, "Ondřej Fiala" a écrit :
>On Fri May 3, 2024 at 7:46 AM CEST, Rémi Denis-Courmont wrote:
>> Le 2 mai 2024 22:32:16 GMT+03:00, "Ondřej Fiala" a écrit
>> :
>> >On Thu May 2, 2024 at 4:38 PM CEST, Rémi Denis-Courmont
If we have to wait for a CLI workflow, for
which no credible development plan exist, then we are stuck with email, and
this is exactly "block[ing] allowing more prople to convert to a gitlab-style
workflow".
--
Rémi Denis-Courmont
http://www.remlab.net/
__
Le perjantaina 3. toukokuuta 2024, 15.58.50 EEST Ondřej Fiala a écrit :
> > And in the end, I could be wrong, but I haven't seen you doing much code
> > review here. This is all about optimising the workflow for people doing
> > code reviews and code merges, so why do you even care?
>
> Because
Hi,
To preserve my own sanity as a volunteer, and until/unless FFmpeg moves to a
different code review workflow, I will *only* be reviewing code submitted in
git-format-patch format. That is to say in-line.
If you do not like it, you are most welcome to support a change to a non-mail-
This adds the Linux-specific function call to detect CPU features. Unlike
the more portable auxillary vector, this supports extensions other than
single lettered ones. At this point, FFmpeg already needs this to detect
Zba and Zbb at run-time, and probably will need it for Zvbb in the near
future.
This reindents code to prepare for the next changeset.
No functional changes.
---
libavutil/riscv/cpu.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
index 460d3e9f91..984293aef0 100644
---
SiFive U74:
ac3_exponent_min_reuse0_c: 10.0
ac3_exponent_min_reuse0_rvb_b:8.0
ac3_exponent_min_reuse1_c: 2924.7
ac3_exponent_min_reuse1_rvb_b: 1803.0
ac3_exponent_min_reuse2_c: 5043.0
ac3_exponent_min_reuse2_rvb_b: 2827.5
ac3_exponent_min_reuse3_c: 7028.7
Le perjantaina 3. toukokuuta 2024, 20.30.16 EEST Ondřej Fiala a écrit :
> > You can't expect the whole community to accomodate your unwillingness to
> > run a web browser or update a ridiculous underprovisioned computer
> > system.
> There is a huge difference between running a web browser and
Le tiistaina 30. huhtikuuta 2024, 2.36.22 EEST flow gg a écrit :
> updated it in the reply and https://github.com/hleft/FFmpeg/tree/vp8vp9
VP9 checkasm does not pass on that branch.
> Rémi Denis-Courmont 于2024年4月30日周二 01:57写道：
>
> > Le perjantaina 22. maaliskuuta 2024, 8.02.
Le torstaina 2. toukokuuta 2024, 17.25.06 EEST Ondřej Fiala a écrit :
> On Wed May 1, 2024 at 7:27 AM CEST, Rémi Denis-Courmont wrote:
> > Le 30 avril 2024 22:15:10 GMT+03:00, "Ondřej Fiala" a
écrit :
> > >On Tue Apr 30, 2024 at 9:06 PM CEST, Hendrik Leppk
10; bit_depth++) {
> +for (i = 0; i < 5; i++) {
> +bit_depth = depths[i];
> ff_h264dsp_init(, bit_depth, 1);
> for (sz = 4; sz <= 8; sz += 4) {
> randomize_buffers();
Fine with me, but then again, this is not RISC-V-specific, and other peo
Le keskiviikkona 24. huhtikuuta 2024, 17.09.43 EEST J. Dekker a écrit :
> Signed-off-by: J. Dekker
> ---
> libavfilter/riscv/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/riscv/Makefile b/libavfilter/riscv/Makefile
> index
Le keskiviikkona 17. huhtikuuta 2024, 21.01.37 EEST Ramiro Polla a écrit :
> Reviewed-by: Martin Storsjö
> ---
> tests/checkasm/Makefile | 1 +
> tests/checkasm/checkasm.c | 3 ++
> tests/checkasm/checkasm.h | 1 +
> tests/checkasm/fdctdsp.c | 68 +++
>
Le lauantaina 4. toukokuuta 2024, 17.48.30 EEST u...@foxmail.com a écrit :
> From: sunyuechi
>
> C908:
> vp8_put_pixels4_c: 87.5
> vp8_put_pixels4_rvv_i32: 42.7
> vp8_put_pixels8_c: 284.5
> vp8_put_pixels8_rvv_i32: 77.7
> vp8_put_pixels16_c: 1087.7
> vp8_put_pixels16_rvv_i32: 108.0
> ---
>
Le lauantaina 4. toukokuuta 2024, 21.02.25 EEST Rémi Denis-Courmont a écrit :
> Le lauantaina 4. toukokuuta 2024, 17.48.31 EEST u...@foxmail.com a écrit :
> > From: sunyuechi
> >
> > C908:
> > vp8_put_bilin4_h_c: 373.5
> > vp8_put_bilin4_h_rvv_i32: 158
Le lauantaina 4. toukokuuta 2024, 13.01.05 EEST u...@foxmail.com a écrit :
> From: sunyuechi
>
> vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_c: 869.7
> vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_rvv_i32: 148.7
> vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_c: 220.5
> vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_rvv_i64:
Le lauantaina 4. toukokuuta 2024, 17.48.31 EEST u...@foxmail.com a écrit :
> From: sunyuechi
>
> C908:
> vp8_put_bilin4_h_c: 373.5
> vp8_put_bilin4_h_rvv_i32: 158.7
> vp8_put_bilin8_h_c: 1437.7
> vp8_put_bilin8_h_rvv_i32: 318.7
> vp8_put_bilin16_h_c: 2845.7
> vp8_put_bilin16_h_rvv_i32: 374.7
>
Will merge soon.
--
レミ・デニ-クールモン
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-requ...@ffmpeg.org with subject
&& flags & AV_CPU_FLAG_RVV_I64 && ff_get_rv_vlenb() >=
> 16) { dsp->intra_pred[TX_8X8][DC_PRED] = ff_dc_8x8_rvv;
> dsp->intra_pred[TX_8X8][LEFT_DC_PRED] = ff_dc_left_8x8_rvv;
> @@ -53,9 +61,10 @@ static av_cold void
> vp9dsp_intrapred_init_rvv(VP9DSPContext *dsp, int bpp
---
libavcodec/riscv/blockdsp_init.c | 2 +-
libavcodec/riscv/g722dsp_init.c | 2 +-
libavcodec/riscv/h264_chroma_init_riscv.c | 2 +-
libavcodec/riscv/idctdsp_init.c | 2 +-
libavcodec/riscv/me_cmp_init.c| 2 +-
libavcodec/riscv/pixblockdsp_init.c |
This inline function checks that the vector length is at least a given
value. With this, most run-time VLEN checks can be optimised away.
---
libavutil/riscv/cpu.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/libavutil/riscv/cpu.h b/libavutil/riscv/cpu.h
index
---
libavcodec/riscv/vp9dsp_init.c | 50 +-
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/libavcodec/riscv/vp9dsp_init.c b/libavcodec/riscv/vp9dsp_init.c
index 69ab39004c..6863c486c8 100644
--- a/libavcodec/riscv/vp9dsp_init.c
+++
tions remain, how changing from MF2 to MF4 affects performance on
Zvl256b, and if it does, how to deal with that without breaking support for
Zvl128b.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
8_put_pixels4_c: 84.0
vp8_put_pixels4_rvi: 3871.0
vp8_put_pixels8_c: 331.0
vp8_put_pixels8_rvi: 11281.2
vp8_put_pixels16_c: 826.0
vp8_put_pixels16_rvi: 22502.0
Best guess is that the data is not 64-bit aligned, otherwise I can't really
make sense of those figures.
--
Rémi Denis-Cou
Not all C run-times support this, and even then, it will be a while
before distributions provide recent enough versions thereof.
Since this is a trivial system call wrapper, we might just as well call
the corresponding kernel system call directly where the C run-time lacks
support but the kernel
---
libavutil/cpu.c | 1 +
libavutil/cpu.h | 1 +
libavutil/riscv/cpu.c | 3 +++
libavutil/tests/cpu.c | 3 ++-
tests/checkasm/checkasm.c | 1 +
5 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index 396eeb38d6..9ac2f01c20
They are actually awfully slow if the CPU does not support misaligned
accesses natively, so only use them if misaligned accesses are fast.
---
libavcodec/riscv/vp8dsp_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/riscv/vp8dsp_init.c
The B Bit manipulation extension was not defined to this day, and
probably never will. Instead it was broken down into Zba, Zbb, Zbc and
Zbs with no particular blessed set to make up B.
This removes the bogus field test. Linux never set this bit, nor
(AFAICT) did FreeBSD or any other OS. We can
---
libavcodec/riscv/flacdsp_init.c | 13 ++---
libavcodec/riscv/flacdsp_rvv.S | 4 ++--
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/libavcodec/riscv/flacdsp_init.c b/libavcodec/riscv/flacdsp_init.c
index 0d7cff8bfe..77ffd09244 100644
---
While this function can easily be written with vectors, it just fails to
get any performance improvement.
For reference, this is a simpler loop-free implementation that does get
better performance than the current one depending on hardware, but still
more or less the same metrics as the C code:
v;
#endif
}
diff --git a/libavcodec/riscv/startcode_rvv.S b/libavcodec/riscv/startcode_rvv.S
new file mode 100644
index 00..7c43b1d7f3
--- /dev/null
+++ b/libavcodec/riscv/startcode_rvv.S
@@ -0,0 +1,44 @@
+/*
+ * Copyright © 2024 Rémi Denis-Courmont.
+ *
+ * Redistribution and use in
@@
+/*
+ * Copyright © 2024 Rémi Denis-Courmont.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1
Le sunnuntaina 12. toukokuuta 2024, 13.55.14 EEST Rémi Denis-Courmont a écrit
:
> ---
> libavcodec/riscv/Makefile| 1 +
> libavcodec/riscv/h264dsp_init.c | 3 +++
> libavcodec/riscv/startcode_rvv.S | 44
> libavcodec/riscv/vc1ds
Le perjantaina 10. toukokuuta 2024, 11.21.14 EEST u...@foxmail.com a écrit :
> From: sunyuechi
>
> C908 X60
> vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_c: 14.7 13.2
> vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_rvv_i32 : 2.5 2.2
>
And then 64-bit shift and 64-bit element stores which are
half as fast as 32-bit ones on weighed basis.
Maybe widening signed multiplication would be faster though, I will try that.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mail
T-Head C908:
flac_wasted_33_c: 786.2
flac_wasted_33_rvv_i64: 486.5
---
libavcodec/riscv/flacdsp_init.c | 4
libavcodec/riscv/flacdsp_rvv.S | 16
2 files changed, 20 insertions(+)
diff --git a/libavcodec/riscv/flacdsp_init.c b/libavcodec/riscv/flacdsp_init.c
index
Le sunnuntaina 12. toukokuuta 2024, 13.55.13 EEST Rémi Denis-Courmont a écrit
:
> ---
> libavcodec/h264dsp.c | 2 +
> libavcodec/h264dsp.h | 2 +
> libavcodec/riscv/Makefile| 2 +
> libavcodec/riscv/h264dsp_init.c | 40
>
id)
> if (check_func(h.lpc32, "flac_lpc_32_%d", pred_orders[i]))
> check_lpc(pred_orders[i], 32);
>
> +if (check_func(h.wasted32, "flac_wasted_32"))
> +check_wasted32();
> +
> report("lpc");
Missing report?
> }
--
Rémi Den
T-Head C908:
flac_wasted_32_c: 949.0
flac_wasted_32_rvv_i32: 278.7
---
libavcodec/riscv/flacdsp_init.c | 7 ++-
libavcodec/riscv/flacdsp_rvv.S | 15 +++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/libavcodec/riscv/flacdsp_init.c
T-Head C908:
flac_wasted_33_c: 1040.0
flac_wasted_33_rvv_i64: 711.2
---
libavcodec/riscv/flacdsp_init.c | 4
libavcodec/riscv/flacdsp_rvv.S | 16
2 files changed, 20 insertions(+)
diff --git a/libavcodec/riscv/flacdsp_init.c b/libavcodec/riscv/flacdsp_init.c
index
Le 13 mai 2024 20:06:34 GMT+03:00, Lynne via ffmpeg-devel
a écrit :
>On 13/05/2024 18:43, Rémi Denis-Courmont wrote:
>> While this function can easily be written with vectors, it just fails to
>> get any performance improvement.
>>
>> For reference, this is a simpl
Le 5 mai 2024 02:51:59 GMT+03:00, Michael Niedermayer
a écrit :
>Fixes: CID1454676 Out-of-bounds read
It's a stretch to call this "fixing". It just asserts that the situation
doesn't happen, in other words, that it is a false positive from the static
analyser.
The code change looks OK, but
Le 6 mai 2024 04:23:07 GMT+03:00, Michael Niedermayer
a écrit :
>Fixes: CID1439574 Dereference after null check
If SPS is guaranteed to be non-NULL, there should probably be an assertion to
document it, and it should be *before* that alleged dereference (which is not
visible in the patch
Le maanantaina 6. toukokuuta 2024, 20.18.39 EEST Ramiro Polla a écrit :
> Reviewed-by: Martin Storsjö
> Reviewed-by: Rémi Denis-Courmont
> ---
> tests/checkasm/Makefile | 1 +
> tests/checkasm/checkasm.c | 3 ++
> tests/checkasm/checkasm.h | 1 +
> tests/che
ome to fix
it anyway of course.
--
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-requ...@ffmpeg.
Le maanantaina 6. toukokuuta 2024, 6.38.06 EEST u...@foxmail.com a écrit :
> From: sunyuechi
>
> C908:
> vp8_put_epel4_h4v4_c: 20.0
> vp8_put_epel4_h4v4_rvv_i32: 11.0
> vp8_put_epel4_h4v6_c: 25.2
> vp8_put_epel4_h4v6_rvv_i32: 13.5
> vp8_put_epel4_h6v4_c: 22.2
> vp8_put_epel4_h6v4_rvv_i32: 14.5
>
dsp_init.c
> @@ -59,6 +59,9 @@ static av_cold void
> vp9dsp_intrapred_init_riscv(VP9DSPContext *dsp, int bpp)
> dsp->intra_pred[TX_16X16][DC_129_PRED] = ff_dc_129_16x16_rvv;
> dsp->intra_pred[TX_32X32][TOP_DC_PRED] = ff_dc_top_32x32_rvv;
> dsp->intra_pred[TX_16X16][TOP
Le maanantaina 6. toukokuuta 2024, 6.38.02 EEST u...@foxmail.com a écrit :
> From: sunyuechi
>
> C908:
> vp8_put_bilin4_h_c: 367.0
> vp8_put_bilin4_h_rvv_i32: 137.7
> vp8_put_bilin4_v_c: 377.0
> vp8_put_bilin4_v_rvv_i32: 137.7
> vp8_put_bilin8_h_c: 1431.0
> vp8_put_bilin8_h_rvv_i32: 297.5
>
Le tiistaina 7. toukokuuta 2024, 19.07.46 EEST flow gg a écrit :
> I didn't understand what you mean... What does judging whether the type is
> 'h' or 'v' have to do with the number?
== is only valid over numeric values, not identifiers.
--
レミ・デニ-クールモン
http://www.remlab.net/
---
libavcodec/riscv/aacpsdsp_rvv.S | 2 +-
libavcodec/riscv/opusdsp_rvv.S | 2 +-
libavcodec/riscv/sbrdsp_rvv.S | 8
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/riscv/aacpsdsp_rvv.S b/libavcodec/riscv/aacpsdsp_rvv.S
index a79d7d7818..2d6858688a 100644
---
libavutil/riscv/asm.S | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavutil/riscv/asm.S b/libavutil/riscv/asm.S
index 0a9e2e0d3f..9d76ab5617 100644
--- a/libavutil/riscv/asm.S
+++ b/libavutil/riscv/asm.S
@@ -36,13 +36,16 @@
#define HWD
#endif
-
This is no longer necessary as Zbb is now always explicitly required.
---
libavutil/riscv/asm.S | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavutil/riscv/asm.S b/libavutil/riscv/asm.S
index 9d76ab5617..14be5055f5 100644
--- a/libavutil/riscv/asm.S
+++ b/libavutil/riscv/asm.S
@@
---
libswscale/riscv/rgb2rgb_rvv.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libswscale/riscv/rgb2rgb_rvv.S b/libswscale/riscv/rgb2rgb_rvv.S
index 21e30ab8bb..19f7aaf67d 100644
--- a/libswscale/riscv/rgb2rgb_rvv.S
+++ b/libswscale/riscv/rgb2rgb_rvv.S
@@ -165,10
---
libavutil/riscv/cpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
index c3683b06d0..69d1afe853 100644
--- a/libavutil/riscv/cpu.c
+++ b/libavutil/riscv/cpu.c
@@ -29,14 +29,14 @@
#include
#define HWCAP_RV(letter) (1ul
---
libavcodec/riscv/vp9_intra_rvv.S | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavcodec/riscv/vp9_intra_rvv.S b/libavcodec/riscv/vp9_intra_rvv.S
index db9774c263..40e38ba83e 100644
--- a/libavcodec/riscv/vp9_intra_rvv.S
+++ b/libavcodec/riscv/vp9_intra_rvv.S
Le 7 mai 2024 23:34:14 GMT+03:00, "Martin Storsjö" a écrit :
>On Tue, 7 May 2024, Rémi Denis-Courmont wrote:
>
>> ---
>> Makefile | 2 +-
>> configure | 3 +++
>> doc/APIchanges| 3 +++
>> ffbuild/arch.mak
---
Makefile | 2 +-
configure | 3 +++
doc/APIchanges| 3 +++
ffbuild/arch.mak | 1 +
libavutil/cpu.h | 1 +
libavutil/tests/cpu.c | 1 +
tests/checkasm/checkasm.c | 1 +
7 files changed, 11 insertions(+), 1 deletion(-)
diff
This requires Linux kernel version 6.8 or later.
---
libavutil/riscv/cpu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
index 69d1afe853..3cf4e25bc9 100644
--- a/libavutil/riscv/cpu.c
+++ b/libavutil/riscv/cpu.c
@@ -54,6 +54,10 @@ int
vcodec/riscv/ac3dsp_rvvb.S b/libavcodec/riscv/ac3dsp_rvvb.S
new file mode 100644
index 00..64766b56be
--- /dev/null
+++ b/libavcodec/riscv/ac3dsp_rvvb.S
@@ -0,0 +1,43 @@
+/*
+ * Copyright © 2023 Rémi Denis-Courmont.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redis
re you not detecting this at runtime?
XLEN is a compile time constant of the ABI. You cannot run 32-bit code in 64-
bit mode, and the ELF loader will not allow you to do so.
--
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-requ...@ffmpeg.org with subject "unsubscribe".
Le 14 mai 2024 10:37:20 GMT+03:00, "Tomas Härdin" a écrit :
>Formal methods would be better than the heuristics coverity uses.
That sounds like wishful thinking, or at least a distant pipe dream. Lets stick
to what is possible and realistic today, please.
And I don't think that it would be
This calculates the optimal vector type value at run-time based on the
hardware vector length and the FLAC LPC prediction order. In this
particular case, the additional computation is easily amortised over
the loop iterations:
T-Head C908: CV before V after
flac_lpc_16_13:
501 - 600 of 956 matches
Mail list logo
