BLIS: a framework for instantiating BLAS-like libraries, not another BLAS build

The problem BLIS solves: porting dense linear algebra without rewriting it

Writing a fast matrix multiplication for one CPU is a known exercise. Repeating it for every new core, cache hierarchy and vector width is not, and that repetition is what BLIS is built to avoid. The README describes BLIS as "a portable software framework for instantiating high-performance BLAS-like dense linear algebra libraries", and the word doing the work there is instantiating. You do not get a finished library so much as a generator for one.

The audience is narrow and identifiable. It is people who maintain a numerical stack across more than one architecture, people who need a BLAS-shaped library whose internals they can retune, and researchers who want to add an operation that the standard BLAS interface does not expose. Application programmers who simply want a fast dgemm on x86 and never intend to touch a kernel are served adequately by what they already have.

The project is developed by the Science of High-Performance Computing group at the Oden Institute, University of Texas at Austin, and the Matthews Research Group at Southern Methodist University. It carries the 2023 James H. Wilkinson Prize for Numerical Software and a 2020 SIAM Activity Group on Supercomputing Best Paper Prize, both cited in the README. The last push to the default branch was on 2026-08-29, and the most recent tagged release is 2.1 from 2025-01-15.

How the framework is layered: kernels, blocksizes, configs and the control tree

The architecture follows from one observation: in dense linear algebra, a small number of computational kernels dominate the cost, and everything else is orchestration. BLIS keeps the orchestration in the framework and pushes the kernels out to per-architecture code. The top-level repository layout makes the split visible. frame/ holds the framework proper, kernels/ holds optimized kernels, ref_kernels/ holds portable reference versions, config/ holds the per-architecture configurations, and blastest/ and testsuite/ hold the test harnesses.

A configuration under config/ supplies the pieces a port needs: which kernels to use, the cache and register blocksizes that shape the loops around them, and the microarchitecture details. Because the framework owns the loop structure, retuning for a new chip is largely a matter of supplying a new configuration and the kernels it names, rather than editing the library. The README points to the IPDPS'14 paper "Anatomy of High-Performance Many-Threaded Matrix Multiplication", which examines parallelism across the five loops the framework exposes in matrix multiplication. That is the real interface: not a function signature, but a loop nest you are allowed to reorganize.

On top of that sit three APIs. There is a new typed API documented in docs/BLISTypedAPI.md, an object-based API documented in docs/BLISObjectAPI.md, and a BLAS compatibility layer that exposes the implementation through traditional BLAS routine calls. The compatibility layer is what makes adoption incremental: existing code that calls BLAS keeps calling BLAS, and the new APIs are available when you want them.

Building BLIS from source and calling it through the BLAS layer

BLIS is distributed as source, and the README's Getting Started section is where the project directs you. The repository root contains a configure script and a top-level Makefile, which is the standard path for a C99 project of this kind. The README lists the build steps as follows:

./configure auto
make

The auto argument lets the configure script pick a configuration for the machine you are on. If you are cross-compiling or targeting a specific chip, the configurations live under config/ and are listed in the config_registry file at the repository root; pass the name you want instead of auto. The build produces the library and a pkg-config file, blis.pc.in, which is the template for blis.pc.

Once the library is built, the quickest way to see it work is through the BLAS compatibility layer, so existing BLAS code needs no changes beyond linking. The repository ships example code in examples/tapi/ for the typed API and examples/oapi/ for the object API; those directories are the place to look for a working call sequence rather than guessing at argument order.

For an installed BLIS, the newer plugin mechanism is worth knowing about. According to the README, plugins let external code extend operation support or define new BLIS APIs using only an installed BLIS package, with no source required, and they can supply their own kernels and blocksizes. The same mechanism exposes an API for modifying the control tree, which is what defines the mathematical operation being computed along with packing and partitioning decisions. The README names SYRKD as the worked example, and docs/PluginHowTo.md is the step-by-step guide.

Where BLIS is the wrong tool

