Skip to content
Open
Show file tree
Hide file tree
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion cmake/deps.txt
Original file line number Diff line number Diff line change
Expand Up @@ -56,5 +56,5 @@ extensions;https://github.com/microsoft/onnxruntime-extensions/archive/c24b7bab0
directx_headers;https://github.com/microsoft/DirectX-Headers/archive/refs/tags/v1.613.1.zip;47653509a3371eabb156360f42faf582f314bf2e
cudnn_frontend;https://github.com/NVIDIA/cudnn-frontend/archive/refs/tags/v1.12.0.zip;7e733cfdc410d777b76122d64232499205589a96
dawn;https://github.com/google/dawn/archive/13c1635a14574ebb7116b56a69f5519301417fda.zip;0aadd28fc385cf7d657d5fc70a352372d2d3c76a
kleidiai;https://github.com/ARM-software/kleidiai/archive/refs/tags/v1.10.0.tar.gz;11b62149cb2514b3b9069cc435c3aa7a4e82b97a
kleidiai;https://github.com/ARM-software/kleidiai/archive/refs/tags/v1.15.0.tar.gz;62ccd24ab60bcef68766440fb42d79071ac2a5d2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this update in the KAI version from 1.10 to 1.15, can SME/SME2 detection be enabled on Windows too to leverage the kernels ?

https://github.com/microsoft/onnxruntime/pull/25187/files#r2223006773
https://github.com/microsoft/onnxruntime/pull/25760/files#r2325260570

duktape;https://github.com/svaarala/duktape/releases/download/v2.7.0/duktape-2.7.0.tar.xz;8200c8e417dbab7adcc12c4dbdef7651cfc55794
165 changes: 141 additions & 24 deletions onnxruntime/core/mlas/lib/kleidiai/qgemm_kleidiai.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -11,10 +11,19 @@
#include "kai/ukernels/matmul/pack/kai_rhs_pack_kxn_qsi8cxp_qsi8cx_neon.h"

#include "kai/ukernels/matmul/matmul_clamp_f32_qai8dxp_qsi8cxp/kai_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme2_mopa.h"
#include "kai/ukernels/matmul/matmul_clamp_f32_qai8dxp_qsi8cxp/kai_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme_mopa.h"
#include "kai/ukernels/matmul/matmul_clamp_f32_qai8dxp_qsi8cxp/kai_matmul_clamp_f32_qai8dxp1x4_qsi8cxp4vlx4_1x4vl_sme2_dot.h"

#include "mlasi_kleidiai.h"

// Thread-local reusable buffers to reduce allocation overhead across tiles.
struct KaiTlsBuffersQgemm {
std::vector<float> output_tile;
std::vector<float> bias_zero;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is bias_zero used somewhere ?

Copy link
Author

@melkap01-Arm melkap01-Arm Oct 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

addressed in the new commit

std::vector<std::byte> lhs_packed;
};
static thread_local KaiTlsBuffersQgemm g_kai_tls_qgemm;

//Matmul with float output of dynamic quantized A and symmetric quantized B.

