Skip to content

[SYCL] Rename project to oneAPI DPC++ Compiler #1249

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

Merged
merged 1 commit into from
Mar 10, 2020

Conversation

pvchupin
Copy link
Contributor

@pvchupin pvchupin commented Mar 5, 2020

Rename project and fix docs accordingly to new project name.
Rename some of the documentation files.
Minor docs cleanup.

bader
bader previously approved these changes Mar 5, 2020
Copy link
Contributor

@bader bader left a comment

Choose a reason for hiding this comment

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

Overall looks good, but there are a few cases where changes lead to long lines.

@pvchupin pvchupin force-pushed the update-project-name branch from 674d9d2 to 9ad6019 Compare March 7, 2020 00:53
Copy link
Contributor

@keryell keryell left a comment

Choose a reason for hiding this comment

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

Thanks for the cleaning.
While I understand that the commercial name of your compiler or language is oneAPI DPC++, DPC++ is a relatively small superset of SYCL. Furthermore, the SYCL standard committee is working hard to move SYCL forward with a next version on-coming, including the interesting extensions proposed by the various implementers and users, such as obviously the great DPC++ extensions.
I agree you can add a lot of oneAPI DPC++ in the wording since this is what this project is about! But, at the same time, I would not blurry the message by removing SYCL almost everywhere in the documentation, as it can bring some confusion during the up-streaming process...
Changing the naming of the code and environment variable like you did makes sense to me if we want to have multiple implementations used as the same time, like in AdaptiveCpp/AdaptiveCpp#216
What about using in many places oneAPI SYCL DPC++/SYCL oneAPI DPC++/oneAPI DPC++ SYCL/whatever sounds good in English instead?
I pointed a few places where SYCL can come back but actually there are potentially quite more places.

Full disclosure: I do not work for Intel but for a competitor and I am the Khronos Group SYCL specification editor who recognizes the huge contribution done by this project to the SYCL C++ community to up-stream the SYCL standard for heterogeneous computing into Clang/LLVM.

@pvchupin
Copy link
Contributor Author

Thanks Ronan for detailed review!!!
Like you mentioned the intention of this change is to start calling project what it really is matching naming used currently in many other places (sites, forums, presentations, etc.). There is some confusion around which I hope will be fixed by this PR. Before we finalized DPC++ name we have been calling some implementation specific details inconsistently.
I've tried to be careful doing all replacements in this change and keep SYCL everywhere when referring to SYCL standard and SYCL language concepts. Thank you for suggesting a few corrections which I really like!

I'd like to make a few (I hope obvious) statements:

  • For the foreseeable future SYCL standard will be the core of DPC++.
  • We plan to stay aligned with new SYCL standards development and keep supporting new standard versions as they arrive.
  • We plan to keep experimenting and implementing some innovative ideas using this project as an engineering sandbox, we believe prototyping is essential for success of any language extension we'd like to explore.
  • We will continue to contribute the most successful or promising extensions to the SYCL standard.
  • We will continue to work on compiler upstream to llvm.org, it's a long path to land SYCL core implementation and we started from the SYCL core.

Basically our plans are not changing with this PR.

Rename project and fixing docs accordingly to new project name.

Signed-off-by: Pavel V Chupin <[email protected]>
@pvchupin pvchupin force-pushed the update-project-name branch from 9ad6019 to dc34adf Compare March 10, 2020 05:03
@bader bader merged commit 7a2e75e into intel:sycl Mar 10, 2020
@keryell
Copy link
Contributor

keryell commented Mar 10, 2020

Basically our plans are not changing with this PR.

Thank you for all the clarifications.

alexbatashev pushed a commit to alexbatashev/llvm that referenced this pull request Mar 12, 2020
…e_api_test

