[DOC] Add SYCL_INTEL_bf16_conversion to sycl/doc/extensions/README.md #4428
Conversation
AlexeySotkin
changed the title
|
@romanovvlad could you please take a look? |
sycl/doc/extensions/README.md
Outdated
| @@ -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 | | |||
There was a problem hiding this comment.
Should we mention that the aspect for this is not implemented yet?
There was a problem hiding this comment.
What prevents us from implementing the aspect?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Just for reference: #4266 - this PR was adding the appropriate aspect, but it was dismissed and closed for the reasons I described above.
There was a problem hiding this comment.
Do we have an open bug report to track this?
Internally - yes.
Co-authored-by: Romanov Vlad <[email protected]>
bader
added
the
Documentation
No description provided.