[SYCL][L0] Proposal for new device descriptors for Intel GPU devices

[glyons-intel]

This proposal details what is required to expose some low-level details of hardware devices as a SYCL extension.

Signed-off-by: Gail Lyons gail.lyons@intel.com

[smaslov-intel]

Does it need to be so much specific to "Intel GPU"?
Is there a process defined that can be used to make it more generic later, if other backends/devices decide to support this?

[jbrodman]

Does it need to be so much specific to "Intel GPU"?
Is there a process defined that can be used to make it more generic later, if other backends/devices decide to support this?

We can always rev the specification in the future, but atm only Intel GPUs define "EU"s.

[smaslov-intel]

Does it need to be so much specific to "Intel GPU"?
Is there a process defined that can be used to make it more generic later, if other backends/devices decide to support this?

We can always rev the specification in the future, but atm only Intel GPUs define "EU"s.

How about PCI address? Doesn't it apply to all PCI devices?

Unfortunately, only the Level Zero backend provides the PCI address today.

[smaslov-intel]

Unfortunately, only the Level Zero backend provides the PCI address today.

That's fine. The feature main remain unsupported by other backends, but I am suggesting that it should not be called "Intel GPU" feature from the beginning.

[gmlueck]

That's fine. The feature main remain unsupported by other backends, but I am suggesting that it should not be called "Intel GPU" feature from the beginning.

Are you just concerned about the title and description of the extension? (E.g. the title is currently "New device descriptors for Intel GPUs".) I presume we could change these in the future if we add support for non-Intel GPUs.

Note that the "intel" in the feature test macro (SYCL_EXT_INTEL_GPU_DEVICE_INFO) and in the aspect names (aspect::ext_intel_gpu_pci_address) indicate that this is an Intel extension, not that it applies only to Intel devices. Even if we supported non-Intel devices in the future, we would still keep "intel" here. We would only remove these "intel" strings if these APIs get added into the core SYCL language or if they are adopted as a Khronos extension (i.e. not an Intel extension).

We might, however, consider dropping the "gpu" from the PCI APIs. For example, aspect::ext_intel_pci_address instead of aspect::ext_intel_gpu_pci_address. This would make sense if we think we might support getting the PCI address of non-GPU accelerators in the future.

[smaslov-intel]

We might, however, consider dropping the "gpu" from the PCI APIs. For example, aspect::ext_intel_pci_address instead of aspect::ext_intel_gpu_pci_address. This would make sense if we think we might support getting the PCI address of non-GPU accelerators in the future.

Yes, that's what I wanted. I think someone mentioned OpenCL support for PCI is coming too, so I assume more than GPU would be covered then already.

[glyons-intel]

We might, however, consider dropping the "gpu" from the PCI APIs. For example, aspect::ext_intel_pci_address instead of aspect::ext_intel_gpu_pci_address. This would make sense if we think we might support getting the PCI address of non-GPU accelerators in the future.

Yes, that's what I wanted. I think someone mentioned OpenCL support for PCI is coming too, so I assume more than GPU would be covered then already.

I can remove the "gpu" from the PCI address device descriptor and aspect.

Should I add a separate Feature Test Macro for the PCI address? Something like SYCL_EXT_INTEL_DEVICE_INFO? SYCL_EXT_INTEL_GPU_DEVICE_INFO still seems appropriate for the EU count and the EU SIMD width.

[smaslov-intel]

Should I add a separate Feature Test Macro for the PCI address? Something like SYCL_EXT_INTEL_DEVICE_INFO?

I'd think so, yes. These are independent features traveling by themselves.

[gmlueck]

Personally, I think we could still call this all one "feature", rather than breaking the PCI address into a separate feature, but I admit this is a matter of taste.

If we do want this to be two features, we should have two documents. So, the only change I suggest is to break the PCI address query out into its own document named something like "IntelDeviceInfo.md".

[smaslov-intel]

Personally, I think we could still call this all one "feature", rather than breaking the PCI address into a separate feature, but I admit this is a matter of taste.

If we do want this to be two features, we should have two documents. So, the only change I suggest is to break the PCI address query out into its own document named something like "IntelDeviceInfo.md".

I'd be OK with single feature for all device info extension.

[gmlueck]

I'd be OK with single feature for all device info extension.

Great! In that case, keep a single document, move the feature test macro back to the top of the document, and name the feature test macro "SYCL_EXT_INTEL_DEVICE_INFO".

[smaslov-intel]

This should not be "Intel GPU" now. Please also review other instances of "Intel GPU" in this document.

[jbrodman]

Just for PCI address? With the exception of maybe "memory bandwidth", the rest are extremely Intel GPU specific.

[glyons-intel]

Done! I made both PCI address and max memory bandwidth more generic.

[smaslov-intel]

can we not call it all "Intel GPU" extensions, but just Intel's extension for device info (which SYCL_EXT_INTEL_DEVICE_INFO feature test macro already says)?

[glyons-intel]

Sure!

[jbrodman]

LGTM!