Skip to content
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

[SYCL][DOC] Add table with DPC++ extensions status #1619

Merged
merged 6 commits into from
May 26, 2020

Conversation

romanovvlad
Copy link
Contributor

Signed-off-by: Vlad Romanov vlad.romanov@intel.com

Signed-off-by: Vlad Romanov <vlad.romanov@intel.com>
@romanovvlad
Copy link
Contributor Author

It would be nice if you review the status of the extensions in this table and suggest a comment about what specifically is already supported for the "partially supported" extensions.

| [SYCL_INTEL_device_specific_kernel_queries](DeviceSpecificKernelQueries/SYCL_INTEL_device_specific_kernel_queries.asciidoc) | Proposal | |
| [SYCL_INTEL_enqueue_barrier](EnqueueBarrier/enqueue_barrier.asciidoc) | Proposal | |
| [SYCL_INTEL_extended_atomics](ExtendedAtomics/SYCL_INTEL_extended_atomics.asciidoc) | Proposal | |
| [SYCL_INTEL_group_algorithms](GroupAlgorithms/SYCL_INTEL_group_algorithms.asciidoc) | Proposal | |
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
| [SYCL_INTEL_group_algorithms](GroupAlgorithms/SYCL_INTEL_group_algorithms.asciidoc) | Proposal | |
| [SYCL_INTEL_group_algorithms](GroupAlgorithms/SYCL_INTEL_group_algorithms.asciidoc) | Partially supported | Does not support host device |

Copy link
Contributor Author

@romanovvlad romanovvlad May 19, 2020

Choose a reason for hiding this comment

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

Applied.

| [SPV_INTEL_function_pointers](SPIRV/SPV_INTEL_function_pointers.asciidoc) | Supported | |
| [SPV_INTEL_inline_assembly](SPIRV/SPV_INTEL_inline_assembly.asciidoc) | Supported | |
| [SYCL_INTEL_static_local_memory_query](StaticLocalMemoryQuery/SYCL_INTEL_static_local_memory_query.asciidoc) | Proposal | |
| [SYCL_INTEL_sub_group_algorithms](SubGroupAlgorithms/SYCL_INTEL_sub_group_algorithms.asciidoc) | Proposal | |
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
| [SYCL_INTEL_sub_group_algorithms](SubGroupAlgorithms/SYCL_INTEL_sub_group_algorithms.asciidoc) | Proposal | |
| [SYCL_INTEL_sub_group_algorithms](SubGroupAlgorithms/SYCL_INTEL_sub_group_algorithms.asciidoc) | Partially supported | Features from SYCL_INTEL_group_algorithms extended to sub-groups. Does not support host device. |

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Applied.

| [SPV_INTEL_inline_assembly](SPIRV/SPV_INTEL_inline_assembly.asciidoc) | Supported | |
| [SYCL_INTEL_static_local_memory_query](StaticLocalMemoryQuery/SYCL_INTEL_static_local_memory_query.asciidoc) | Proposal | |
| [SYCL_INTEL_sub_group_algorithms](SubGroupAlgorithms/SYCL_INTEL_sub_group_algorithms.asciidoc) | Proposal | |
| [Sub-groups for NDRange Parallelism](SubGroupNDRange/SubGroupNDRange.md) | Proposal | |
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
| [Sub-groups for NDRange Parallelism](SubGroupNDRange/SubGroupNDRange.md) | Proposal | |
| [Sub-groups for NDRange Parallelism](SubGroupNDRange/SubGroupNDRange.md) | Deprecated | Does not support host device. |

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's already mentioned, see line 31

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it's not. There are 3 extensions in the directory: Subgroup, SubGroupNDRange and SubgroupAlgorithms and I think we want status per each.

Copy link
Contributor

Choose a reason for hiding this comment

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

@pvchupin is right. I suggested what the Subgroup extension line could look like here: #1619 (comment)

SubGroupNDRange includes some queries and functions that were deprecated when equivalent functionality was introduced in GroupAlgorithms and SubgroupAlgorithms. We'll eventually drop support for it entirely (and when that happens we can probably remove its row from this table).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Applied original comment and added the line John suggested.

@Pennycook
Copy link
Contributor

We should add a line:

| [Sub-groups](SubGroup/SYCL_INTEL_sub_group.asciidoc) | Partially supported | Does not support host device. |

The directory contains documents that describe DPC++ extensions to SYCL
specification.

DPC++ extensions status:
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we add a legend with possible "Status" values?

Copy link
Contributor

Choose a reason for hiding this comment

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

I have a selfish interest to capture information about the compiler options to turn on/off these extensions.
Do you think we can add another column?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

A column with compiler options which turn on/off specific extensions?
What do you think about having them in https://github.com/intel/llvm/blob/sycl/sycl/doc/UsersManual.md
and add a link from this doc to the user manual?

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds good to me.

AFAIK, some extensions are "library-only" and there is no dedicated clang driver option to manage library extensions - they are managed through macro definitions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

they are managed through macro definitions.

Can we have such macro documented in the user manual as well?

Copy link
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 them and align extensions API with this proposal: https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/ExtensionMechanism/SYCL_INTEL_extension_api.asciidoc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a link to user manual, please, let me know if something else should be done in scope of this comment.

