been cited.
As far as FFmpeg(-devel) is concerned, I can't think how it could/should
reasonably get any more specific than that.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/
To whom it may concern,
It has come to Remlab Tmi's attention that the FATE samples suite has recently
been abused to contain non-multimedia files. This is a breach of your trust and
we feel that this is totally inappropriate. The FATE instances were explicitly
setup and sponsored by Tmi
Le 9 août 2023 15:02:45 GMT+03:00, David Rosca a écrit :
>Support for allocating frames with x2rgb10 format was added
>in c00264f5013, this adds support for importing DMA-BUFs.
>---
> libavutil/hwcontext_vaapi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git
Le tiistaina 8. elokuuta 2023, 18.22.49 EEST Michael Niedermayer a écrit :
> > > That is missing that people suggest a path forward but
> > > with too few details to easily walk that path.
> >
> > Uh, I hate to state the patently obvious, but if "no path forward is
> > needed", then there should
Le 23 juin 2023 20:12:41 GMT+02:00, Michael Niedermayer
a écrit :
>Hi
>
>On Fri, Jun 23, 2023 at 06:37:18PM +0200, Rémi Denis-Courmont wrote:
>> Hi,
>>
>> Le 23 juin 2023 13:17:28 GMT+02:00, Michael Niedermayer
>> a écrit :
>> >On Fri, Jun 23, 202
Hi,
Le 30 juin 2023 21:02:36 GMT+03:00, Michael Niedermayer
a écrit :
>On Fri, Jun 30, 2023 at 07:40:53PM +0200, Michael Niedermayer wrote:
>> On Fri, Jun 30, 2023 at 04:38:46PM +0200, Jean-Baptiste Kempf wrote:
>> > On Fri, 30 Jun 2023, at 16:08, Michael Niedermayer wrote:
>> > > Also as said
Le 29 juin 2023 22:42:17 GMT+03:00, Paul B Mahol a écrit :
>On Thu, Jun 29, 2023 at 9:35 PM Andreas Rheinhardt <
>andreas.rheinha...@outlook.com> wrote:
>
>> Paul B Mahol:
>> > On Thu, Jun 29, 2023 at 8:18 PM Andreas Rheinhardt <
>> > andreas.rheinha...@outlook.com> wrote:
>> >
>> >> The
Hi,
Le 2 juillet 2023 13:08:54 GMT+03:00, Paul B Mahol a écrit :
>On Sun, Jul 2, 2023 at 11:40 AM Nicolas George wrote:
>
>> Michael Niedermayer (12023-06-30):
>> > And if we could put it in git master then people could work together to
>> > build the libavradio out of it as we all want.
>> >
Le sunnuntaina 25. kesäkuuta 2023, 1.19.04 EEST Nicolas George a écrit :
> Michael Niedermayer (12023-06-23):
> > * What iam interrested in was working with the signals at a low level, why
> > because i find it interresting and fun.
>
> Then this is what you should be spending your time on, and
Le torstaina 15. kesäkuuta 2023, 13.36.41 EEST Peiting Shen a écrit :
> From: Shen Peiting
>
> Vector instructions replaces scalar options of float convert to fixed
>
> Benchmarks on Spike(cycles):
> len=16
> float_to_fixed24_c: 315
> float_to_fixed24_rvv: 27
> len=160
> float_to_fixed24_c:
v0, (t2), t0
> +vmv.s.x v8, t4
> +sub t3, t3, t1
> +vredminu.vs v8, v0, v8
> +vmv.x.s t4, v8
> +bnezt3, 2b
> +vsetivlit1, 1, e8
When you're not using the output, so u
can enforce tail-call optimisation.
Since this is assembler, you can count on tail-call optimisation. This is
really just one `li` and `j` added on the 2 and 4.
Not that I could measure the actual impact of either approaches.
--
Rémi Denis-Courmont
http://ww
broken code once
> they do exist. And no one wants to debug someone else's
> assembly.
>
> Those results look far too optimistic, and I'm guessing
> it's because they're using a theoretical huge vector size
> limit. Could you re-test with something more realistic,
> like 256
Hi,
Le 23 juin 2023 13:17:28 GMT+02:00, Michael Niedermayer
a écrit :
>On Fri, Jun 23, 2023 at 10:34:10AM +0800, Kieran Kunhya wrote:
>> FFmpeg is not the place for SDR. SDR is as large and complex as the
>> entirety of multimedia.
>>
>> What next, is FFmpeg going to implement TCP in
---
configure | 2 ++
libavutil/riscv/cpu.c | 54 ---
2 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/configure b/configure
index ed9efad985..8cad88cdd2 100755
--- a/configure
+++ b/configure
@@ -5412,6 +5412,8 @@ elif enabled
xponents_rvb: 1167
FWIW, RV-Zbb can be benchmarked on real hardware.
I would have done it already if only there was a checkasm case for this.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
ht
Le torstaina 15. kesäkuuta 2023, 13.36.42 EEST Peiting Shen a écrit :
> From: Shen Peiting
>
> Scalar calculating int32 sum_square optimized by using RVV instructions
>
> Benchmarks on Spike(cycles):
> len=128
> ac3_sum_square_butterfly_int32_c: 8497
> ac3_sum_square_butterfly_int32_rvv: 258
>
Hi,
Not really. My old key had to be revoked, so it should probably not be listed
there.
(Sorry for top post)
Le 4 mai 2023 21:59:29 GMT+03:00, James Almer a écrit :
>On 5/3/2023 1:10 PM, Rémi Denis-Courmont wrote:
>> ---
>> MAINTAINERS | 1 +
>> 1 file changed, 1 ins
r future optimization.
Well most likely. The thing is though that nobody in the FFmpeg community
(except you) has hardware access in any shape or form at this time, at least
that I'd know. That's one of the reasons why my own efforts have stalled.
>
>
>On Wed, May 10, 2023 at 12:51 AM Rémi Den
Le 15 mai 2023 05:38:22 GMT+08:00, Michael Niedermayer
a écrit :
>> >
>> > But lets consider:
>> > file:///home/myname/myfile.m3u8?file.avi
>> > /home/myname/myfile.m3u8?file.avi
>> > http:/server/myfile.m3u8?file.avi
>> >
>> > The first is odd, iam not sure what "?file.avi" is and i wonder
cal
file exists by interleaving local and remote URLs in a playlist.
In practice, this is a well-known issue and has been for two at least decades,
and the "solution" is to limit what the open file can do. To state the obvious
extreme, one wouldn't want to execute a shell script or an
, Guillaume Poirier
Amiga / PowerPC Colin Ward
Linux / PowerPC Lauri Kasanen
+RISC-V Rémi Denis-Courmont
Windows MinGW Alex Beregszaszi, Ramiro Polla
Windows Cygwin
Nit: different
But is there an actual threat model whence it is necessary or even useful for a
media framework to implement origin policies? On top of my head, this can be
used by content providers to prevent third parties from referencing their media
files... but that seems user-hostile; it
Hi,
Le tiistaina 9. toukokuuta 2023, 12.50.25 EEST Arnie Chang a écrit :
> We are submitting a set of patches that significantly improve H.264 decoding
> performance by utilizing RVV intrinsic code.
I believe that there is a general dislike of compiler intrinsic for vector
optimisations
Le keskiviikkona 17. toukokuuta 2023, 10.13.01 EEST Arnie Chang a écrit :
> Optimize the put and avg filtering for 8x8 chroma blocks
>
> Signed-off-by: Arnie Chang
> ---
> libavcodec/h264chroma.c | 2 +
> libavcodec/h264chroma.h | 1 +
>
Le keskiviikkona 17. toukokuuta 2023, 17.54.22 EEST Lynne a écrit :
> Finally, run:
> make checkasm && ./tests/checkasm/checkasm --bench
> and report on the timings for both the C and assembly versions.
> If you've made a mistake somewhere, (forgot to restore stack, or a
> callee-saved register,
Le lauantaina 20. toukokuuta 2023, 10.27.19 EEST Hao Chen a écrit :
> From: yuanhecai
>
> This patch supports the use of the "checkasm --bench" testing feature
> on loongarch platform.
>
> Change-Id: I42790388d057c9ade0dfa38a19d9c1fd44ca0bc3
> ---
> libavutil/loongarch/timer.h | 48
Le perjantaina 19. toukokuuta 2023, 21.52.57 EEST Lynne a écrit :
> May 19, 2023, 19:16 by r...@remlab.net:
> > Le keskiviikkona 17. toukokuuta 2023, 17.54.22 EEST Lynne a écrit :
> >> Finally, run:
> >> make checkasm && ./tests/checkasm/checkasm --bench
> >> and report on the timings for both the
Le keskiviikkona 17. toukokuuta 2023, 17.54.22 EEST Lynne a écrit :
> Finally, run:
> make checkasm && ./tests/checkasm/checkasm --bench
> and report on the timings for both the C and assembly versions.
> If you've made a mistake somewhere, (forgot to restore stack, or a
> callee-saved register,
Hi,
Le 4 février 2024 21:28:44 GMT+02:00, Michael Niedermayer
a écrit :
>On Sun, Feb 04, 2024 at 03:38:43PM +0100, Rémi Denis-Courmont wrote:
>> Hi,
>>
>> Le 4 février 2024 14:41:15 GMT+01:00, Michael Niedermayer
>> a écrit :
>> >Hi
>> &
e16, m2, tu, ma
> vmax.vv v16, v16, v20
> add a2, a2, a3
> vwadd.wvv24, v24, v16
> bneza4, 1b
>
> vsetvli zero, zero, e32, m4, ta, ma
> vwredsumu.vsv0, v24, v0
> vmv.x.s
lse64.v works
just fine; we're already using it. There's also the possibility of segmented
strided loads, or simply multiple unit loads.
In any case, unrolling one way or other should improve performance.
>
>
>
>Rémi Denis-Courmont 于2024年2月9日周五 03:41写道：
>
>> Le keskiviikk
eckasm tests off because of broken legacy code.
--
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-deve
Le perjantaina 2. helmikuuta 2024, 3.14.39 EET flow gg a écrit :
> Ok, updated it in the reply
Sorry I meant directive, not macro. .rept is just fine here.
--
レミ・デニ-クールモン
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Hi,
I think you cna use vwadd here?
--
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
Le keskiviikkona 31. tammikuuta 2024, 19.58.55 EET flow gg a écrit :
> Fixed the rv32 break in this reply
It looks like widening add would avoid the sign extension.
Although you'd need as many instructions, since V lacks signed to unsigned
clipping.
--
Rémi Denis-Courmont
h
Hi,
To avoid repeating the code, you can either use .repr or .irp. You can even
use assembler conditionals to elide the redundant code on the last iteration.
--
レミ・デニ-クールモン
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
qually with no cross-row calculations. This might
require trickery or not work at all for those functions that subtract adjacent
values. But your patchset seems to leave those out anyway.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg
Le lauantaina 10. helmikuuta 2024, 11.14.11 EET Rémi Denis-Courmont a écrit :
> But your patchset seems to leave those out anyway.
Nevermind that bit, I missed other mails
--
レミ・デニ-クールモン
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffm
Happy new year,
The gains are -unsurprisingly- modest here. Did you try to reorder
instructions to improve scheduling?
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman
Le perjantaina 9. helmikuuta 2024, 21.22.17 EET Timo Rothenpieler a écrit :
> On 13.01.2024 16:46, Timo Rothenpieler wrote:
> > FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
> > which then end up heap-allocated.
> > By declaring any variable in a struct, or tree of structs,
Hi,
Le 13 février 2024 18:22:46 GMT+02:00, Nicolas George a écrit
:
>Martin Storsjo (12024-02-13):
>> The main arguments raised were about API consistency, prevention of
>> accidental inclusions, as well as explicitness in marking a field as
>> public or private.
>
>Too bad the committee
Le 20 février 2024 16:01:11 GMT+02:00, Michael Niedermayer
a écrit :
>On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
>[...]
>> their preferred wording, and then we can have the GA vote on it.
>
>Before this GA vote, we need another extra member discussion/vote.
>Because the
ests, the most
effective way around them is to keep diverse membership in the TC to counter-
balance conflicted members.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailma
Le tiistaina 6. helmikuuta 2024, 17.56.32 EET flow gg a écrit :
>
Did you try to compute integral absolute values with the ad-hoc (floating
point) instruction instead of vneg/vmax? It should work since the sign is in
the same place, though I don't know if it will be faster.
--
レミ・デニ-クールモン
an just repeating the 8 regular loads, and it won't work
if you need calculations between rows.
I may be missing something but I don't understand what purpose the header file
serves here?
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel maili
Le lauantaina 17. helmikuuta 2024, 13.46.27 EET Gyan Doshi a écrit :
> As a TC member who is part of the disagreement, I believe your
> participation is recused.
Obviously not. We don't want to get into a situation whence TC members have an
incentive not to participate in regular code reviews
Le sunnuntaina 18. helmikuuta 2024, 14.27.56 EET flow gg a écrit :
> ping
Patch does not apply here.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffm
Hi,
I'm not sure why you're mixing element sizes this way, but the code should not
even compile due to mismatched extensions.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https
Hi,
To sum a vector, you should only reduce once at the end of the function, c.f.
how it's done in existing scalar products. Reduction instructions are
(intrinsically) slow.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing
Le 7 février 2024 14:16:51 GMT+02:00, Nicolas George a écrit :
>Paul B Mahol (12024-02-06):
>> If this is again about SDR, go ahead, merge it. I no longer care.
>
>You should care. But you should care by being FOR it, not AGAINST.
>
>The people who oppose SDR are the same libav people who are
t1, 13 * 13 * 3
mul t0, t0, t1
Also the second vsetvl seems pointless, unless you specifically meant that the
pointer was aligned to 32 bits?
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
ht
Le 7 février 2024 23:19:41 GMT+02:00, James Almer a écrit :
>On 2/7/2024 6:10 PM, Cosmin Stejerean via ffmpeg-devel wrote:
>>
>>
>>> On Feb 7, 2024, at 11:27 AM, Lynne wrote:
>>>
>
> As a compromise, we could start requiring C11 now, and C17 in 7.1.
> Or does anyone still care
Le sunnuntaina 18. helmikuuta 2024, 18.27.35 EET Andreas Rheinhardt a écrit :
> 1. The function is called aligned_alloc (how did you test this?).
> 2. C11: "The value of alignment shall be a valid alignment supported by
> the implementation and the value of size shall be an integral multiple
> of
ly aligned buffers
> +if (ALIGN > _Alignof(max_align_t))
If you ever try to reintroduce something like this, you would need
here, and thus you should use alignof rather than _Alignof (which
was already deprecated by C23 deprecated).
> +ptr = aligned_malloc(size, ALIGN);
>
Le sunnuntaina 18. helmikuuta 2024, 18.29.32 EET James Almer a écrit :
> Removing all the different target specific allocation functions in favor
> of the standard one. But your second point makes it moot, so patch
> withdrawn.
If you want to get code closer to standards for dealing with
Le sunnuntaina 18. helmikuuta 2024, 2.43.14 EET Michael Niedermayer a écrit :
> > > You clearly are one of the parties to the disagreement, and "recuse
> > > themselves from the decision" is self-explanatory.
> >
> > Such a maximalist interpretation makes no sense - why should my opinion
> >
Le sunnuntaina 18. helmikuuta 2024, 20.40.14 EET Nicolas George a écrit :
> The world is “involves”, its meaning is inherently maximalist.
The wording is very clear (emphasis added): "If the disagreement involves a
member of the TC, that member SHOULD recuse themselves from the decision."
I
Le 13 décembre 2023 12:03:55 GMT+02:00, Nicolas George a
écrit :
>Rémi Denis-Courmont (12023-12-12):
>> ...and test for overflow errors in errno.m (which shall have been
>> zeroed beforehand). AFAIK, you need to do both if you want strict
>> error detection.
ing
to be happening next year.
--
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.
The current pack_output function pointer is a property of the decoder,
rather than a constant method provided by the DSP code. Indeed, except
for an unused initialisation, the field is never used in DSP code.
---
libavcodec/mlpdec.c | 48 ++---
Le sunnuntaina 17. joulukuuta 2023, 23.57.50 EET Martin Storsjö a écrit :
> > Rounding errors would not cause a constant gap across the different test
> > cases. This is most likely an off-by-one in the x86 code. I don't know if
> > this is a bug in the x86 code, or the test case being a little
Le 18 décembre 2023 21:58:39 GMT+02:00, Michael Niedermayer
a écrit :
>On Mon, Dec 18, 2023 at 06:33:45PM +0100, Anton Khirnov wrote:
>> Quoting Stefano Sabatini (2023-12-16 16:18:07)
>> > On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote:
>> > > Anton Khirnov (12023-12-14):
>>
Le 19 décembre 2023 11:29:04 GMT+02:00, Nicolas George a
écrit :
>Rémi Denis-Courmont (12023-12-19):
>> As others noted earlier, that won't work for Mac and Windows.
>
>If it works on Linux and other real Unixes, it is a lot better than if
>it does not work on any platform. A
haven't been possible to set.
>
> Use the official names for these extensions, as the previous ad-hoc
> names wasn't parseable.
>
> libavutil/tests/cpu tests that the cpu flags can be set, and prints
> the detected flags.
Acked-by: Rémi Denis-Courmont
> ---
> v3: Fixe
Le sunnuntaina 17. joulukuuta 2023, 18.09.45 EET James Almer a écrit :
> On 12/17/2023 6:13 AM, Rémi Denis-Courmont wrote:
> > ---
> >
> > tests/checkasm/lpc.c | 47 ++--
> > 1 file changed, 45 insertions(+), 2 deletions(-)
The penultimate loop iteration could pick any vl such that:
vlenb/4 < vl <= vlenb/2
Thus if the total length is not a multiple of vlenb/2, the vfadd.vf
on the penultimate iteration would yield corrupt values for the last
iteration.
To avoid this, force vl = vlen/2 until the last iteration.
Le perjantaina 22. joulukuuta 2023, 15.48.45 EET Andreas Rheinhardt a écrit :
> Avoids relocations.
This is a little bit misleading. It reduces the number of relocations indeed,
but the data structures still end up in nonshareable .data.relro rather than
.rodata due to other remaining pointers.
Le perjantaina 22. joulukuuta 2023, 3.34.39 EET flow gg a écrit :
> func ff_decorrelate_sm_rvv, zve32x
> 1:
> vsetvli t0, a2, e32, m8, ta, ma
> vle32.v v8, (a1)
> sub a2, a2, t0
> vle32.v v0, (a0)
> vssra.vi v8, v8, 1
> vsub.vv v16, v0, v8
>
Le perjantaina 22. joulukuuta 2023, 3.41.29 EET flow gg a écrit :
> It's at c908
>
> According to the benchmark results, if vlseg2e64 is used, the speed is
> almost as slow as C language (dcmul_add_rvv_f64: 86.2), if vsseg2e64 is
> used, it will be only a bit slower (dcmul_add_rvv_f64: 50.2).
Hello,
The RISC-V board will be personally visiting the taylor to get a fashionable
custom-made outfit. As a consequence, it will be taking a much deserved break
from FATE service over the end of year holidays.
--
Rémi Denis-Courmont
http://www.remlab.net
vcodec/riscv/takdsp_rvv.S
+++ b/libavcodec/riscv/takdsp_rvv.S
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2023 Institue of Software Chinese Academy of Sciences (ISCAS).
+ * Copyright (c) 2023 Rémi Denis-Courmont
*
* This file is part of FFmpeg.
*
@@ -65,3 +66,23 @@ func ff_decorrelate_sm_rvv, zve32x
Le perjantaina 22. joulukuuta 2023, 18.13.51 EET Andreas Rheinhardt a écrit :
> Rémi Denis-Courmont:
> > Le perjantaina 22. joulukuuta 2023, 15.48.45 EET Andreas Rheinhardt a
écrit :
> >> Avoids relocations.
> >
> > This is a little bit misleading. It reduces the nu
Le 15 décembre 2023 15:05:10 GMT+02:00, "Martin Storsjö" a
écrit :
>The names of the cpu flags are pased by the libavutil eval
PaSsed
>functions - names with dashes are parsed as a subtraction.
>Replace dashes with underscores.
My personal preference would be to use official extension
Le 15 décembre 2023 18:39:28 GMT+02:00, "Martin Storsjö" a
écrit :
>On Fri, 15 Dec 2023, Rémi Denis-Courmont wrote:
>
>> Le 15 décembre 2023 15:05:10 GMT+02:00, "Martin Storsjö"
>> a écrit :
>>> The names of the cpu flags are pased by the li
Le 15 décembre 2023 15:02:04 GMT+02:00, "Martin Storsjö" a
écrit :
>We can't call ff_get_rv_vlenb() if we don't have RVV available
>at all.
>
>Due to the SIGILL signal handler in checkasm catching it, in an
>unexpected place, this caused checkasm to hang instead of reporting
>the issue.
>---
>
Le 15 décembre 2023 17:39:48 GMT+02:00, "Martin Storsjö" a
écrit :
>On Fri, 15 Dec 2023, Rémi Denis-Courmont wrote:
>
>> Le 15 décembre 2023 15:02:04 GMT+02:00, "Martin Storsjö"
>> a écrit :
>>> We can't call ff_get_rv_vlenb() if we do
c = ff_vc1_inv_trans_8x8_dc_rvv;
> dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
> }
> -if (flags & AV_CPU_FLAG_RVV_I32) {
> -dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
> -dsp->vc1_inv_trans_4x4_dc = ff_vc
The 8x4 and 4x4 use a needlessly large multiplier (unless/until we care
about embedded 64-bit-vector hardware). This is merely suboptimal.
The 8x4 case also uses an incorrect vector length, which leads to incorrect
behaviour on future/hypothetical hardware with 256-bit or larger vectors.
This skips the round-trip to scalar register for the sliding 'x'
coefficients, improving performance by about 5%. The trick here is that
the vector slide-up instruction preserves elements in destination vector
until the slide offset.
The switch from vfslide1up.vf to vslideup.vi also allows the
Le torstaina 14. joulukuuta 2023, 18.41.24 EET Michael Niedermayer a écrit :
> SSE2:
> - lpc.apply_welch_window_even [OK]
> - lpc.apply_welch_window_odd [OK]
> 0: 976.228035341704 - 976.998462662304 = -0.7704273206
>autocorr_10_sse2 (lpc.c:81)
> - lpc.compute_autocorr_10 [FAILED]
>
Le perjantaina 15. joulukuuta 2023, 22.52.51 EET Martin Storsjö a écrit :
> The names of the cpu flags, when parsed from a string with
> av_parse_cpu_caps, are parsed by the libavutil eval functions. These
> interpret dashes as subtractions. Therefore, these previous cpu flag
> names haven't been
---
tests/checkasm/lpc.c | 47 ++--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/lpc.c b/tests/checkasm/lpc.c
index 592e34c03d..9b33f8a3b0 100644
--- a/tests/checkasm/lpc.c
+++ b/tests/checkasm/lpc.c
@@ -57,10 +57,46 @@
ction macros and with .option arch, +, right?
`.option arch` wants lower case names.
> Using the single-letter forms here for cpu flags would probably feel a bit
> obscure...
> Is there some similar names like these, that would be used for
> .option arch, for what we call rvi/rvf/rvd ab
The loop iterates over the length of the vector, not the order. This is
to avoid reloading the same data for each lag value. However this means
the loop only works if the maximum order is no larger than VLENB.
The loop is roughly equivalent to:
for (size_t j = 0; j < lag; j++)
---
tests/checkasm/lpc.c | 42 --
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/lpc.c b/tests/checkasm/lpc.c
index 592e34c03d..4d84defec3 100644
--- a/tests/checkasm/lpc.c
+++ b/tests/checkasm/lpc.c
@@ -57,10 +57,41 @@ static
Le 12 décembre 2023 16:07:28 GMT+02:00, Nicolas George a
écrit :
>Lena via ffmpeg-devel (12023-12-12):
>> The documentation for `strtol` says that on error, 0 is returned. This
>> makes it impossible to specify a window handle of 0 (the whole
>> desktop), but that case is already covered by
Le tiistaina 12. joulukuuta 2023, 23.02.40 EET Rémi Denis-Courmont a écrit :
> The loop iterates over the length of the vector, not the order. This is
> to avoid reloading the same data for each lag value. However this means
> the loop only works if the maximum order is no larger t
Le 27 décembre 2023 17:25:03 GMT+01:00, Abhishek Ojha
a écrit :
>This commit requires to resolve the compilation error of pipewiregrab
>because Pipewire's spa plugin is requesting locale_t extension to
>compile.
>Which was added in POSIX 2008 but ffmpeg is using POSIX 2001 due to
>which spa
lly crude yet effective,
designed to solve a problem temporarily or expediently"). That's pretty much
the antithesis of good and sound API design.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.or
Le maanantaina 18. joulukuuta 2023, 17.16.27 EET flow gg a écrit :
> C908:
> decorrelate_sm_c: 130.0
> decorrelate_sm_rvv_i32: 43.7
+
+func ff_decorrelate_sm_rvv, zve32x
+1:
+vsetvli t0, a2, e32, m8, ta, ma
+vle32.v v0, (a0)
+sub a2, a2, t0
+vle32.v v8, (a1)
+
Le torstaina 21. joulukuuta 2023, 18.07.55 EET Rémi Denis-Courmont a écrit :
> You can use VSSRA, and then VADD won't need to depend on the output of VSUB.
P.S.: I have NOT checked which approach is actually faster.
--
Rémi Denis-Courmont
http://www.remlab.
Le tiistaina 19. joulukuuta 2023, 4.53.12 EET flow gg a écrit :
> c908:
> dcmul_add_c: 88.0
> dcmul_add_rvv_f64: 46.2
>
> Did not use vlseg2e64, because it is much slower than vlse64
> Did not use vsseg2e64, because it is slightly slower than vsse64
Is this about C910 or C908? I have not checked
Le tiistaina 19. joulukuuta 2023, 14.02.00 EET Martin Storsjö a écrit :
> This replaces the riscv specific handling from
> 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is
> reverted, together with 286d6742218ba0235c32876b50bf593cb1986353)
> with a different implementation of the
Le 22 décembre 2023 00:03:59 GMT+02:00, Henrik Gramner via ffmpeg-devel
a écrit :
>On Thu, Dec 21, 2023 at 9:16 PM Rémi Denis-Courmont wrote:
>> > +checkasm_fail_func("%s",
>> > + s == SIGFPE ? "fatal arithmetic error&q
Le 21 décembre 2023 22:16:09 GMT+02:00, "Rémi Denis-Courmont"
a écrit :
>Le tiistaina 19. joulukuuta 2023, 14.02.00 EET Martin Storsjö a écrit :
>> This replaces the riscv specific handling from
>> 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially
Le 11 décembre 2023 11:11:28 GMT+02:00, Anton Khirnov a
écrit :
>Quoting Rémi Denis-Courmont (2023-12-08 18:46:51)
>> +#if __riscv_xlen >= 64
>> +func ff_lpc_apply_welch_window_rvv, zve64d
>> +vsetvli t0, zero, e64, m8, ta, ma
>> +vid.v v0
Le 11 décembre 2023 11:57:50 GMT+02:00, Anton Khirnov a
écrit :
>Quoting Rémi Denis-Courmont (2023-12-11 10:50:53)
>> Le 11 décembre 2023 11:11:28 GMT+02:00, Anton Khirnov a
>> écrit :
>> >I think it'd look a lot less like base64 < /dev/random if you vertically
>
Le lauantaina 9. joulukuuta 2023, 12.45.03 EET flow gg a écrit :
> There's a strange issue:
>
> Adding tests can compile successfully on x86 and lichee4a (risc v), but it
> results in an error on k230.
>
> > collect2: fatal error: ld terminated with signal 9 [Killed]
> > compilation terminated.
"offending" files should no longer be
compiled).
--
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
301 - 400 of 967 matches
Mail list logo