size_t
Expand Down Expand Up @@ -78,39 +87,147 @@ MLASCALL
ArmKleidiAI::MlasDynamicQGemmBatch(
const MLAS_GEMM_DYN_QUANT_SHAPE_PARAMS& Shape,
const MLAS_GEMM_DYN_QUANT_DATA_PARAMS* DataParams,
const size_t BatchN,
const size_t BatchSize,
MLAS_THREADPOOL* ThreadPool
) {
for (auto b = BatchN; b > 0; --b,++DataParams) {
auto mr = kai_get_mr_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme2_mopa();
auto kr = kai_get_kr_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme2_mopa();
auto sr = kai_get_sr_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme2_mopa();

const size_t mr = UseSME2 ? kai_get_mr_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme2_mopa()
: kai_get_mr_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme_mopa();
const size_t kr = UseSME2 ? kai_get_kr_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme2_mopa()
: kai_get_kr_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme_mopa();
const size_t sr = UseSME2 ? kai_get_sr_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme2_mopa()
: kai_get_sr_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme_mopa();

//TODO enable multi-threading for lhs packing and matmul
MLAS_UNREFERENCED_PARAMETER(ThreadPool);
size_t m_step = UseSME2 ? kai_get_m_step_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme2_mopa()
: kai_get_m_step_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme_mopa();
size_t n_step = UseSME2 ? kai_get_n_step_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme2_mopa()
: kai_get_n_step_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme_mopa();

//Dynamic Quantize A - lhs
auto lhs_size = kai_get_lhs_packed_size_lhs_quant_pack_qai8dxp_f32(Shape.M, Shape.K, mr, kr, sr);
std::byte* lhs = nullptr;
std::unique_ptr<std::byte[]> fallback;

if (DataParams->Workspace && DataParams->WorkspaceSize >= lhs_size) {
lhs = static_cast<std::byte*>(DataParams->Workspace);
if (Shape.M == 0 || Shape.N == 0) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be a Shape.K check for completeness ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

addressed in the newest commit.

return;
}
if ((Shape.M < m_step || Shape.N < n_step) && !DataParams->PackedB) {
// Fallback to MLAS
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is no fallback implementation of MlasDynamicQGemmBatch().

#if defined(USE_KLEIDIAI) && !defined(_MSC_VER)
//No fallback and putting in guards
if(MLAS_CPUIDINFO::GetCPUIDInfo().HasArm_SME()){
ArmKleidiAI::MlasDynamicQGemmBatch(Shape, DataParams, BatchN, ThreadPool);
}
#endif
MLAS_UNREFERENCED_PARAMETER(Shape);
MLAS_UNREFERENCED_PARAMETER(DataParams);
MLAS_UNREFERENCED_PARAMETER(BatchN);
MLAS_UNREFERENCED_PARAMETER(ThreadPool);

if we get to this point, the computation should happen or (maybe less preferably) it should be a hard error.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will investigate the fallback case further and try to provide better implementation.
Until then, would like to get your opinion on using ORT_ENFORCE

ORT_ENFORCE(false, "ArmKleidiAI::MlasDynamicQGemmBatch(): unsupported small-shape case (M < m_step or N < n_step)");

Copy link
Member

@hariharans29 hariharans29 Oct 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we instead implement @edgchen1's suggestion in the other PR: #26302 (comment) to have a universal check that can be used in all places to check if MLAS supports QGemm for that problem shape, platform, etc. ?

Also since we have a check on the M dimension, this might need some thinking - In the current setup, we turn off MLAS usage for QGemm in PrePack() if we don't detect SME or the weight's shape don't match requirements in PrePack(). See here and here. The M dimension won't be known in PrePack().

Just curious - what would happen if the M was < m_step ? Would there be a crash or would the perf be sub-optimal ? If so, we need to add a runtime check in the CPU kernel's Run() function which means we may need to perform pre-packing for both KAI and the "regular" path. See here.

return;
}

//Dynamic Quantize A - lhs
const size_t LhsPackedStride = kai_get_lhs_packed_size_lhs_quant_pack_qai8dxp_f32(Shape.M, Shape.K, mr, kr, sr);
std::byte* LhsPackedData = nullptr;

if (g_kai_tls_qgemm.lhs_packed.capacity() < LhsPackedStride * BatchSize) {

g_kai_tls_qgemm.lhs_packed.reserve(LhsPackedStride * BatchSize);
}
g_kai_tls_qgemm.lhs_packed.resize(LhsPackedStride * BatchSize);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we just do the resizing directly instead of reserve + resize ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, reserve() + resize() or using only resize() cases both end up with one allocation + one initialisation. But somehow there is a very very little performance difference in the case allocation and initialisation separated or done at once with resize(). (after: is the case reserve() calls removed and only resize() is used.)
ort_ops_compare_2_thread_before_2025-10-29_13-08-56_vs_2_thread_after_2025-10-29_13-32-05

LhsPackedData = g_kai_tls_qgemm.lhs_packed.data();

//Per-batch table of lhs
std::vector<const std::byte*> LhsBase(BatchSize);
Copy link
Member

@hariharans29 hariharans29 Oct 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a thought - Can this vector containing the per-batch address be moved into the KaiTlsBuffersQgemm struct and be re-sized when it's size is less than the BatchSize ?

The pro of that approach:

  1. We generally expect the BatchSize to be stable across runs and that will mean we can do away with the dynamic memory allocation latency variance that comes with using std::vector

The con of that approach:

  1. The size of that caching vector will be bound by the highest batch size that the kernel will encounter.

Given that the batch sizes are generally stable across different runs, I am thinking the pro might outweight the con ?

What are your thoughts on this ?

Copy link
Author

@melkap01-Arm melkap01-Arm Oct 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an idea worth to try and measure the impact.
I implemented it and the results with single thread:

ort_ops_compare_single_thread_before_2025-10-30_10-17-10_vs_single_thread_after_2025-10-30_14-24-15

and 2 threads :
ort_ops_compare_2_thread_before_2025-10-30_10-17-38_vs_2_thread_after_2025-10-30_14-24-29

After: Lhsbase is moved inside the TLS structure. Before: LhaBase is a local buffer shared with the threads.

here is the implementation:

      //Per-batch table of lhs
    if (g_kai_tls_qgemm.LhsBase.capacity() < BatchSize) {
        g_kai_tls_qgemm.LhsBase.reserve(BatchSize);
    }
      g_kai_tls_qgemm.LhsBase.resize(BatchSize);
    // Capture the shared batch table pointer so worker threads use the same backing storage.
    const std::byte** tls_lhs_base = g_kai_tls_qgemm.LhsBase.data();
      // B batches require no packing
        ⋮
          kai_run_lhs_quant_pack_qai8dxp_f32(Shape.M, Shape.K, mr, kr, sr, 0, DataParams[batch_idx].A, DataParams[batch_idx].lda*sizeof(float), lhs);

        tls_lhs_base[batch_idx] = lhs;
      });
        ⋮

        const std::byte* A_base = tls_lhs_base[BIdx]; // LhsPackedData + LhsPackedStride * BIdx; OR DataParams[batch_idx].Workspace;
         auto ATile = reinterpret_cast<const std::byte*>(A_base + lhs_packed_offset);

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect perf-wise there isn't much difference but it is coming from a performance variance POV. If we performed dynamic memory allocations on every Run(), I suspect we may see some latency variance. I was just wonderinf if this can be avoided as in most cases, usually the Gemm problem shapes stay the same across invocations. Let us dynamically resize only when we encounter a change of shape (batch size). Hope the motivation of the comment is clear now.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Motivation behind the comment is clear, if we expect generally stable batches, reusing its capacity across calls is making sense. If the performance results also acceptable we are all good with this idea. Please find the implementation in the latest commit.

