Accelerating Open-Source OpenCV with Portable SIMD

Jul 24, 2026

Over the past year, the AMD Optimizing CPU Libraries (AOCL) team has been upstreaming performance directly into OpenCV — so the primitives millions of developers already call run measurably faster on AMD, Intel, and Arm alike, with no code changes and no vendor lock-in.

Every image an application blurs, every frame a robot tracks, every histogram a medical tool equalizes — a little bit of that now runs faster for everyone, on every CPU, because the work went upstream into the project instead of into a private fork.

Why we upstream

There is an easy way and a hard way to make software fast on your hardware. The easy way is to ship a private, tuned fork and hand it to a few customers. The hard way — the one that actually moves the ecosystem — is to upstream the optimization into the project itself: defend it in code review, prove it does not regress anyone else’s platform, and let millions of developers get the speedup for free the next time they run pip install opencv-python.

AMD chose the hard way. Over the last year we have worked on performance improvements directly into opencv/opencv, the most widely used computer-vision library in the world. The goal is deliberately un-branded: make the primitives everybody already calls — medianBlur, GaussianBlur, cvtColor, remap, gemm, LUT, norm — measurably faster, using portable SIMD so the wins land across architectures.

figure 1

Portable by design: one kernel, every CPU

The engineering discipline here matters. Rather than gating fast paths behind an AMD-only library, the contributions are written against OpenCV’s Universal Intrinsics. A single implementation compiles down to AVX-512 on “Zen 5” (Turin) and “Zen 4” (Genoa), AVX2 on “Zen 2” (Rome), AVX-512 on Intel® Ice Lake, and NEON on Apple silicon. Every pull request is benchmarked across all of these before it merges, so a speedup on AMD is never a regression on someone else’s platform.

This is the opposite of a vendor fork. The same code path that makes an AMD EPYC™ Processor faster also helps an Arm-based edge device and an Intel workstation — which is precisely why the OpenCV maintainers are willing to take it.

Working in the open, one PR at a time

These wins did not arrive as a code drop thrown over the wall. Each optimization went in the way open source is supposed to work: as an individual pull request against opencv/opencv, discussed and defended in public, and merged only under the project’s own governance. In practice that meant a sustained engineering loop with the maintainers — regular pull-request review, cross-platform CI on every change, blocker triage when a kernel behaved differently on one target, and feedback cycles with the broader community until the patch was right for everyone, not just for AMD.

Much of that review was carried by OpenCV core maintainer Alexander Smorkalov, who validated each patch, pushed back where a fast path risked a regression, and ran the cross-platform scrutiny that lets a change land safely for millions of downstream developers. It is slower than shipping a private fork — and that is exactly the point. The result survives every future release because it lives in the project, reviewed and owned by the community.

The results

Two views of the same work. First the headline: how much faster the best case runs on AMD’s flagship “Zen 5” (Turin) part. Then the proof that these are not AMD-only tricks — the same kernels accelerate across five very different CPUs.

fig2
The largest multipliers come from cases where hand-tuned SIMD replaces a scalar fallback path entirely (for example, masked norm and LUT-based equalizeHist). Typical everyday cases see solid, portable gains rather than these peaks — the full per-server tables below tell the complete story.

Where the wins land

The optimized kernels sit across a typical computer-vision pipeline — from loading and reshaping an image, through filtering and feature extraction, to the statistics and linear algebra that downstream models depend on. Nearly every stage now has a tuned fast path.

Fig 3
The biggest multi-x wins land in preprocessing filters and pixel math, where SIMD replaces scalar fallbacks. Every kernel ships with a dedicated performance test — alongside correctness work such as race fixes and warning cleanups — so the gains stay measurable and stable.

The Full Picture, per Server

Speedup = optimized patch vs. reference (higher is better). Benchmarks were run on five targets: AMD Turin (EPYC™ 9005 series, “Zen 5”, AVX-512), AMD Genoa (EPYC™ 9004 series, “Zen 4”, AVX-512), AMD Rome (EPYC™ 7742, “Zen 2”, AVX2), Intel Ice Lake (AVX-512), and Apple Mac M5.¹

Fig 4

In review — peak (max) gain per server

Fig 5
² Measured against the 5.x baseline (port branches); the 4.x-merged kernels are equivalent. norm peaks come from masked cases where SIMD replaces a scalar fallback. Peak numbers exclude very small images (width < 320 px) that are dominated by dispatch overhead.

What “good” open-source contribution looks like

  • Portable code (Universal SIMD) over vendor-specific branches.
  • Cross-vendor benchmarking on every PR — no silent regressions.
  • Performance tests committed with optimization, so gains are reproducible.
  • Reviewed and merged in the open, under the project’s own governance.

What this adds up to

None of these functions are exotic. They are the everyday building blocks of vision pipelines, called billions of times a day across robotics, medical imaging, video analytics, and AI pre-processing. Making them faster in the shared upstream — portably, and under community review — means the benefit compounds: it reaches AMD customers, but also the entire OpenCV user base, and it keeps paying off with every future release. That is what “faster by default” means.

Browse the pull requests on GitHub.

Special thanks

None of this reaches users without the OpenCV community’s open review process. A special thank-you to the OpenCV community and core maintainer Alexander Smorkalov for validating and reviewing these patches — the careful scrutiny, cross-platform testing, and feedback are what make these optimizations safe to merge for everyone.

About the author

Madan Mohan Manokar — Principal Member of Technical Staff (PMTS), AMD; AOCL Team, Core Software Group. An active OpenCV contributor with 20+ merged PRs, Madan works on CPU performance for computer-vision, cryptography, and video compression — taking micro-architecture-aware optimizations upstream into open-source projects such as OpenCV and OpenSSL. Before joining AMD, he developed ultra-low-latency video-encoder and pre-processing algorithms for FPGA and CPU platforms. Find him on GitHub at @madanm3.

Related reading

Footnotes

Endnotes & disclaimer

¹ Testing conducted by AMD as of July 2026. Speedups are the ratio of the optimized (patched) OpenCV implementation to the pre-optimization baseline for the same function, measured with OpenCV’s own performance-test harness. Configurations tested: AMD Turin (EPYC 9005 series, “Zen 5”, AVX-512), AMD Genoa (EPYC 9004 series, “Zen 4”, AVX-512), AMD Rome (EPYC 7742, “Zen 2”, AVX2), Intel Ice Lake (AVX-512), and Apple Mac M5. “Peak” values are the best single measured case per server, excluding images narrower than 320 px, which are dominated by dispatch overhead. Actual performance will vary based on hardware, workload, image size, data type, compiler, and system configuration. All contributions referenced are public on github.com/opencv/opencv.

² System configurations. The bracketed values below are placeholders and must be replaced with the exact, verified specifications of each test machine before publication.

AMD Turin (“Zen 5”): AMD EPYC™ 9005-series [model, e.g. 9755 128-core] processor, [1P/2P; sockets used], SMT [on/off], [N×capacity] DDR5-[rated] (running at [effective] MT/s), BIOS [version], mitigations=[on/off], [NUMA nodes per socket], [core-pinning if any]. Software: OpenCV [version/commit], compiler [e.g. GCC 14.x], OS [distro + kernel].

AMD Genoa (“Zen 4”): AMD EPYC™ 9004-series [model] processor, [1P/2P; sockets used], SMT [on/off], [N×capacity] DDR5-[rated] (running at [effective] MT/s), BIOS [version], mitigations=[on/off], [NUMA nodes per socket], [core-pinning if any]. Software: OpenCV [version/commit], compiler [e.g. GCC 14.x], OS [distro + kernel].

AMD Rome (“Zen 2”): AMD EPYC™ 7742 64-core processor, [1P/2P; sockets used], SMT [on/off], [N×capacity] DDR4-[rated] (running at [effective] MT/s), BIOS [version], mitigations=[on/off], [NUMA nodes per socket], [core-pinning if any]. Software: OpenCV [version/commit], compiler [e.g. GCC 14.x], OS [distro + kernel].

Intel Ice Lake: Intel® Xeon® [model, e.g. Platinum 8xxx] processor (Ice Lake-SP, AVX-512), [1P/2P; sockets used], Hyper-Threading [on/off], [N×capacity] DDR4-[rated] (running at [effective] MT/s), BIOS [version], mitigations=[on/off], [NUMA config], [core-pinning if any]. Software: OpenCV [version/commit], compiler [e.g. GCC 14.x], OS [distro + kernel].

Apple Mac (M5): Apple M5 [variant, e.g. base/Pro/Max], [P+E core count], [unified memory capacity], macOS [version]. Software: OpenCV [version/commit], compiler [Apple clang version] (NEON).

The views expressed here are the author’s own. OpenCV is a trademark of its respective owners. AMD, the AMD Arrow logo, EPYC, Ryzen, and combinations thereof are trademarks of Advanced Micro Devices, Inc. Other product names are for informational purposes only and may be trademarks of their respective owners.

Share:

Related Blogs

View All Blogs