[ARM CPU] SVE support for Sgemm kernel

[akote123]

This PR ports the SGEMM kernel and associated packing kernels to the ARM SVE (Scalable Vector Extension) backend. Specifically, it introduces new wrapper implementations for SVE functions in lib/sve/sgemm_sve.cpp and integrates these wrappers within the existing kernel implementations.

Motivation and Context

This work is part of an ongoing effort to enhance ONNX Runtime's performance and architecture-awareness on ARM platforms. By leveraging ARM SVE, we aim to unlock better computational efficiency and scalability on modern ARM hardware.

This PR builds upon and extends the SVE work introduced in PR #25238

Performance Analysis:

Results are captured from sve 256,128 and SVE 512 supported machines.
This PR is a joint contribution by:

• Aruna K(@akote123)
• Nikhil R Sharma(@nikhilfujitsu)
• Abhishek Jain(@abhijain1204fujitsu)

[akote123]

@akote123 please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@microsoft-github-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

Contribution License Agreement

This Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”), and conveys certain license rights to Microsoft Corporation and its affiliates (“Microsoft”) for Your contributions to Microsoft open source projects. This Agreement is effective as of the latest signature date below.

1. Definitions.
   “Code” means the computer software code, whether in human-readable or machine-executable form,
   that is delivered by You to Microsoft under this Agreement.
   “Project” means any of the projects owned or managed by Microsoft and offered under a license
   approved by the Open Source Initiative (www.opensource.org).
   “Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any
   Project, including but not limited to communication on electronic mailing lists, source code control
   systems, and issue tracking systems that are managed by, or on behalf of, the Project for the purpose of
   discussing and improving that Project, but excluding communication that is conspicuously marked or
   otherwise designated in writing by You as “Not a Submission.”
   “Submission” means the Code and any other copyrightable material Submitted by You, including any
   associated comments and documentation.
2. Your Submission. You must agree to the terms of this Agreement before making a Submission to any
   Project. This Agreement covers any and all Submissions that You, now or in the future (except as
   described in Section 4 below), Submit to any Project.
3. Originality of Work. You represent that each of Your Submissions is entirely Your original work.
   Should You wish to Submit materials that are not Your original work, You may Submit them separately
   to the Project if You (a) retain all copyright and license information that was in the materials as You
   received them, (b) in the description accompanying Your Submission, include the phrase “Submission
   containing materials of a third party:” followed by the names of the third party and any licenses or other
   restrictions of which You are aware, and (c) follow any other instructions in the Project’s written
   guidelines concerning Submissions.
4. Your Employer. References to “employer” in this Agreement include Your employer or anyone else
   for whom You are acting in making Your Submission, e.g. as a contractor, vendor, or agent. If Your
   Submission is made in the course of Your work for an employer or Your employer has intellectual
   property rights in Your Submission by contract or applicable law, You must secure permission from Your
   employer to make the Submission before signing this Agreement. In that case, the term “You” in this
   Agreement will refer to You and the employer collectively. If You change employers in the future and
   desire to Submit additional Submissions for the new employer, then You agree to sign a new Agreement
   and secure permission from the new employer before Submitting those Submissions.
5. Licenses.

• Copyright License. You grant Microsoft, and those who receive the Submission directly or
  indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license in the
  Submission to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute
  the Submission and such derivative works, and to sublicense any or all of the foregoing rights to third
  parties.
• Patent License. You grant Microsoft, and those who receive the Submission directly or
  indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license under
  Your patent claims that are necessarily infringed by the Submission or the combination of the
  Submission with the Project to which it was Submitted to make, have made, use, offer to sell, sell and
  import or otherwise dispose of the Submission alone or with the Project.
• Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement.
  No additional licenses or rights whatsoever (including, without limitation, any implied licenses) are
  granted by implication, exhaustion, estoppel or otherwise.

6. Representations and Warranties. You represent that You are legally entitled to grant the above
   licenses. You represent that each of Your Submissions is entirely Your original work (except as You may
   have disclosed under Section 3). You represent that You have secured permission from Your employer to
   make the Submission in cases where Your Submission is made in the course of Your work for Your
   employer or Your employer has intellectual property rights in Your Submission by contract or applicable
   law. If You are signing this Agreement on behalf of Your employer, You represent and warrant that You
   have the necessary authority to bind the listed employer to the obligations contained in this Agreement.
   You are not expected to provide support for Your Submission, unless You choose to do so. UNLESS
   REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING, AND EXCEPT FOR THE WARRANTIES
   EXPRESSLY STATED IN SECTIONS 3, 4, AND 6, THE SUBMISSION PROVIDED UNDER THIS AGREEMENT IS
   PROVIDED WITHOUT WARRANTY OF ANY KIND, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY OF
   NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
7. Notice to Microsoft. You agree to notify Microsoft in writing of any facts or circumstances of which
   You later become aware that would make Your representations in this Agreement inaccurate in any
   respect.
8. Information about Submissions. You agree that contributions to Projects and information about
   contributions may be maintained indefinitely and disclosed publicly, including Your name and other
   information that You submit with Your Submission.
9. Governing Law/Jurisdiction. This Agreement is governed by the laws of the State of Washington, and
   the parties consent to exclusive jurisdiction and venue in the federal courts sitting in King County,
   Washington, unless no federal subject matter jurisdiction exists, in which case the parties consent to
   exclusive jurisdiction and venue in the Superior Court of King County, Washington. The parties waive all
   defenses of lack of personal jurisdiction and forum non-conveniens.
10. Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and
    supersedes any and all prior agreements, understandings or communications, written or oral, between
    the parties relating to the subject matter hereof. This Agreement may be assigned by Microsoft.

@microsoft-github-policy-service agree company=“Fujitsu Research of India Private Ltd”

[akote123]

CC: @edgchen1 , @hariharans29

[hariharans29]

Please address the build failures and please run onnxruntime_mlas_test in your env with your change and report any failures if any here.

[akote123]

onnxruntime_mlas_test
@hariharans29 ,
Thank you. I have fixed CI failures and tested onxruntime_mlas_test in gr3, with #26203 fix all tests are passing

[hariharans29]

/azp run Linux QNN CI Pipeline, Win_TRT_Minimal_CUDA_Test_CI, Windows ARM64 QNN CI Pipeline, Windows GPU Doc Gen CI Pipeline, Windows x64 QNN CI Pipeline

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[hariharans29]

Have you tried this on multiple Gemm problem shapes - Please submit comprehensive micro-benchmarks for all SVE platforms.

I tried taking this change on a Graviton4 and for a Conv heavy model (which uses Im2Col + SGemm for the Conv implementation), it slows down the model very much - when I build with --no_sve, the perf is fine again. So, it seems like this Gemm implementation is not performant for all Gemm shapes yet.

[akote123]

Have you tried this on multiple Gemm problem shapes - Please submit comprehensive micro-benchmarks for all SVE platforms.

I tried taking this change on a Graviton4 and for a Conv heavy model (which uses Im2Col + SGemm for the Conv implementation), it slows down the model very much - when I build with --no_sve, the perf is fine again. So, it seems like this Gemm implementation is not performant for all Gemm shapes yet.

Yes. I have tried on different shapes ,and for large shapes tuning is required. This PR is added as patch to enable sve for gemm kernel and for larger shapes this gemm implementation has to be tuned and we are currently working on that.

[hariharans29]

Hi @akote123: Any plan to resume this work ? Or at the very least, can you please guide what remains to be done for perf tuning ?

[akote123]

@hariharans29 ,Thank you. We will resume this work .This PR we planned as SVE sgemm enablement work and do performance tuning as future task and contribute

[akote123]

@hariharans29 ,Thank you
Updated the PR with latest code changes, where for sve 128 it falls back to NEON and for SVE 256 and 512 it fllows SVE path.

Below table shows shape wise timing:

GEMM Performance Comparison (time in ms)

M	K	N	gr3 (32C) MLAS_SVE	gr3 (32C) MLAS_NEON	fx700 (48C) MLAS_SVE	fx700 (48C) MLAS_NEON
3072	3072	3072	26.499	30.603	45.63	190.72
256	3072	3072	2.196	2.68	6.86	19.77
256	2048	2048	1.047	1.177	2.384	10.599
2048	2048	256	1.015	1.145	3.87	20.5
2048	2048	2048	8.152	9.244	34.98	56.094

[hariharans29]

Thanks for this. I have a few PRs ahead of this in the review queue and I will get to this soon ! Meanwhile, I am happy to kick off CI and Copilot reviewing in the background.

Also there is another SVE based Gemm implementation coming in (from KleidiAI) - Need to study the overlap and synergize

#27643

[hariharans29]

/azp run Linux QNN CI Pipeline, Win_TRT_Minimal_CUDA_Test_CI, Windows ARM64 QNN CI Pipeline, Windows GPU Doc Gen CI Pipeline, Windows x64 QNN CI Pipeline

[azure-pipelines]

No pipelines are associated with this pull request.

[Copilot]

Pull request overview

This PR adds ARM SVE (Scalable Vector Extension) support for the MLAS SGEMM (single-precision GEMM) path by introducing SVE-specific SGEMM kernels and wiring them into the existing packing/transposition and kernel dispatch logic.

Changes:

• Introduces new SVE SGEMM kernel + helper routines (compute, transpose/pack, load/store, zero-init).
• Integrates runtime dispatch to SVE implementations when MLAS_USE_SVE is enabled and the CPU reports SVE support.
• Updates the MLAS CMake wiring to compile and include the new SVE SGEMM source.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
onnxruntime/core/mlas/lib/sve/sgemm_sve.cpp	Adds SVE SGEMM kernels plus SVE packing/transpose helpers.
onnxruntime/core/mlas/lib/sve/mlasi_sve.h	Declares new SVE SGEMM/packing entrypoints and constants.
onnxruntime/core/mlas/lib/sgemm.cpp	Routes packing/transposition and kernel dispatch to SVE at runtime when available.
onnxruntime/core/mlas/lib/mlasi.h	Extends the fallback CPUID info class (non-ORT build) with SVE-related capability accessors/state.
cmake/onnxruntime_mlas.cmake	Adds the new SVE SGEMM source file and compilation flags to the build.

Comments suppressed due to low confidence (1)

onnxruntime/core/mlas/lib/mlasi.h:204

• The BUILD_MLAS_NO_ONNXRUNTIME fallback CPUID class now defines HasArmSVE() (twice) but the rest of MLAS uses HasArmSve(). This introduces a duplicate method definition and will also break builds that compile MLAS outside ONNX Runtime. Rename/restore the method to HasArmSve() (single definition) to match existing call sites.

    // ARM
    bool HasArmNeonDot() const { return has_arm_neon_dot_; }
      bool HasArmSVE() const { return has_arm_sve_; }

    bool HasFp16VectorAcceleration() const { return has_fp16_; }

    uint32_t GetCurrentCoreIdx() const { return 0xFFFFFFFF; }

    int32_t GetCurrentUarch() const { return -1; }

    int32_t GetCoreUarch(uint32_t coreId) const { return -1; }

    bool IsCoreArmv8NarrowLd(uint32_t coreId) const { return false; }

    bool IsCurrentCoreArmv8NarrowLd() const { return false; }

    bool HasArmNeon_I8MM() const { return has_arm_neon_i8mm_; }

    bool HasArmSVE() const { return has_arm_sve_; }

    bool HasArmSVE_I8MM() const { return has_arm_sve_i8mm_; }

    bool HasArmNeon_BF16() const { return has_arm_neon_bf16_; }

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[akote123]

Thanks for this. I have a few PRs ahead of this in the review queue and I will get to this soon ! Meanwhile, I am happy to kick off CI and Copilot reviewing in the background.

Also there is another SVE based Gemm implementation coming in (from KleidiAI) - Need to study the overlap and synergize

#27643

Ok. Thank you hariharans29.

[hariharans29]

Please update/resolve the comments if you are addressing them in a commit. It is very hard to gauge which comments have been addressed just by looking at the commit.

Please address the conflict too so that the next run can be kicked off.

[akote123]

@hariharans29,Resolved all the comments and merge conflicts .

[hariharans29]

@hariharans29,Resolved all the comments and merge conflicts .

Hi Aruna - I still see some comments from sept 2025 and I still see conflicts too. Can you please take a look ?

[hariharans29]

Btw - since KleidiAI is also supporting SVE based SGemm, is this PR needed ? Do you know the perf compairson between the KleidiAI SVE SGemm implementation vs this implementation ?

[akote123]

Btw - since KleidiAI is also supporting SVE based SGemm, is this PR needed ? Do you know the perf compairson between the KleidiAI SVE SGemm implementation vs this implementation ?

hariharans29,
With this PR we wanted to enable SVE SGEMM support directly within the MLAS library, without introducing a dependency on any external kernel library.
With the planned packing kernel improvements as a follow-up, we expect the performance to be comparable to kleidi implementations.

[hariharans29]

Btw - since KleidiAI is also supporting SVE based SGemm, is this PR needed ? Do you know the perf compairson between the KleidiAI SVE SGemm implementation vs this implementation ?

hariharans29, With this PR we wanted to enable SVE SGEMM support directly within the MLAS library, without introducing a dependency on any external kernel library. With the planned packing kernel improvements as a follow-up, we expect the performance to be comparable to kleidi implementations.

Thanks @akote123. We already have an existing dependency on KleidiAI - please hold off of any more updates/effort to this PR. I will have to check internally what the guidance is from my leadership and get back.

[akote123]

@hariharans29,During benchmarking on AWS Graviton4, I observed that the Kleidi-sgemm path is currently slower than the NEON baseline for the tested workload(T5,Jina,E5).
In this current PR,I have added fallback to NEON for SVE128.

[akote123]

@harihara

Btw - since KleidiAI is also supporting SVE based SGemm, is this PR needed ? Do you know the perf compairson between the KleidiAI SVE SGemm implementation vs this implementation ?

