From: "Martin Storsjö via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org>
To: "Rémi Denis-Courmont via ffmpeg-devel" <ffmpeg-devel@ffmpeg.org>
Cc: "Harish Raja Selvan" <harish.rajaselvan@multicorewareinc.com>,
"Rémi Denis-Courmont" <remi@remlab.net>,
"Martin Storsjö" <martin@martin.st>
Subject: [FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm
Date: Tue, 20 Jan 2026 15:34:57 +0200 (EET)
Message-ID: <77c5679-f47f-5165-7c5-6d5dd9978cda@martin.st> (raw)
In-Reply-To: <3C1B3820-C4C2-4CA5-B1A9-9AB15EE5A2A4@remlab.net>
On Tue, 20 Jan 2026, Rémi Denis-Courmont via ffmpeg-devel wrote:
> Do you have a plan to address the outstanding shortcomings? What would
> the actual performance look like in such case, seen as it would disable
> most or all of the assembler optimisations?
It is possible to use the current aarch64 assembler as such - even
though it does violate the arm64ec ABI.
I just did a set of test builds of ffmpeg with MSVC, natively for arm64,
one for arm64ec (with an unpatched ffmpeg) and one for x86_64. For a
simple testcase of decoding VP9, both the proper arm64 and the less proper
arm64ec build end up decoding at a similar speed, ~390 fps. The x86_64
build, running emulated runs at 171 fps.
The fact that the arm64ec ABI is violated by the assembly is mostly not a
practical problem, as long as it only is called directly by the arm64ec
code, not by emulated x86_64. There are also some other limitations
(if someone is suspending/resuming the process, the register state would
be limited to what is expressible in arm64ec mode). There's of course no
guarantees that this violation will be tolerated in the same way in future
versions of Windows either.
The cpuflags part of the library API/ABI is indeed a problem - but for a
caller user application which doesn't call that (and, practically
speaking, I would expect that most user apps don't do that), that issue
doesn't really crop up either.
I'm not arguing for us to support this in any greater form than we
currently do - anyone wanting to use this can really build it for
themselves. But in the current form, with ABI violations at all, it does
practically work quite fine in many cases, and it does give essentially
the same performance as a native build. But those who want to do that will
need to worry about the limitations - and I wouldn't expect those who
currently distribute binary builds of ffmpeg to care to add arm64ec
builds.
(Do note that the ffmpeg project itself doesn't distribute binary builds,
that is up to third party volunteers. So at this point, it's not us that
would need to be convinced, it's those third parties that do binary
builds.)
// Martin
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org
next prev parent reply other threads:[~2026-01-20 13:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-03 12:49 [FFmpeg-devel] " Martin Storsjö via ffmpeg-devel
2025-10-03 12:49 ` [FFmpeg-devel] [GASPP PATCH 2/2] Filter out the cl.exe option -arm64EC from armasm Martin Storsjö via ffmpeg-devel
2025-10-09 12:11 ` [FFmpeg-devel] Re: [GASPP PATCH 1/2] Pass "-machine" options through to armasm Martin Storsjö via ffmpeg-devel
2025-10-10 11:11 ` Harish Raja Selvan via ffmpeg-devel
2025-10-10 13:06 ` Martin Storsjö via ffmpeg-devel
2025-11-07 3:51 ` Harish Raja Selvan via ffmpeg-devel
2025-11-07 8:56 ` Martin Storsjö via ffmpeg-devel
2025-11-17 7:27 ` Harish Raja Selvan via ffmpeg-devel
2026-01-20 7:26 ` Harish Raja Selvan via ffmpeg-devel
2026-01-20 11:32 ` Rémi Denis-Courmont via ffmpeg-devel
2026-01-20 13:34 ` Martin Storsjö via ffmpeg-devel [this message]
2026-01-20 14:33 ` Rémi Denis-Courmont via ffmpeg-devel
2026-01-27 7:42 ` Harish Raja Selvan via ffmpeg-devel
2026-01-27 15:34 ` Rémi Denis-Courmont via ffmpeg-devel
2025-11-07 9:37 ` Rémi Denis-Courmont via ffmpeg-devel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=77c5679-f47f-5165-7c5-6d5dd9978cda@martin.st \
--to=ffmpeg-devel@ffmpeg.org \
--cc=harish.rajaselvan@multicorewareinc.com \
--cc=martin@martin.st \
--cc=remi@remlab.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git