We run into the issue of a standardization process for hardware topologies and I think HSA can help us with names and layers.

What is the current state of compass. The current compass usage usually looks like this:

auto vendor = compass::runtime::vendor();
auto device_name = compass::runtime::device_name();
auto value = compass::runtime::has(compass::feature::sse());
...

The instantiation of the corresponding wrappers happens at compile-time through the detection of

• OS (linux, mac, windows)
• platform (x86, x86_64, power)
• compiler architecture (clang, intel, gcc, msvc),

mostly retrieved by macros coming from header includes and compilers.

So, the code above always refer to CPU device (keep in mind, nvcc does not compile host code). So first thing coming up here is:

How to name device layer?

There is a need for a layer for the devices within a node. C++AMP just calls them accelerator, which does not seem sufficient for our library. What about HSA, what's their convention:

HSA nomenclature

• HSA 1.1 specification:
  • system and agent information
  • device types: HSA defines CPU, GPU and DSP

1x compass instance only sees 1x node, but n devices (HSA refers to as agents).

// possible compass API
auto node = compass::node();
auto node_compiletime = compass::compiletime::node(); // for compile-time structure
auto vendor = compass::vendor(node);

• So, how about using compass::node and compass::devices to get [compile-time] properties encapsulated in structures?

How to select or iterate through devices?

// possible compass API
...
auto devices = compass::devices();
auto value_node = compass::has(node, compass::feature::sse());
auto value_dev  = compass::has(devices[0], compass::feature::sse());
auto devices_gpu = compass::devices(compass::device_type::gpu);
...

• maybe the runtime namespace can be neglected. A user should not start guessing "is this in runtime or in compiletime". However, compiletime could be a reasonable namespace to ensure compile-time features
• does compile-time feature still work when using cross-compiler?
• accessing device- or node-specific properties can be done via structures/methods, see issue Encapsulation of properties? #4