Skip to content

[SYCL] Update sycl_ext_intel_device_info with querying the device IP version - #23185

Open
dm-vodopyanov wants to merge 1 commit into
intel:syclfrom
dm-vodopyanov:add_query_device_ip_version
Open

dm-vodopyanov wants to merge 1 commit into
intel:syclfrom
dm-vodopyanov:add_query_device_ip_version

Conversation

@dm-vodopyanov

Copy link
Copy Markdown
Contributor

No description provided.

@dm-vodopyanov
dm-vodopyanov requested review from a team as code owners September 15, 2026 18:21
@dm-vodopyanov dm-vodopyanov changed the title [SYCL] Update sycl_ext_intel_device_info with quering the device IP version [SYCL] Update sycl_ext_intel_device_info with querying the device IP version Sep 15, 2026

_Returns:_ The IP version of the device. The meaning of the device IP version
is implementation-defined, but newer devices should have a higher version than
older devices.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 to 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants