[SYCL] Update sycl_ext_intel_device_info with querying the device IP version

[dm-vodopyanov]

No description provided.

[gmlueck]

I think we should document what this number means for Intel GPUs. In the mid-to-long term, I want to create a public document with this information. For now, I think we can point to this public header:

https://github.com/intel/compute-runtime/blob/master/third_party/aot_config_headers/platforms.h

And say something like:

Returns: The IP version of the device. For a GPU device, refer to the PRODUCT_CONFIG enumeration in this header for a mapping between IP versions and device names.

I also think we should provide some way to decompose the uint32_t into the "major", "minor", and "patch" components. I can think of two ways to do this:

1. Change the return_type into a union like:

   union {
      std::uint32_t raw;
      struct {
        std::uint32_t patch:14;
        std::uint32_t minor:8;
        std::uint32_t major:10;
      };
   };
   

2. Provide three inline function that each take a uint32_t and return one of the components.

I think (1) is not guaranteed to work if we care about portability between little-endian and big-endian host systems. However, Intel devices are all little-endian, so maybe this doesn't matter. Option (2) is guaranteed to be portable, but is a bit more verbose. Option (2) seems safer to me, but I'm open.

CC: @bashbaug also to verify that "major", "minor", "patch" are the right names for these three components. I'm also not certain of the bit widths of these three components, so maybe Ben can verify this too.

[KornevNikita]

I make no claim to the absolute truth, but I use architecture, release and revision (would be nice to align):

// A GPU IP version packs four fields, from the most significant bit down:
//
//    31           22 21      14 13       6 5        0
//   +---------------+----------+----------+----------+
//   |  architecture |  release | reserved | revision |
//   +---------------+----------+----------+----------+
//        10 bits      8 bits     8 bits     6 bits
//
// The reserved bits carry no information.

FYI - so called revision actually uses 6 bits, the rest of 8 bits is unused.

UPD.

Provide three inline function that each take a uint32_t and return one of the components.

IMO this sounds better.

[gmlueck]

@bashbaug do you know the official names for the three components of the GMDID?

[KornevNikita]

Updated the spec and added 3 new free functions - e2da3f8. Kept major/minor/patch names untill Ben's clarification.

[bashbaug]

I don't think there is any official terminology, and I've seen different names even internally.

Good candidates IMO are:

• family / release / revision
• architecture / release / revision
• major / minor / revision
• major / minor / patch (note: aligns with SemVer, but may imply compatibility when it doesn't exist)

As long as we get the number of bits right and pick something sensible we should be fine. If I had to choose though, I'd go with architecture / release / revision.

[KornevNikita]

@gmlueck do you have any preferences/objections against architecture / release / revision?

[gmlueck]

I think we want to protect these calls to the free functions with if (dev.is_gpu()).

Aside from that, the spec looks good! I'll wait to hear from @bashbaug, though, about the official names.