Re: [FFmpeg-devel] [PATCH v2] checkasm: add sample argument to adjust during bench
On Tue, May 21, 2024 at 2:33 PM J. Dekker wrote:
> @@ -338,8 +338,9 @@ typedef struct CheckasmPerf {
> uint64_t tsum = 0;\
> int ti, tcount = 0;\
> uint64_t t = 0; \
> +const uint64_t truns = bench_runs;\
> checkasm_set_signal_handler_state(1);\
> -for (ti = 0; ti < BENCH_RUNS; ti++) {\
> +for (ti = 0; ti < truns; ti++) {\
This is comparing int with uint64_t. We should probably just use int
for the sample count too.
___
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".
Re: [FFmpeg-devel] [PATCH v3 2/5] ffbuild/libversion.sh: add shebang
On Tue, Apr 9, 2024 at 11:52 PM Marth64 wrote: > > +#!/bin/sh > Might I suggest `#!/usr/bin/env sh` instead for this case? > I tend to prefer it from a portability and usability perspective, > but I can imagine for sh it might not matter. /bin/sh exists on virtually every *NIX system whereas /usr/bin/env is not ubiquitous, so that seems like a terrible idea that would achieve the opposite result. ___ 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".
Re: [FFmpeg-devel] [PATCH] lavf/vsrc_ddagrab: WinAPI functions must be called as stdcall in x86_32
On Sun, Apr 7, 2024 at 2:59 AM Vadim Guchenko wrote: > +typedef DPI_AWARENESS_CONTEXT (__stdcall > *set_thread_dpi_t)(DPI_AWARENESS_CONTEXT); I believe most existing code uses WINAPI instead of __stdcall. ___ 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".
Re: [FFmpeg-devel] [GASPP PATCH] Implicitly start out in the text section for armasm
On Wed, Apr 3, 2024 at 3:47 PM Martin Storsjö wrote: > > This fixes assembling files starting with bare symbol declarations, > without explicitly switching to .text first. lgtm. ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/x86/h264_idct: Fix incorrect xmm spilling on win64
On Sun, Mar 24, 2024 at 8:21 PM Henrik Gramner wrote: > > Broken in afa471d0efed1df5dca6eeeb2fcdd211ae4cad4e. It just happened > to work before due to x86inc.asm previously performing XMM spills in > INIT_MMX mode which was more of a bug than an intentional feature. Will apply. ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/mov_chan: Use anonymous union
On Mon, Mar 25, 2024 at 4:01 PM Andreas Rheinhardt wrote: > > Right, it is an anonymous enum, not union. Amended locally. > > - Andreas Can confirm this eliminates the warnings, lgtm. ___ 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".
[FFmpeg-devel] [PATCH] avcodec/x86/h264_idct: Fix incorrect xmm spilling on win64
Broken in afa471d0efed1df5dca6eeeb2fcdd211ae4cad4e. It just happened to work before due to x86inc.asm previously performing XMM spills in INIT_MMX mode which was more of a bug than an intentional feature. x86_h264_idct_spill_xmm.patch Description: Binary data ___ 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".
Re: [FFmpeg-devel] [PATCH] x86: Update x86inc.asm
On Tue, Mar 19, 2024 at 11:20 AM Henrik Gramner wrote: > > Will push in a few days if there are no comments. Pushed. ___ 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".
Re: [FFmpeg-devel] [PATCH] x86: Update x86inc.asm
On Sat, Mar 16, 2024 at 8:53 PM Henrik Gramner wrote: > Makes things up-to-date with the upstream at > https://code.videolan.org/videolan/x86inc.asm Will push in a few days if there are no comments. ___ 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".
Re: [FFmpeg-devel] [PATCH] avutil/x86util: Fix broken pre-SSE4.1 PMINSD emulation
On Sun, Mar 17, 2024 at 1:44 PM James Almer wrote: > LGTM. I wonder why we even added a float based fallback for this. Thanks, pushed. ___ 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".
[FFmpeg-devel] [PATCH] avutil/x86util: Fix broken pre-SSE4.1 PMINSD emulation
Fixes yadif-16 which allows FATE to pass. Broken since 2904db90458a1253e4aea6844ba9a59ac11923b6 (2017). pminsd_emulation.patch Description: Binary data ___ 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".
[FFmpeg-devel] [PATCH] x86: Update x86inc.asm
Makes things up-to-date with the upstream at https://code.videolan.org/videolan/x86inc.asm Specifying every individual change is difficult as there have been divergences and cherry-picks over time, but the full upstream change log can be found at https://code.videolan.org/videolan/x86inc.asm/-/commits/master?ref_type=heads Tested and passes FATE on Linux (x86-64), macOS (x86-64), and Windows (x86-64 and x86-32). The macOS system with AVX2, the rest with AVX512ICL. The following local changes compared to upstream remain (is the OS/2 part still relevant?): @@ -37,2 +37,5 @@ +%if HAVE_ALIGNED_STACK +%define STACK_ALIGNMENT 16 +%endif %ifndef STACK_ALIGNMENT @@ -86,4 +89,11 @@ +; aout does not support align= +; NOTE: This section is out of sync with x264, in order to +; keep supporting OS/2. %macro SECTION_RODATA 0-1 16 -%ifidn __OUTPUT_FORMAT__,win32 +%ifidn __OUTPUT_FORMAT__,aout +SECTION .text +%elifidn __OUTPUT_FORMAT__,coff +SECTION .text +%elifidn __OUTPUT_FORMAT__,win32 SECTION .rdata align=%1 x86_update_x86inc.patch Description: Binary data ___ 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".
Re: [FFmpeg-devel] [PATCH] libavcodec/h264pred: Remove pred8x8_horizontal_8_mmxext
On Sat, Mar 2, 2024 at 10:13 PM Kieran Kunhya wrote: > SPLATB_LOAD m0, r0+r1*0-1, m2 > SPLATB_LOAD m1, r0+r1*1-1, m2 This adds an extra unnecessary shuffle in the SSE2 code as it splats to a full register. The easiest way of fixing it would probably be to unroll the macro and manually get rid of it. Although on x86-64 it might be faster to do a 1->8 byte splat using a GPR multiply with 0x0101010101010101. ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/x86/hevc: fix luma 12b overflow
On Sun, Feb 25, 2024 at 5:42 PM Ronald S. Bultje wrote: > +movam13, [pw_8] > +paddw m10, m12, m12 > +paddw m12, m10 ; 9 * (q0 - p0) - 3 * ( q1 - p1 ) > paddw m12, m13; + 8 Memory operand > +paddw m10, m13, m13 > +paddw m13, m10 ; abs(9 * (q0 - p0) - 3 * ( q1 - p1 )) > +paddw m13, [pw_8] [...] > +paddw m13, m12, m12 > +paddw m13, m12 ; 3*abs(m12) > +paddw m13, [pw_8] Another minor improvement would be to reorder the adds like (x + x) + (x + 8) instead of ((x + x) + x) + 8 to allow for more instruction-level parallelism. ___ 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".
Re: [FFmpeg-devel] [PATCH] checkasm: Generalize crash handling
On Fri, Dec 22, 2023 at 7:20 AM Rémi Denis-Courmont wrote:
> >> > +checkasm_fail_func("%s",
> >> > + s == SIGFPE ? "fatal arithmetic error" :
> >> > + s == SIGILL ? "illegal instruction" :
> >> > + s == SIGBUS ? "bus error" :
> >> > + "segmentation fault");
> >>
> >> The current code for the error print-out is both simpler and more
> >> versatile,
> >> so I don't get this.
> >
> >IMO "illegal instruction" is a far better error message than "fatal
> >signal 4" (with an implementation-defined number which nobody knows
> >the meaning of without having to look it up).
>
> The current code prints the number and the name.
Not on all supported systems. And even when it does it's in an
implementation-defined and locale-dependent form, which isn't great.
> >> +const struct sigaction sa = {
> >> +.sa_handler = signal_handler,
> >> +.sa_flags = SA_NODEFER,
> >
> >That does not look very sane to me. If a recursive signal occurs, processing
> >it recursively is NOT a good idea.
>
> Following that, it actually seems safer to automatically reset the handler,
> using `signal()` or equivalently passing the `SA_RESETHAND` flag. Then the
> handler can rearm its own self if and *only* if it was able to actually
> handle the signal by observing a long jump. Resetting to default explicitly
> is no longer useful then.
Sure, that approach sounds fine.
___
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".
Re: [FFmpeg-devel] [PATCH] checkasm: Generalize crash handling
On Thu, Dec 21, 2023 at 9:16 PM Rémi Denis-Courmont wrote:
> > +checkasm_fail_func("%s",
> > + s == SIGFPE ? "fatal arithmetic error" :
> > + s == SIGILL ? "illegal instruction" :
> > + s == SIGBUS ? "bus error" :
> > + "segmentation fault");
>
> The current code for the error print-out is both simpler and more versatile,
> so I don't get this.
IMO "illegal instruction" is a far better error message than "fatal
signal 4" (with an implementation-defined number which nobody knows
the meaning of without having to look it up).
> > +/* fall back to the default signal handler */
> > +static const struct sigaction default_sa = { .sa_handler = SIG_DFL
> > }; +sigaction(s, _sa, NULL);
> > +raise(s);
>
> Why raise here? Returning from the handler will reevaluate the same code with
> the same thread state, and trigger the default signal handler anyway (since
> you don't modify the user context).
No it wont, it'll get stuck in an infinite loop invoking the signal
handler over and over. At least on my system.
> > +const struct sigaction sa = {
> > +.sa_handler = signal_handler,
> > +.sa_flags = SA_NODEFER,
>
> That does not look very sane to me. If a recursive signal occurs, processing
> it recursively is NOT a good idea. This would cause an infinite loop,
> eventually a literal stack overflow after maxing out the processor for a
> while.
> I'd rather let the OS kernel deal with the problem, by killing the process or
> whatever the last resort is.
>
> > +#define checkasm_save_context() setjmp(checkasm_context_buf)
> > +#define checkasm_load_context() longjmp(checkasm_context_buf, 1)
> > +#endif
>
> Been there done that and it did not end well.
> sigsetjmp() & co are necessary here.
For all intents and purposes sigjmp()/longjmp() with SA_NODEFER does
the same thing as sigsetjmp()/siglongjmp() without SA_NODEFER for this
particular use case (no infinite recursion is possible the way the
code is written). The change isn't necessary per se but it seems
reasonable and I have no objections to it.
___
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".
Re: [FFmpeg-devel] [PATCH] checkasm: Generalize crash handling
On Tue, Dec 19, 2023 at 1:02 PM Martin Storsjö wrote: > This replaces the riscv specific handling from > 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is > reverted, together with 286d6742218ba0235c32876b50bf593cb1986353) > with a different implementation of the same (plus a bit more), based > on the corresponding feature in dav1d's checkasm, supporting both Unix > and Windows. lgtm ___ 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".
Re: [FFmpeg-devel] [PATCH v2] avcodec/amfenc: increase precision of Sleep() on Windows
On Mon, Nov 27, 2023 at 2:42 PM Mark Thompson wrote: > Is it reasonable to set this global state from a library without the parent > program knowing? We'd really prefer not to affect the global state > unexpectedly. CreateWaitableTimerExW() with the CREATE_WAITABLE_TIMER_HIGH_RESOLUTION flag might be an alternative? ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] x86/ac3dsp: add ff_float_to_fixed24_avx2()
On Thu, Nov 23, 2023 at 12:51 PM James Almer wrote: > movdqa wiht ymm is avx2. I could change it to movaps, but technically > the registers contain floats and i don't know if any old AVX cpu has > penalties for changing domains. Fwiw I believe what domain the result of fp <-> int conversion instructions belongs to actually differs between µarchs. Realistically whether movaps or movdqa is used to store the result to memory is unlikely to matter in practice though. ___ 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".
Re: [FFmpeg-devel] [PATCH 1/4] avutil/x86/pixelutils: Empty MMX state in ff_pixelutils_sad_8x8_mmxext
On Wed, Nov 1, 2023 at 10:44 AM Andreas Rheinhardt wrote: > libavutil/x86/pixelutils.asm | 1 + > 1 file changed, 1 insertion(+) IIRC the emms instructions is quite slow on many systems, so if this is the only pixelutils function using mmx it's probably better to just rewrite it to use SSE2 instead (even if that means only using the lower half of xmm registers). ___ 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".
Re: [FFmpeg-devel] [PATCH] x86inc: Add REPX macro to repeat instructions/operations
On Fri, Sep 29, 2023 at 1:38 PM Frank Plowman wrote: > libavutil/x86/x86inc.asm | 10 ++ > 1 file changed, 10 insertions(+) LGTM. As a side note https://code.videolan.org/videolan/x86inc.asm is the upstream repo for x86inc.asm. ___ 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".