* origin/sycl:
  [SYCL][NFC] Fix static code analysis concerns (intel#1283)
  [SYCL] Fix the test/basic_tests/buffer/subbuffer.cpp (intel#1277)
  [SYCL][CUDA] Implement the program kernel names query (intel#1248)
  [SYCL] Honor the LLVM_LIBDIR_SUFFIX variable at installation time (intel#1261)
  [SYCL][UX] Diagnostic for undefined device functions (intel#1026)
  [SYCL] Reverse reqd_work_group_size attribute (intel#1234)
  [SYCL] Rename project to oneAPI DPC++ Compiler (intel#1249)
  [SYCL][XPTI] Instrumentation of SYCL runtime with XPTI (intel#1129)
alexbatashev added a commit to alexbatashev/llvm that referenced this pull request Mar 13, 2020
…st_commit

* otcshare/sycl: (469 commits)
  [SYCL] Implement thread-local storage restriction (intel#1281)
  [Driver][SYCL][FPGA] Adjust the output location for the project report (intel#1278)
  [SYCL][NFC] Fix static code analysis concerns (intel#1283)
  [SYCL] Fix the test/basic_tests/buffer/subbuffer.cpp (intel#1277)
  [SYCL][CUDA] Implement the program kernel names query (intel#1248)
  [SYCL] Honor the LLVM_LIBDIR_SUFFIX variable at installation time (intel#1261)
  [SYCL][UX] Diagnostic for undefined device functions (intel#1026)
  [SYCL] Reverse reqd_work_group_size attribute (intel#1234)
  [SYCL] Rename project to oneAPI DPC++ Compiler (intel#1249)
  [SYCL][XPTI] Instrumentation of SYCL runtime with XPTI (intel#1129)
  [SYCL] Add buffer dimensions restriction (intel#1147)
  [SYCL][NFC] Update copyright header in handler files (intel#1271)
  [SYCL][NFC] Format the code with clang-format
  [SYCL][Test] Fix SYCL library location path for LIT tests (intel#1228)
  [SYCL][NFC] Fix doxygen warnings (intel#1270)
  [SYCL][CUDA] Add the CUDA backend to the deploy-sycl-toolchain target (intel#1268)
  [SYCL][NFC] Fix a misleading comment regarding the SYCL flow (intel#1266)
  Change capability for SpecId decoration
  README.md: Mention retrieving llvm archive signatures
  travis: Restore macOS builds
  ...
alexbatashev pushed a commit to alexbatashev/llvm that referenced this pull request Mar 15, 2020
…_accessor_refactor

* origin/sycl: (454 commits)
  [SYCL][NFC] Fix static code analysis concerns (intel#1283)
  [SYCL] Fix the test/basic_tests/buffer/subbuffer.cpp (intel#1277)
  [SYCL][CUDA] Implement the program kernel names query (intel#1248)
  [SYCL] Honor the LLVM_LIBDIR_SUFFIX variable at installation time (intel#1261)
  [SYCL][UX] Diagnostic for undefined device functions (intel#1026)
  [SYCL] Reverse reqd_work_group_size attribute (intel#1234)
  [SYCL] Rename project to oneAPI DPC++ Compiler (intel#1249)
  [SYCL][XPTI] Instrumentation of SYCL runtime with XPTI (intel#1129)
  [SYCL] Add buffer dimensions restriction (intel#1147)
  [SYCL][NFC] Update copyright header in handler files (intel#1271)
  [SYCL][NFC] Format the code with clang-format
  [SYCL][Test] Fix SYCL library location path for LIT tests (intel#1228)
  [SYCL][NFC] Fix doxygen warnings (intel#1270)
  [SYCL][CUDA] Add the CUDA backend to the deploy-sycl-toolchain target (intel#1268)
  Change capability for SpecId decoration
  README.md: Mention retrieving llvm archive signatures
  travis: Restore macOS builds
  Fix DebugInfo creation after LLVM change 7a42bab
  Add more missing mixes
  Add missing fixes
  ...
@pvchupin pvchupin deleted the update-project-name branch August 24, 2021 22:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants