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

[Thiago Macieira <thiago.macieira@intel.com>]

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