@bader bader added the spec extension All issues/PRs related to extensions specifications label May 1, 2020
specification.

DPC++ extensions status:

Copy link
Contributor

Choose a reason for hiding this comment

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

printf extension seems to be missing.

Copy link
Contributor

Choose a reason for hiding this comment

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

These others seem to be missing too:

  1. Specialization constants
  2. Generic interoperability between DPC++ and native RT (https://github.com/KhronosGroup/SYCL-Shared/blob/master/proposals/sycl_generalization.md)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bader , do we have an extension doc for the printf extension?
@smaslov-intel I haven't added non-Intel extensions intentionally.
@pvchupin Should we track non-Intel extensions here? What if they are not implemented so far?

Copy link
Contributor

Choose a reason for hiding this comment

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

@bader , do we have an extension doc for the printf extension?

I've requested it here, but there were updates yet. @AlexeySachkov any updates?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@pvchupin Should we track non-Intel extensions here? What if they are not implemented so far?

Copy link
Contributor

@pvchupin pvchupin May 21, 2020

Choose a reason for hiding this comment

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

I think this table purpose is to clarify what we support or planning to prototype in the nearest future (Intel or non-Intel doesn't matter).
In particular we have specialization constants implementation, so we should add it. We should probably add generalization too. I don't think we should extend this list to all existing drafts, only to those we are considering or prototyped already.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, are you OK if these extensions are added to the table in a separate PR(preferably by the authors)?

@Ruyk
Copy link
Contributor

Ruyk commented May 4, 2020

I think when mentioned "Supported" , it should be listed which backend supports the extension. The CUDA backend doesn't support many of them.

@pvchupin
Copy link
Contributor

pvchupin commented May 4, 2020

I think when mentioned "Supported" , it should be listed which backend supports the extension. The CUDA backend doesn't support many of them.

Good point. @romanovvlad we may need another column.

specification.

DPC++ extensions status:

Copy link
Contributor

Choose a reason for hiding this comment

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

These others seem to be missing too:

  1. Specialization constants
  2. Generic interoperability between DPC++ and native RT (https://github.com/KhronosGroup/SYCL-Shared/blob/master/proposals/sycl_generalization.md)

The directory contains documents that describe DPC++ extensions to SYCL
specification.

DPC++ extensions status:
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we please maintain more info about the extensions and capture this:

  • where it is targeted, i.e. which devices/backends are going to support it
  • current availability through various targeted backends
  • what SW components are known to be involved in the implementation (e.g. SYCL headers, SPIR-V, SYCL RT, PI,...)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think that if we add all this information the table will be too complex, but I can add a couple of columns that can be filled in future.

@smaslov-intel
Copy link
Contributor

I think when mentioned "Supported" , it should be listed which backend supports the extension. The CUDA backend doesn't support many of them.

Good point. @romanovvlad we may need another column.

@smaslov-intel
Copy link
Contributor

I think when mentioned "Supported" , it should be listed which backend supports the extension. The CUDA backend doesn't support many of them.

Good point. @romanovvlad we may need another column.

Please consider documenting even more:

  • where it is targeted, i.e. which devices/backends are going to support it
  • current availability through various targeted backends
  • what SW components are known to be involved in the implementation (e.g. SYCL headers, SPIR-V, SYCL RT, PI,...)

jbrodman
jbrodman previously approved these changes May 7, 2020
@romanovvlad
Copy link
Contributor Author

I think when mentioned "Supported" , it should be listed which backend supports the extension. The CUDA backend doesn't support many of them.

Good point. @romanovvlad we may need another column.

What is a separate column for?
I suggest change the format of the Status column to something like this:
Supported(OpenCL), Partially supported(CUDA)

sycl/doc/extensions/README.md Outdated Show resolved Hide resolved
sycl/doc/extensions/README.md Outdated Show resolved Hide resolved
sycl/doc/extensions/README.md Outdated Show resolved Hide resolved
@romanovvlad romanovvlad marked this pull request as draft May 12, 2020 17:16
@pvchupin
Copy link
Contributor

What is a separate column for?
I suggest change the format of the Status column to something like this:
Supported(OpenCL), Partially supported(CUDA)

That's fine to me.

@bader
Copy link
Contributor

bader commented May 17, 2020

@romanovvlad, is it still a draft PR or ready for review?

@romanovvlad romanovvlad force-pushed the private/vromanov/ExtensionsStatus branch from 2659355 to 77e41b9 Compare May 18, 2020 17:58
@romanovvlad romanovvlad marked this pull request as ready for review May 18, 2020 17:58
@romanovvlad
Copy link
Contributor Author

@romanovvlad, is it still a draft PR or ready for review?

Yes, I believe I resolved all the comments I could.

@romanovvlad
Copy link
Contributor Author

@smaslov-intel ping

@bader
Copy link
Contributor

bader commented May 26, 2020

@romanovvlad, please, resolve conflicts.

@romanovvlad
Copy link
Contributor Author

@romanovvlad, please, resolve conflicts.

Done.

@bader bader merged commit dbbc474 into intel:sycl May 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec extension All issues/PRs related to extensions specifications
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants