-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Add int8 support to ConvInteger #26585
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
@skottmckay, @yuslepukhin: could you please review the PR? Thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR extends the ConvInteger operator implementation to support all type combinations allowed by the ONNX specification, adding int8 support alongside the existing uint8 implementation. The changes enable models using int8 or mixed int8/uint8 quantized convolutions to execute without requiring custom kernels or operator rewrites.
- Templated the core computation logic to handle both uint8_t and int8_t element types for input (X) and weight (W) tensors
- Added signedness flags to the MLAS GEMM calls to correctly interpret the raw byte data based on runtime types
- Added explicit template instantiation for Im2col<int8_t> to support int8 input processing
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| onnxruntime/core/providers/cpu/quantization/conv_integer.cc | Refactored Compute into a templated ComputeInner method supporting all uint8/int8 combinations, updated kernel registration to accept both types, and added runtime dispatch logic |
| onnxruntime/core/util/math_cpu.cc | Added template instantiation for Im2col<int8_t, StorageOrder::NCHW> to support int8 input data |
| onnxruntime/test/providers/cpu/nn/conv_integer_test.cc | Added comprehensive test cases for u8s8 and s8s8 type combinations covering various scenarios (padding, groups, strides, 2D/3D) |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <[email protected]>
yuslepukhin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🕐
|
/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 successfully started running 4 pipeline(s). |
yuslepukhin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
![]()
|
The documentation pipeline failed. Here is the output:
|
Description
This change extends the
ConvIntegerimplementation to match the ONNX operator spec, which allows bothint8anduint8for the input tensors:ConvIntegerschema defines:T1:tensor(int8)ortensor(uint8)T2:tensor(int8)ortensor(uint8)T3:tensor(int32)uint8×uint8combination was supported.uint8×uint8(existing behavior)uint8×int8int8×uint8int8×int8Motivation and Context
Fixes #24183
Fixes #15888
Fixes #12558
Fixes #3130
Fixes #12362
The ONNX ConvInteger operator schema allows both int8 and uint8 element types for its inputs, but the current implementation only supports uint8 × uint8. This leads to a gap where valid ONNX models using ConvInteger with int8 tensors cannot be executed.
This PR closes that gap by:
Aligning the implementation with the official ConvInteger type constraints.
Enabling models that use int8 (or mixed int8/uint8) for X and W to run without needing operator rewrites or additional custom kernels.
Keeping existing uint8 behavior unchanged, so the change is backwards compatible for current users.
Implementation details
The core logic of ConvInteger::Compute is moved into a templated helper:
XT is the element type of X (uint8_t or int8_t).
WT is the element type of W (uint8_t or int8_t).
Zero-point handling
Zero points are still treated as per-tensor scalar values, with the same validation,
The values are read via
DataRaw()and stored as 8-bit scalars, preserving the previous behavior.Interpretation of these raw bytes as signed or unsigned is delegated to the GEMM implementation via explicit signedness flags (see below).
Im2col templated on XT
The Im2col call now uses the runtime input type XT.
Quantized GEMM with signedness flags:
AIsSigned and BIsSigned are derived from the runtime types of W and X.
Data for A and B is passed as raw bytes, the GEMM implementation uses the signedness flags to interpret them correctly (In a manner similar to the implementation in
MatMulInteger).The public Compute method becomes a thin dispatcher that selects the appropriate ComputeInner<XT, WT> instantiation based on the actual input types.
In addition, a small set of unit tests is added on top of the existing ConvInteger tests to cover the new type combinations, including cases where the first input tensor contains negative values (for the int8 × int8 path).