Re: x86 CPU features detection for applications (and AMX)

Thiago Macieira
2021-06-25T23:31:17Z

On 23 Jun 2021 17:04:27 +0200, Florian Weimer wrote:
> We have an interface in glibc to query CPU features:
> X86-specific Facilities
> <https://www.gnu.org/software/libc/manual/html_node/X86.html>
>
> CPU_FEATURE_USABLE all preconditions for a feature are met,
> HAS_CPU_FEATURE means it's in silicon but possibly dormant.
> CPU_FEATURE_USABLE is supposed to look at XCR0, AT_HWCAP2 etc. before
> enabling the relevant bit (so it cannot pass through any unknown bits).

It's a nice initiative, but it doesn't help library and applications that need
to be either cross-platform or backwards compatible.

The first problem is the cross-platformness need. Because we library and
application developers need to support other OSes, we'll need to deploy our
own CPUID-based detection. It's far better to use common code everywhere,
where one developer working on Linux can fix bugs in FreeBSD, macOS or Windows
or any of the permutations. Every platform-specific deviation adds to
maintenance requirements and is a source of potential latent bugs, now or in
the future due to refactoring. That is why doing everything in the form of
instructions would be far better and easier, rather than system calls.

[Unless said system calls were standardised and actually deployed. Making this
a cross-platform library that is not part of libc would be a major step in
that direction]

The second problem is going to be backwards compatibility. Applications and
libraries may want to ship precompiled binaries that make use of the new CPU
features, whether they are open source or not. It comes as no surprise to
anyone that we CPU makers will have made software that use those features and
want to have it ready on Day 1 of the HW being available for the market (if
we're doing our jobs right). That often involves precompiling because everyone
who installed their compilers more than one year ago will not have the
necessary tools to build. That runs counter to the need to use a libc
interface that didn't exist until recently.

And by "recently", I mean "anything since the glibc that came with Red Hat
Enterprise Linux 7" (2.17).

So no, application and library developers will not use libc functions they
don't need to, especially if it adds to their problems, unless there's no way
around it.

> Previously kernel developers have expressed dismay that we didn't
> coordinate the interface with them. This is why I want raise this now.

You also need to coordinate with your users.

A platform-specific API to solve a problem that is already solved is "knock
yourself out, we're not going to use this." So my first suggestion is to
remove the "platform-specific" part and make this a cross-platform solution.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering