Le perjantaina 28. huhtikuuta 2023, 12.55.02 EEST Nicolas George a écrit :
> +/**
> * + * Generic API
> +
> ***
> / +
> +#define FIELDOK(st, f) ((char *)(&
Ping.
--
雷米‧德尼-库尔蒙
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 tiistaina 2. toukokuuta 2023, 19.53.43 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-05-02):
> > Indirecting the printf function seems pretty pointless. The last thing you
>
> Please re-read the code, there is no other way of obtaining a va_list
> from an ac
Le tiistaina 2. toukokuuta 2023, 19.42.39 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-05-02):
> > A JSON writer that requires forced alignment is a poorly-written JSON
> > parser.
> This JSON writer requires that the structures that contain its state are
> a
Le tiistaina 2. toukokuuta 2023, 21.36.53 EEST Nicolas George a écrit :
> The only thing dumb and confusing I see here is the mail I am answering
> to.
> I must say, I am impressed by the rudeness and arrogance of such a
> comment without even looking at the code itself.
I think that that is pret
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 do
a local
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 sc
, Guillaume Poirier
Amiga / PowerPC Colin Ward
Linux / PowerPC Lauri Kasanen
+RISC-V Rémi Denis-Courmont
Windows MinGW Alex Beregszaszi, Ramiro Polla
Windows Cygwin
Le keskiviikkona 3. toukokuuta 2023, 22.05.26 EEST Michael Niedermayer a écrit
:
> On Wed, May 03, 2023 at 07:07:09PM +0300, Rémi Denis-Courmont wrote:
> The difference is with a dodgy link its the web browser that has to protect
> the user. With a dodgy HLS file its ffmpeg that has t
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
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
elieve this would be a good starting point for 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 stall
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 i
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 +
> libavcodec/riscv/M
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, or
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, or
; +
> +for (int i = 0; i < e->thread_count; i++)
> +pthread_join(e->threads[i].thread, NULL);
> +pthread_cond_destroy(&e->cond);
> +pthread_mutex_destroy(&e->lock);
> +
> +av_free(e->threads);
> +av_free(e->local_contexts);
Le sunnuntaina 21. toukokuuta 2023, 17.24.56 EEST Nuo Mi a écrit :
> > > +
> > > +typedef struct ThreadInfo {
> > > +int idx;
> > > +VVCExecutor *e;
> > > +pthread_t thread;
> > > +} ThreadInfo;
> > > +
> > > +struct VVCExecutor {
> > > +VVCTaskCallbacks cb;
> > > +ThreadInfo *t
a2
> +vwmulu.vx v10, v8, a6
> +vle8.v v8, (t0)
> +add t0, t1, a2
> +vle8.v v9, (t1)
> +vle8.v v12, (t0)
> +vnclipu.wi v13, v10, 6
> +vwmulu.vx v10, v
Le 24 mai 2023 10:39:59 GMT+03:00, Hao Chen a écrit :
>
>在 2023/5/20 下午5:38, Rémi Denis-Courmont 写道:
>> Le lauantaina 20. toukokuuta 2023, 10.27.19 EEST Hao Chen a écrit :
>>> From: yuanhecai
>>>
>>> This patch supports the use of the "checka
Le keskiviikkona 24. toukokuuta 2023, 8.28.08 EEST Arnie Chang a écrit :
> diff --git a/libavcodec/riscv/h264_mc_chroma.S
> b/libavcodec/riscv/h264_mc_chroma.S new file mode 100644
> index 00..9fcd2e34b3
> --- /dev/null
> +++ b/libavcodec/riscv/h264_mc_chroma.S
> @@ -0,0 +1,307 @@
> +/*
> +
Le perjantaina 26. toukokuuta 2023, 11.03.12 EEST Martin Storsjö a écrit :
> These are available since ARMv8.4-a and ARMv8.6-a respectively,
> but can also be available optionally since ARMv8.2-a.
>
> Check if these are available for use unconditionally (e.g. if compiling
> with -march=armv8.6-a),
Le perjantaina 26. toukokuuta 2023, 11.03.14 EEST Martin Storsjö a écrit :
> Based on code by Janne Grunau.
>
> Using HWCAP_CPUID for user space access to the CPU feature registers. See
> https://www.kernel.org/doc/html/latest/arm64/cpu-feature-registers.html.
> ---
> configure | 2
Le sunnuntaina 28. toukokuuta 2023, 0.34.15 EEST Martin Storsjö a écrit :
> > Someone would have to write assembler code that would fail to build under
> > a toolchain with a lower target version. That sounds like a bug that
> > should be spotted and fixed, rather than papered over.
>
> I don't se
Le lauantaina 27. toukokuuta 2023, 23.35.14 EEST Martin Storsjö a écrit :
> > NEON detection could be added here, though I've yet to see an Armv8
> > implementation without AdvSIMD.
>
> I guess we could, but as it's part of the require baseline for armv8-a I
> don't think there's much need for it?
Hi,
Unless somebody else comes up with additional comments, you don't need to do
anything.
As the FFmpeg RISC-V maintainer, whatever that entails, I figure that I am
expected, by default, to merge your patch but I have not sorted out commit
access yet. But anyhow, there's not much *you* can do
Le tiistaina 30. toukokuuta 2023, 15.25.25 EEST Martin Storsjö a écrit :
> On Sun, 28 May 2023, Rémi Denis-Courmont wrote:
> > Le sunnuntaina 28. toukokuuta 2023, 0.34.15 EEST Martin Storsjö a écrit :
> >> I guess the alternative would be to just try to set .arch
> >> .
Le tiistaina 30. toukokuuta 2023, 15.30.41 EEST Martin Storsjö a écrit :
> Based partially on code by Janne Grunau.
>
> ---
> Updated to use both the direct HWCAP* macros and HWCAP_CPUID. A
> not unreasonably old distribution like Ubuntu 20.04 does have
> HWCAP_CPUID but not HWCAP2_I8MM in the dis
Le perjantaina 9. kesäkuuta 2023, 10.17.27 EEST Arnie Chang a écrit :
> Optimize the put and avg filtering for 4xH and 2xH blocks
>
> Signed-off-by: Arnie Chang
> diff --git a/libavcodec/riscv/h264_mc_chroma.S
> b/libavcodec/riscv/h264_mc_chroma.S index 364bc3156e..c97cdbad86 100644
> --- a/libav
Le maanantaina 12. kesäkuuta 2023, 18.28.34 EEST Arnie Chang a écrit :
> On Mon, Jun 12, 2023 at 10:59 PM Rémi Denis-Courmont
>
> wrote:
> > It would seem more simpler and more intuitive to just use `.if` here.
> > (Ditto
> > below.)
>
> hi,
> Do you mean u
5-line conditional shift blocks could be simplified by
folding, e.g.:
slli t3, a2, (1 + \unroll)
Though I wonder if we could leverage SH*ADD instructions in some cases instead
of SLLI?
(..)
> +.endm
> +
> +.macro h264_chroma_mc type wi
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,
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: 2871
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
ersion, we'll end up with 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
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
> l
---
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 p
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 userspace,
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
-09-03 21:56:31 +0300)
Rémi Denis-Courmont (3):
riscv: add CPU flags for the RISC-V Vector extension
riscv: initial common header for assembler macros
riscv: add float vector-scalar multiplication
libavutil/cpu.c
Le lauantaina 3. syyskuuta 2022, 22.01.45 EEST r...@remlab.net a écrit :
> +#define ZVE_UP_TO(cap) ((2 * (cap)) - 1)
Stray code. Ignore.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
ht
Le lauantaina 3. syyskuuta 2022, 22.11.26 EEST Lynne a écrit :
> > diff --git a/libavutil/riscv/float_dsp_rvv.S
> > b/libavutil/riscv/float_dsp_rvv.S new file mode 100644
> > index 00..54ea1d9d6d
> > --- /dev/null
> > +++ b/libavutil/riscv/float_dsp_rvv.S
> > @@ -0,0 +1,60 @@
> > +/*
> > +
Le lauantaina 3. syyskuuta 2022, 22.20.20 EEST Lynne a écrit :
> Sep 3, 2022, 21:01 by r...@remlab.net:
> > From: Rémi Denis-Courmont
> >
> > RVV defines a total of 12 different extensions: V, Zvl32b, Zvl64b,
> > Zvl128b, Zvl256b, Zvl512b, Zvl1024b, Zve32x, Zve32f, Zv
Le lauantaina 3. syyskuuta 2022, 22.48.45 EEST Lynne a écrit :
> Sep 3, 2022, 21:34 by r...@remlab.net:
> > Le lauantaina 3. syyskuuta 2022, 22.11.26 EEST Lynne a écrit :
> >> > diff --git a/libavutil/riscv/float_dsp_rvv.S
> >> > b/libavutil/riscv/float_dsp_rvv.S new file mode 100644
> >> > index 0
Le sunnuntaina 4. syyskuuta 2022, 0.38.32 EEST Lynne a écrit :
> I need to know the length in C, not assembly.
There may be some corner cases where that makes sense, but typically it
doesn't. Even if you're dealing in fixed-size macro blocks, you should leverage
the larger vectors to unroll and
Le sunnuntaina 4. syyskuuta 2022, 9.39.36 EEST Lynne a écrit :
> In particular, doing the tail, which consists of 2 equal length transforms.
> On AVX we interleave the coefficients from 2x4pt transforms during
> lookups since we can do them simultaneously and save on
> shuffles. Doing them individu
support for Zvba for probably neglible
performance gains though.
Rémi Denis-Courmont (10):
riscv: add CPU flags for the RISC-V Vector extension
riscv: initial common header for assembler macros
riscv: float vector
Le sunnuntaina 4. syyskuuta 2022, 20.48.26 EEST Lynne a écrit :
> > The pointer arithmetic could be slightly optimised with SH2ADD and
> > SH3ADD instructions from the Zvba extension. This would require more
> > conditional code, or requiring support for Zvba for probably neglible
> > performance g
Le maanantaina 5. joulukuuta 2022, 4.51.34 EET zhilizhao(赵志立) a écrit :
> > On Nov 19, 2022, at 02:48, Zhao Zhili wrote:
> >
> > From: Zhao Zhili
> >
> > Unlike the pipe protocol, fd protocol has seek support if it
> > corresponding to a regular file.
> > ---
> > Sometimes it's the only way to
Le sunnuntaina 11. joulukuuta 2022, 17.17.27 EET Zhao Zhili a écrit :
> From: Zhao Zhili
>
> Unlike the pipe protocol, fd protocol has seek support if it
> corresponding to a regular file.
> ---
> v2: dup the file descriptor for safety
>
> doc/protocols.texi | 24 ++
> liba
Le maanantaina 12. joulukuuta 2022, 19.23.52 EET Zhao Zhili a écrit :
> On Mon, 2022-12-12 at 18:31 +0200, Rémi Denis-Courmont wrote:
> > Le maanantaina 5. joulukuuta 2022, 4.51.34 EET zhilizhao(赵志立) a écrit
> >
> > > > On Nov 19, 2022, at 02:48, Zhao Zhili
> >
Le sunnuntaina 11. joulukuuta 2022, 17.17.27 EET Zhao Zhili a écrit :
> From: Zhao Zhili
>
> Unlike the pipe protocol, fd protocol has seek support if it
> corresponding to a regular file.
> ---
> v2: dup the file descriptor for safety
>
> doc/protocols.texi | 24 ++
> liba
need to use REUSEPORT and BPF, but that will only work on Linux,
and that's not implemented in the patch.)
--
Rémi Denis-Courmont
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubsc
Le 24 décembre 2022 14:07:26 GMT+01:00, Camille Oudot
a écrit :
>Hello,
>
>On Sat, 2022-12-24 at 13:36 +0200, Rémi Denis-Courmont wrote:
>> I don't see why you need an option for this. In parsing the SDP, it
>> should be self-evident if a given socket needs to be reus
Le maanantaina 26. joulukuuta 2022, 23.47.17 EET Nicolas George a écrit :
> "zhilizhao(赵志立)" (12022-12-26):
> > Just use the same socket file descriptor. Don’t use OS dependent hack to
> > implement a feature.
>
> SO_REUSEADDR is absolutely not a hack.
So I agree that SO_REUSEADDR is "absolutely
Le tiistaina 3. tammikuuta 2023, 11.03.30 EET Camille Oudot a écrit :
> Hi, I'm back on the topic. Thanks to all of you for your comments.
>
> > So I agree that SO_REUSEADDR is "absolutely not a hack"... if you use
> > it to recycle IP/port pair without waiting for the time-out. But
> > that's mai
Le keskiviikkona 11. tammikuuta 2023, 10.52.08 EET Paul B Mahol a écrit :
> > Sorry for the break, I’m trying to figure out how to make it compatible
> > with Windows.
>
> Is this even portable?
If you build FFmpeg correctly, so that all the FFmpeg libraries and the
application code share the sa
Le perjantaina 13. tammikuuta 2023, 5.37.36 EET zhilizhao(赵志立) a écrit :
> > On Jan 13, 2023, at 03:13, Rémi Denis-Courmont wrote:
> >
> > Le keskiviikkona 11. tammikuuta 2023, 10.52.08 EET Paul B Mahol a écrit :
> >>> Sorry for the break, I’m trying to figure
Le keskiviikkona 11. tammikuuta 2023, 0.57.13 EET Mark Reid a écrit :
> > Are you really duplicating a whole bunch of files from lavc in sws? I
> > don't think that's anywhere remotely close to acceptable.
>
> This was what I was suggested to do
> http://ffmpeg.org/pipermail/ffmpeg-devel/2022-Dece
This fixes the RISC-V B code not to assume alignment. Unfortunately,
the whole idea behind the optimisation does not really work if the
input is unaligned, and the C code works just as well.
Notes:
- This does not fix the call prototypes, whose second parameter
is expected to change to `const vo
Le keskiviikkona 8. helmikuuta 2023, 16.27.52 EET Devin Heitmueller a écrit :
> On Wed, Feb 8, 2023 at 8:08 AM Jean-Baptiste Kempf wrote:
> > Do we really need those PIX_FMT in FFmpeg public API?
>
> Tiled formats are annoying, but not uncommon in popular embedded
> platforms (e.g. NXP iMX, TI Da
Hi,
I agree with Kieran that this doesn't look like it belongs in FFmpeg or in any
media framework. In fact, Wireshark has some support for extracting media from
RTP, and that seems like the right place for it.
With that said, you can't realistically pass RTP packets on the standard input.
RTP
ERNET" fare type. Otherwise, you have to pay the normal
price, but you avoid queues at the ticket counter.
Looking forward to seeing many of you in Brussels,
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ffmpeg-devel mailing list
ff
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 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 discrep
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 p
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 2 juillet 2023 19:01:41 GMT+03:00, Nicolas George a écrit :
>Rémi Denis-Courmont (12023-07-02):
>> Otherwise it's not offensive and inflammatory. Rather it's insulting and
>> defamatory.
>
>“Bean counter” was derogatory,
So you admit to insulting not jus
Hi,
The diff is ok. I even have a slight incline in favour thereof for the sake of
consistency. Yet, I may be vainly pedantic but I do have problems with the
description.
Le 3 juillet 2023 05:44:12 GMT+03:00, Khem Raj a écrit :
>Add missing operand
The spec does explicitly make the mask and t
Le maanantaina 3. heinäkuuta 2023, 18.52.13 EEST Khem Raj a écrit :
> > *Hopefully* LLVM gets their act together by release 16, and ship a usable
> > assembler, rather than tell us to use automatic RVV vectorisation (which
> > *is* a release 16 feature, though it was half-baked last time I tried).
Le tiistaina 4. heinäkuuta 2023, 2.00.04 EEST Michael Niedermayer a écrit :
> Suggested-by: Anton
>
> Signed-off-by: Michael Niedermayer
> ---
> doc/developer.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 0c2f2cd7d1
Le keskiviikkona 5. heinäkuuta 2023, 2.26.12 EEST James Almer a écrit :
> This ensures the requested amount of bytes is read.
You're moving the problem though. Now, you may read more than necessary (and
block longer than necessary) due to stdio internal buffering, which you did not
disable.
> A
Le sunnuntaina 9. heinäkuuta 2023, 0.41.35 EEST Michael Niedermayer a écrit :
> On Fri, Jul 07, 2023 at 10:05:39PM +0800, Nuo Mi wrote:
> > This is the main entry point for the CTU (Coding Tree Unit) decoder.
> > The code will divide the CTU decoder into several stages.
> > It will check the stage
Terminating the whole checkasm process is not very helpful. This will
report if an illegal instruction occurs while executing a tested
function.
---
tests/checkasm/checkasm.c | 20
tests/checkasm/checkasm.h | 8 +++-
2 files changed, 27 insertions(+), 1 deletion(-)
diff
This increases the group multiplier as per T-Head C910 benchmarks:
inverse_coupling_c: 4597.0
inverse_coupling_rvv_i32: 1312.7 (m1)
inverse_coupling_rvv_i32: 1116.7 (m2)
inverse_coupling_rvv_i32: 732.2 (m4)
inverse_coupling_rvv_i32: 898.0 (m8)
---
libavcodec/riscv/vorbisdsp_rvv.S | 2 +-
1 file
This increases the group multiplier as per T-Head C910 benchmarks:
alac_append_extra_bits_mono_c: 803.0
alac_append_extra_bits_stereo_c: 1604.2
alac_decorrelate_stereo_c: 1077.5
LMUL=1
alac_append_extra_bits_mono_rvv_i32: 418.2
alac_append_extra_bits_stereo_rvv_i32: 693.2
alac_decorrelate_stereo_
Except for add_squares, telling the compiler that the output vector(s)
cannot alias helps quite a bit (cycles on SiFive U74-MC):
ps_add_squares_c: 98277.7
ps_add_squares_r: 98320.2
ps_hybrid_analysis_c: 3731.2
ps_hybrid_analysis_r: 2495.7
ps_hybrid_analysis_ileave_c: 20478.0
ps_hybrid_analysis_i
Even though they have the same size, and typically the same alignment,
uint32_t and float are under no circumstances compatible types in C.
The casts from float * to uint32_t * are invalid here. Insofar as the
resulting pointers are dereferenced, this is undefined behaviour.
This patch uses av_flo
The IMDCT offset is only relevant for NEON optimisations. There are no
VFP optimisations here that would justify the HAVE_VFP flag. In
practice, this makes no difference because HAVE_NEON is practically
always true for standard Armv8 platforms.
---
libavcodec/aarch64/synth_filter_init.c | 2 +-
1
This is not actually used for anything. The configure check causes the
CPU feature flag to be set, but nothing consumes it at all.
While AArch64 does have VFP, it is only used for the scalar C code.
Conversely, it is still possible to disable VFP, by changing the
C compiler flags as before (though
Hello,
This enables use of Linux perf without breaking RISC-V Linux kernel
versions that don't support it.
Rémi Denis-Courmont (7):
checkasm: fix Linux perf cleanup
checkasm: improve Linux perf error me
0 is a valid file descriptor.
---
tests/checkasm/checkasm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 4311a8ffcb..1da0877be5 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -317,7
Report the failing system call name, as is convention, rather than just
a rather unhelpful "syscall".
---
tests/checkasm/checkasm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 1da0877be5..bfc0a48079 100644
--- a/te
This converts the bench/perf start/stop macros into functional macros,
and for that to work, take the Linux perf code out of line.
---
tests/checkasm/checkasm.c | 24
tests/checkasm/checkasm.h | 36 +---
2 files changed, 33 insertions(+), 27
This makes all calls to the bench start and stop functions via
function pointers. While the primary goal is to support run-time
selection of the performance measurement back-end in later commits,
this has the side benefit of containing platform dependencies in to
checkasm.c and out of checkasm.h.
-
---
tests/checkasm/checkasm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 4b6164301a..c3075fe37c 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -524,7 +524,6 @@ static int measure_nop_time(void)
{
u
Now that checkasm can automatically fall back to RDCYCLE, it is safe to
enable this for forward compatibility with kernel versions mitigating
the "Cycle Drift" side channel attack.
Where available, this should also reduce measurement noise, since
kernel and hypervisor cycles should no longer be co
On Linux RISC-V, depending on kernel version and configuration, the
cycle counters may be available:
- via Linux perf (as on Arm),
- directly with RDCYCLE (which is considered legacy),
- neither (if admistratively disabled), or
- or both (in legacy compatibility mode).
This allows to try Linux per
This checks that arguments are handled. If not, then this prints a
short usage notice and returns an error.
---
tests/checkasm/checkasm.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
i
Before:
butterflies_fixed_c: 804.7
butterflies_fixed_rvv_i32: 348.2
After:
butterflies_fixed_rvv_i32: 308.7
---
libavutil/riscv/fixed_dsp_rvv.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/riscv/fixed_dsp_rvv.S b/libavutil/riscv/fixed_dsp_rvv.S
index a91316e1da..6
Le lauantaina 15. heinäkuuta 2023, 11.05.51 EEST Lynne a écrit :
> Jul 14, 2023, 20:29 by r...@remlab.net:
> > This makes all calls to the bench start and stop functions via
> > function pointers. While the primary goal is to support run-time
> > selection of the performance measurement back-end in
Changes since v1:
- Purge additional no longer used variable.
- Deinitialise benchmarking through function pointer.
- Cache function pointers outside bench loop.
--
レミ・デニ-クールモン
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Report the failing system call name, as is convention, rather than just
a rather unhelpful "syscall".
---
tests/checkasm/checkasm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 4311a8ffcb..8702c9a30a 100644
--- a/te
This converts the bench/perf start/stop macros into functional macros,
and for that to work, take the Linux perf code out of line.
---
tests/checkasm/checkasm.c | 24
tests/checkasm/checkasm.h | 36 +---
2 files changed, 33 insertions(+), 27
This makes all calls to the bench start and stop functions via
function pointers. While the primary goal is to support run-time
selection of the performance measurement back-end in later commits,
this has the side benefit of containing platform dependencies in to
checkasm.c and out of checkasm.h.
-
---
tests/checkasm/checkasm.c | 2 --
tests/checkasm/checkasm.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index e921257257..c90f361ff7 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -522,7 +522,6 @@ static
Now that checkasm can automatically fall back to RDCYCLE, it is safe to
enable this for forward compatibility with kernel versions mitigating
the "Cycle Drift" side channel attack.
Where available, this should also reduce measurement noise, since
kernel and hypervisor cycles should no longer be co
101 - 200 of 1177 matches
Mail list logo
