Tvm: [TESTS] Runtime cpu feature detection util

[tqchen]

Right now we want to optionally disable tests based on the availability of the features, we do that for gpu runtimes, cuda/amdgpu, but not cpu features, this is an issue to track that.

Ideally, we should put that into tvm.testing.cpu_features.py

[tqchen]

cc @llyfacebook @u99127 @ajtulloch please share some of your insights? I think we could get quite far with cpuinfo?

[u99127]

@tqchen

The approach I've taken / seen taken is to test whether the hardware supports the "feature" or not with a run time test. That could well be an introspection route like probing some environment variables if clinfo or cuda provides that information or on cpu architectures this is the route that I've preferred.

/proc/cpuinfo is available only on linux, doesn't easily translate to other OS's and then there might be other local variations in terms of the string formats that the output produced looks like on different OS's and different versions of the OS's and different architecture platforms. For instance the output of /proc/cpuinfo on arm and x86_64 could be different. I don't know the route to getting such system information on other platforms like Windows or MacOS.

if (target_cpu_arch == aarch64))
{
// check if low level dependency -> for eg. llvm supports this feature.
// If no skip the test ; return;
// generate_simple_program equivalent to ("int main (void) { __asm__ volatile (" instruction/ feature to be tested"); return 0; } ;
// retval = compile_and_execute () ;
// if (retval == 0)
// can run the test
// else
// skip the test ; // Expect a SIGILL
}

Advantages :

• Keeps this localized to specific architecture and the instruction feature being tested.
• /proc/cpuinfo might have funny strings. Figuring out the mapping of the right mnemonic to the right string on a per architecture basis is quite hard and requires specific knowledge.
• In terms of code generated for that feature, we know what instructions we are targeting. Getting the output is easy .

Disadvantage

• Getting the framework "working" can take some more time especially if one wants to do remote testing / remote compilation.
• Parsing /proc/cpuinfo is quick and dirty on GNU/Linux systems.

Hope this helps.

regards
Ramana

[lly-zero-one]

Can we just annotate the test with @unittest.skipIf decorator? The condition can be generated from cuda availability or cpuinfo.

[ajtulloch]

https://github.com/pytorch/cpuinfo is a good, minimal, cross-platform (Linux/Android/OS X/Windows/iOS) library that might be useful for this purpose.

[tqchen]

@ajtulloch It seems to be a great util that we could add as 3rdparty dependency and expose some of the detection features to python tvm.testing.cpuinfo

[u99127]

@ajtulloch and @tqchen That certainly looks interesting as a project to poke into and looks like it is quite cross platform.

I will need to peek more into the guts of the implementation especially around architectural features on Arm and AArch64 as I note that cpuid based feature detection is still a todo and that for me is the better way of detecting that on those platforms compared to parsing /proc/cpuinfo.

@tqchen - any thoughts on how we would pin versions here for the dependency with CI since there's no binary packaging with this ?

Ramana

[tqchen]

If we put it as a submodule, the version should be pinned by the hashtag of the submodule. We just need to make sure to have an optional flag that build around it.

[u99127]

Since we use this as part of testsuite cpu feature probing mechanism, I think the version needs pinning for the following reason.

Developer runs the test on day X for a given SHA in tvm repository - it passes
Developer runs the test on day Y for the same SHA as on day X in tvm repository - it runs the test but with different test infrastructure ?

regards
Ramana

[tqchen]

To be clear, hashtags of submodules are pinned, so that is what you asked for @u99127