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;\
>
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
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
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
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.
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
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
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
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
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
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
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
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
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
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 ?
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"
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
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
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
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
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.
___
21 matches
Mail list logo