hariharans29, With this PR we wanted to enable SVE SGEMM support directly within the MLAS library, without introducing a dependency on any external kernel library. With the planned packing kernel improvements as a follow-up, we expect the performance to be comparable to kleidi implementations.

Thanks @akote123. We already have an existing dependency on KleidiAI - please hold off of any more updates/effort to this PR. I will have to check internally what the guidance is from my leadership and get back.

Hi @hariharans29 ,just following up on this—Any update on this ? Please let me know if any updates or further changes are needed from my side

[hariharans29]

@harihara

Btw - since KleidiAI is also supporting SVE based SGemm, is this PR needed ? Do you know the perf compairson between the KleidiAI SVE SGemm implementation vs this implementation ?

hariharans29, With this PR we wanted to enable SVE SGEMM support directly within the MLAS library, without introducing a dependency on any external kernel library. With the planned packing kernel improvements as a follow-up, we expect the performance to be comparable to kleidi implementations.

Thanks @akote123. We already have an existing dependency on KleidiAI - please hold off of any more updates/effort to this PR. I will have to check internally what the guidance is from my leadership and get back.

Hi @hariharans29 ,just following up on this—Any update on this ? Please let me know if any updates or further changes are needed from my side

Thanks @akote123 for the follow up. Let me get back by the end of this week.

[akote123]

Thanks @akote123 for the follow up

Thank you @hariharans29.

[hariharans29]

Hi @akote123 - I would like to run this by one of our contacts to get more feedback. Could you please give me one more week ?

One thought I had was to see if we could use the Mlas Backend Kernel Selector (with default to off for sve gemm) ? I feel like we have limited perf data to turn this on by default. What are your thoughts on this ?

[akote123]

Hi @akote123 - I would like to run this by one of our contacts to get more feedback. Could you please give me one more week ?

One thought I had was to see if we could use the Mlas Backend Kernel Selector (with default to off for sve gemm) ? I feel like we have limited perf data to turn this on by default. What are your thoughts on this ?

@hariharans29, Thank you for update.
Regarding "Mlas Backend Kernel Selector (with default to off for sve gemm)" - As for currently perf improvements are seen for SVE 256 and SVE 512 we can enable SVE for GEMM and we can add dispatcher that for sve 128 calls NEON instead of SVE as below:
`

   if (svcntw() == 4u) {
    size_t rows = MlasSgemmKernelAdd(A, B, C, CountK, CountM, CountN, lda, ldc, alpha);
    return rows;
   }   
   else {
        SVE flow
`

[hariharans29]

Hi @akote123 - I would like to run this by one of our contacts to get more feedback. Could you please give me one more week ?
One thought I had was to see if we could use the Mlas Backend Kernel Selector (with default to off for sve gemm) ? I feel like we have limited perf data to turn this on by default. What are your thoughts on this ?

@hariharans29, Thank you for update. Regarding "Mlas Backend Kernel Selector (with default to off for sve gemm)" - As for currently perf improvements are seen for SVE 256 and SVE 512 we can enable SVE for GEMM and we can add dispatcher that for sve 128 calls NEON instead of SVE as below: `

   if (svcntw() == 4u) {
    size_t rows = MlasSgemmKernelAdd(A, B, C, CountK, CountM, CountN, lda, ldc, alpha);
    return rows;
   }   
   else {
        SVE flow
`

Sorry - re-visiting this just now. Do we have perf data across a large bunch of representative M,N,K shapes for SVE 256 and 512 - or have you measured perf only across the 4 models listed in the PR description ? Personally, I am leaning towards including SVE SGemm support in MLAS and defaulting it to off (via the Mlas backend kernel selector) and allowing the user to opt-in to using this feature - atleast for 1 or 2 releases. We can announce the feature via release notes and get perf feedback. We can turn it on my default in a future release once we are satisifed it hasn't broken anything.

[hariharans29]

Could you please re-base with main (and integrate with the Mlas backend kernel selector) ? Once done, I will prioritize merging this - thanks

[akote123]

Could you please re-base with main (and integrate with the Mlas backend kernel selector) ? Once done, I will prioritize merging this - thanks

Sure .I will update with patch to integrate with the Mlas backend kernel selector.
I have also captured shape wise timing as well . Will take it again after this patch and rebase and will share it here.
Thank you @hariharans29.

[akote123]

@hariharans29,
Rebased and integrated with the Mlas backend kernel selector for sve sgemm.
The shapewise performance results on g3E are as follows:
(timings are in ms and tested in 64C machine)

M	K	N	MLAS_SVE	MLAS_NEON
3072	3072	3072	15.05	17.69
256	3072	3072	1.326	1.403
256	2048	2048	0.609	0.720
2048	2048	256	0.613	0.874
2048	2048	2048	4.800	6.053
256	256	256	0.061	0.063