The framework assumption cuts both ways. If you want a library that is already tuned for your exact processor by the people who designed it, a vendor BLAS is the better answer, and no amount of framework flexibility changes that. BLIS gives you the machinery to reach that performance; it does not hand you the result.

Building from source is a real cost in deployment. There is no indication in the README of a supported binary distribution path, so a team that cannot compile C in its build pipeline, or that needs to ship a single artifact across many heterogeneous machines, will feel that. The configure step also means the artifact is tied to the target it was configured for, which complicates container images and CI matrices.

The scope is dense linear algebra. The description and README describe a BLAS-like dense library; sparse formats, iterative solvers and distributed-memory decomposition are not what this is. If your problem is a sparse system, the framework's loop-level tuning is beside the point.

Finally, the three-API structure is a genuine surface. The typed API, the object API and the BLAS compatibility layer are distinct interfaces with distinct documentation files, and the object API in particular has no equivalent in the BLAS world, so code written against it is not portable to another BLAS library. Choosing it is a commitment.

BLIS vs OpenBLAS and BLIS vs plain BLAS

The comparison people actually search for is BLIS against OpenBLAS, and the difference is structural rather than a matter of which is faster. OpenBLAS is a BLAS library: you get a set of routines, tuned per target, and the tuning lives inside the project. BLIS is a framework for producing such a library, with the kernels and blocksizes factored out into configurations and the loop structure kept in the framework. If you want to change how the loops are blocked for a new core, BLIS is designed for you to do that; with a conventional BLAS library you are generally waiting for someone else to do it.

Against plain BLAS, the distinction is about the interface rather than the implementation. The reference BLAS defines the routine signatures and nothing more. BLIS implements those signatures through its compatibility layer, but also exports the typed API and the object-based API, which the README calls unique to BLIS. The object API is the part with no counterpart elsewhere, and correspondingly the part that ties you to this project.

The project also has an addon mechanism, visible as the addon/ directory at the repository root, which the README describes as the earlier way to extend operation support or define custom BLIS APIs. Plugins are the newer route and the one the README recommends for external code, since they need only an installed package. If you are reading older material that talks about addons, that is the mechanism it means.

Maintenance, licensing and what upgrades cost

The last push to master was on 2026-08-29, and the release history shows a slow cadence: 0.9.0 in April 2022, 1.3 in May 2024, 2.1 in January 2025. That is a stable project rather than a fast-moving one, which is appropriate for numerical infrastructure and also means fixes arrive on a relaxed schedule. If you depend on a specific behaviour, plan to track the CHANGELOG and RELEASING.md files at the repository root rather than expecting frequent point releases.

Upgrade cost is dominated by the build, not by API churn, because the compatibility layer keeps BLAS callers insulated. The thing to watch is a configuration you have customized: a new release may change blocksizes or kernel expectations, and your local config/ entry is the part that has to be reconciled. Code written against the object API is the other place where a version bump can require attention, since that interface is BLIS-specific.

The licence field on the repository is NOASSERTION, which means no single licence was detected for the repository as a whole. The README states that BLIS is available under a new, modified, 3-clause BSD license, and the Makefile carries a three-clause BSD notice naming the University of Texas at Austin and Advanced Micro Devices. Those two facts do not contradict each other, but they do mean the repository is not uniform: individual files and directories can carry their own notices. Read LICENSE and the header of any file you redistribute. This is a description of what the repository says, not legal advice.

Editorial conclusion

Adopt BLIS if you are porting dense linear algebra to a new microarchitecture, need a BLAS-compatible library you can retune without forking the whole stack, or want to define a new operation through the object API or a plugin. Do not adopt it if you expect a binary drop-in with no build step, if you need sparse or distributed solvers, or if you want vendor-tuned numbers on a specific chip with no effort; that is what the vendor library is for. Before committing, check the config/ directory for a configuration matching your target, confirm whether the BLAS compatibility layer covers every routine your code calls, and read LICENSE and the headers of individual files rather than assuming one uniform licence.

Frequently asked questions

Official sources

1. flame/blis on GitHub
2. Issues
3. README
4. Releases