-
Notifications
You must be signed in to change notification settings - Fork 769
Update SYCL_INTEL_bf16_conversion.asciidoc #5248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Align the document with changes made in intel#4989
sycl/doc/extensions/Bf16Conversion/SYCL_INTEL_bf16_conversion.asciidoc
Outdated
Show resolved
Hide resolved
Am I right in understanding that there is no reason this proposal can't be implemented for other backends (cuda)? Would it be acceptable for us to add NVPTX backend implementations of these spirv functions? For example __spirv_ConvertFToBF16INTEL (perhaps suitably renamed?) would call the cuda builtin that performs the conversion using round to nearest even (as per the proposal). Thanks |
I think I see that the implementations of the spirv functions that are labelled INTEL are hidden. I think I understand that they will remain intel specific: in this case, and assuming that this extension could be generalized, what would be the preferred way of generalizing this extension to support other vendor's backends? A higher level spirv function that would call INTEL labelled spirv/other backend specific spirv depending on the backend compiled for? Thanks |
I made/tested an example draft oneapi namespace extension supporting CUDA here: #5393 |
OK, I've updated the PR to remove from_bits() and raw() and kept the other changes. |
It looks like This PR also needs to be merged with the main branch and updated. The extension spec is now at "sycl/doc/extensions/experimental/sycl_ext_oneapi_bfloat16.asciidoc". |
Moved the required changes to "sycl/doc/extensions/experimental/sycl_ext_oneapi_bfloat16.asciidoc". |
sycl/doc/extensions/experimental/sycl_ext_oneapi_bfloat16.asciidoc
Outdated
Show resolved
Hide resolved
We decided in the PR comments to remove this implicit conversion to `uint16_t`, and it was removed from the table describing the member functions. I think it was just a merge mistake that this conversion was re-added to the synopsis, so remove it.
Closing in favor of #6524 . |
Align the document with changes made in #4989