// B batches require no packing
// We have already decided the matmul variant we are using, before having values for M,N,K
MlasTrySimpleParallel(ThreadPool, BatchSize, [&](ptrdiff_t batch_idx) {

std::byte* lhs = nullptr;
if (DataParams[batch_idx].Workspace && DataParams[batch_idx].WorkspaceSize >= LhsPackedStride) {
lhs = static_cast<std::byte*>(DataParams[batch_idx].Workspace);
} else {
fallback = std::make_unique<std::byte[]>(lhs_size);
lhs = fallback.get();
lhs = &(LhsPackedData[LhsPackedStride * batch_idx]);
}

kai_run_lhs_quant_pack_qai8dxp_f32(Shape.M, Shape.K, mr, kr, sr, 0, DataParams->A,
Shape.K*sizeof(float), lhs);
kai_run_lhs_quant_pack_qai8dxp_f32(Shape.M, Shape.K, mr, kr, sr, 0, DataParams[batch_idx].A, DataParams[batch_idx].lda*sizeof(float), lhs);
LhsBase[batch_idx] = lhs;
});

// tile iteration dimensions
std::array<size_t, 3> dim;
dim[0] = BatchSize; // B
dim[1] = MlasDivRoundup(Shape.M, m_step); // M
dim[2] = MlasDivRoundup(Shape.N, n_step); // N

// Minimize the kernel call count for the number of available threads
auto RequiredTiles = std::min(static_cast<size_t>(MlasGetMaximumThreadCount(ThreadPool)), dim[0] * dim[1] * dim[2]);

// scale required tiles over available tile processors
dim[1] = MlasDivRoundup(RequiredTiles * dim[1], dim[1] * dim[2]);
dim[2] = MlasDivRoundup(RequiredTiles * dim[2], dim[1] * dim[2]);

