Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
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

  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