Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions sycl/doc/extensions/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,6 +44,7 @@ DPC++ extensions status:
| [Assert](Assert/SYCL_ONEAPI_ASSERT.asciidoc) | Proposal | |
| [Matrix](Matrix/dpcpp-joint-matrix.asciidoc) | Partially supported(AMX AOT) | Not supported: dynamic-extent, wg and wi scopes, layouts other than packed|
| [SYCL_INTEL_free_function_queries](FreeFunctionQueries/SYCL_INTEL_free_function_queries.asciidoc) | Supported (experimental) | |
| [SYCL_INTEL_bf16_conversion](Bf16Conversion/SYCL_INTEL_bf16_conversion.asciidoc) | Partially supported (Level Zero: GPU) | Currently available only on Xe HP GPU |
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we mention that the aspect for this is not implemented yet?

Copy link
Contributor

Choose a reason for hiding this comment

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

What prevents us from implementing the aspect?

Copy link
Contributor

Choose a reason for hiding this comment

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

We need a low-level runtime specification to map this aspect on. Also, aspects aren't helping now for device-code features without device_if feature.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, aspects aren't helping now for device-code features without device_if feature

This part isn't true. An application can use logic on the host (device::has(aspect)) to decide which kernel to submit to a device. A typical pattern would be to define two versions of a kernel (e.g. by defining the kernel as a template) and submit one or the other depending on whether the device supports an aspect.

Copy link
Contributor

Choose a reason for hiding this comment

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

This part isn't true. An application can use logic on the host (device::has(aspect)) to decide which kernel to submit to a device

But it doesn't help for a device compiler to decide whether it should compile the kernel. If the device compiler doesn't know the appropriate instruction it will emit an error (best case) or crash (worst case) even if a user put kernel invocation in if (0) { /*...*/ } condition.

Copy link
Contributor

Choose a reason for hiding this comment

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

If the device compiler doesn't know the appropriate instruction it will emit an error (best case) or crash (worst case)

We have a design that will fix this (OptionalDeviceFeatures), and that design requires each optional feature (like this one) to have an aspect.

Copy link
Contributor

Choose a reason for hiding this comment

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

I understand that we may not be able to implement all parts of this API at present. However, the missing aspect support is technically a bug in our implementation now. The extension spec says that it is available, but our implementation doesn't provide it. Do we have an open bug report to track this?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeap, that's why I've said, that aspects aren't helping now and we need device_if feature :)

So, taking in account, that we don't have a low-level runtime spec to map the aspect on (and taking a (almost) random number for now will cause an ABI breakage when we will re-map the aspect on the extension), and since without device_if feature there is no value in the aspect for this feature - it wasn't added.

Copy link
Contributor

Choose a reason for hiding this comment

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

Just for reference: #4266 - this PR was adding the appropriate aspect, but it was dismissed and closed for the reasons I described above.

Copy link
Contributor

Choose a reason for hiding this comment

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

Do we have an open bug report to track this?

Internally - yes.


Legend:

Expand Down