kai_run_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme2_mopa(
Shape.M, Shape.N, Shape.K, lhs, DataParams->PackedB,
DataParams->C,
Shape.N * sizeof(float),
sizeof(float),
-std::numeric_limits<float>::max(), std::numeric_limits<float>::max()
// compute new step sizes
m_step *= MlasDivRoundup(MlasDivRoundup(Shape.M, dim[1]), m_step);
n_step *= MlasDivRoundup(MlasDivRoundup(Shape.N, dim[2]), n_step);

// update tile iterations
dim[1] = MlasDivRoundup(Shape.M, m_step);
dim[2] = MlasDivRoundup(Shape.N, n_step);

MlasTrySimpleParallel(ThreadPool, static_cast<ptrdiff_t>(dim[0] * dim[1] * dim[2]), [=](ptrdiff_t tid) {

// compute B,M,N index from iteration index
ptrdiff_t BIdx = tid / (dim[1] * dim[2]);
ptrdiff_t MIdx = (tid % (dim[1] * dim[2])) / dim[2];
ptrdiff_t NIdx = (tid % (dim[1] * dim[2])) % dim[2];

// Get rhs tile, B
const size_t rhs_packed_offset =
UseSME2 ? kai_get_rhs_packed_offset_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme2_mopa(NIdx * n_step, Shape.K)
: kai_get_rhs_packed_offset_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme_mopa(NIdx * n_step, Shape.K);

const std::byte* B_base = reinterpret_cast<const std::byte*>(DataParams[BIdx].PackedB);
auto BTile = reinterpret_cast<const void*>(B_base + rhs_packed_offset);

// Get lhs tile, A
const size_t lhs_packed_offset =
UseSME2 ? kai_get_lhs_packed_offset_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme2_mopa(MIdx * m_step, Shape.K)
: kai_get_lhs_packed_offset_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme_mopa(MIdx * m_step, Shape.K);

const std::byte* A_base = LhsBase[BIdx]; // LhsPackedData + LhsPackedStride * BIdx; OR DataParams[batch_idx].Workspace;
auto ATile = reinterpret_cast<const std::byte*>(A_base + lhs_packed_offset);

auto TileSizeM = (MIdx + 1) * m_step > Shape.M ? (Shape.M - MIdx * m_step) : m_step;
auto TileSizeN = (NIdx + 1) * n_step > Shape.N ? (Shape.N - NIdx * n_step) : n_step;

// Get result tile, C
auto CTile = reinterpret_cast<void*>(
reinterpret_cast<std::byte*>(DataParams[BIdx].C) +
MIdx * m_step * DataParams[BIdx].ldc * sizeof(float) +
NIdx * n_step * sizeof(float)
);
}
// Allocate temporary buffer for raw A*B result (TLS reusable buffer)
{
const size_t tile_elems = TileSizeM * TileSizeN;
if (g_kai_tls_qgemm.output_tile.capacity() < tile_elems) {
// reserve more memory if required
g_kai_tls_qgemm.output_tile.reserve(tile_elems);
}
// resize the tile to the required size (doesn't effect memory)
g_kai_tls_qgemm.output_tile.resize(tile_elems);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto - Is Reserve + Resize necessary ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same above

}
float* temp_tile = g_kai_tls_qgemm.output_tile.data();
std::fill_n(temp_tile, TileSizeM * TileSizeN, 0.0f);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this buffer zeroing absolutely needed (i.e.) Does the micro-kernel accumulate into the existing contents ?

Is there a concept of dis-reagrding existing contents in the output buffer in the micro-kernel's interface ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can remove the fill_n, the kernel handles zeroing of the tile


if (UseSME2) {
kai_run_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme2_mopa(
TileSizeM, TileSizeN, Shape.K, ATile, BTile,
temp_tile,
TileSizeN * sizeof(float),
sizeof(float),
-std::numeric_limits<float>::max(), std::numeric_limits<float>::max()
);
}
else {
kai_run_matmul_clamp_f32_qai8dxp1vlx4_qsi8cxp4vlx4_1vlx4vl_sme_mopa(
TileSizeM, TileSizeN, Shape.K, ATile, BTile,
temp_tile,
TileSizeN * sizeof(float),
sizeof(float),
-std::numeric_limits<float>::max(), std::numeric_limits<float>::max()
);
}

// Final output tile pointer
float* dst_tile = reinterpret_cast<float*>(CTile);
std::memcpy(dst_tile, temp_tile, TileSizeM * TileSizeN * sizeof(float));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's the benefit of writing to a temporary buffer (temp_tile) and then copying it to dst_tile instead of directly writing to dst_tile?

Copy link
Author

@melkap01-Arm melkap01-Arm Oct 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea behind it was making the arithmetics on the temporary tile to be error prone as it was implemented on the sgemms. But I see making the calculations on the destination and writing directly is lowering the complexity.

instead of having the result in each TLS and copying to the destination tile, destination tile can have the result directly.
Measuring the impact :
single thread:

ort_ops_compare_single_thread_no_fill_after_2025-10-30_15-28-05_vs_single_thread_no_temp_buffer_after_2025-10-30_16-39-27

2 threads :
ort_ops_compare_2_thread_no_fill_after_2025-10-30_15-28-19_vs_2_thread_no_temp_buffer_after_2025-10-30_16-39-43

return;
});
}
Loading