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] Don't add include/sycl/ to the system includes path #15437

Merged
merged 8 commits into from
Sep 25, 2024

Conversation

aelovikov-intel
Copy link
Contributor

@aelovikov-intel aelovikov-intel commented Sep 18, 2024

Fixes #6770

Open question: I'm not sure if https://github.com/intel/llvm/tree/sycl/sycl/include/CL/__spirv should go into include/CL/__spirv or somewhere else. On the other hand, https://github.com/intel/llvm/blob/sycl/sycl/include/CL/sycl.hpp has to be installed into include/CL/sycl.hpp per the specification.

Copy link
Contributor

@sarnex sarnex left a comment

Choose a reason for hiding this comment

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

esimd changes lgtm, will let others review the overall change

@mdtoguchi
Copy link
Contributor

Driver changes look fine - seeing the number of header inclusion changes we have had to make internally - how do we minimize impact on users?

@bader
Copy link
Contributor

bader commented Sep 19, 2024

Fixes #6770

Thanks for fixing this long-standing issue!

On the other hand, https://github.com/intel/llvm/blob/sycl/sycl/include/CL/sycl.hpp has to be installed into include/CL/sycl.hpp per the specification.

The spec says that

For compatibility with SYCL 1.2.1, SYCL provides another standard header file: <CL/sycl.hpp>, which can be included in place of <sycl/sycl.hpp>. In that case, all SYCL classes, constants, types and functions defined by this specification should exist within the ::cl::sycl C++ namespace.

It doesn't require implementation to put it into include directory. Moreover, it doesn't mandate the driver to add additional search paths for SYCL headers. It's DPC++ implementation choice.

I'm not sure if https://github.com/intel/llvm/tree/sycl/sycl/include/CL/__spirv should go into include/CL/__spirv or somewhere else.

What is your concern about the __spirv directory location?

@aelovikov-intel
Copy link
Contributor Author

It doesn't require implementation to put it into include directory. Moreover, it doesn't mandate the driver to add additional search paths for SYCL headers. It's DPC++ implementation choice.

Yeah, I wasn't precise in what I said. What I meant is that #include <CL/sycl.hpp> must work and now that we don't put include/sycl in search path we have to move that header.

@aelovikov-intel
Copy link
Contributor Author

What is your concern about the __spirv directory location?

It feels awkward to me that our implementation detail is located in OpenCL-specific folder. It might better be suited for sycl/__spirv.

@aelovikov-intel
Copy link
Contributor Author

Driver changes look fine - seeing the number of header inclusion changes we have had to make internally - how do we minimize impact on users?

My personal opinion: we don't - it was a bug and now it's fixed.

@bader
Copy link
Contributor

bader commented Sep 19, 2024

What is your concern about the __spirv directory location?

It feels awkward to me that our implementation detail is located in OpenCL-specific folder. It might better be suited for sycl/__spirv.

Agree. SYCL-1.2.1 implementation put all headers into CL directory. When we added support for SYCL-2020, we moved all headers from CL to sycl directory. It sounds like it's a leftover of this work. I expect CL to have only one file - sycl.hpp, which includes sycl/sycl.hpp and imports all SYCL declarations to cl namespace.

@aelovikov-intel
Copy link
Contributor Author

What is your concern about the __spirv directory location?

It feels awkward to me that our implementation detail is located in OpenCL-specific folder. It might better be suited for sycl/__spirv.

Agree. SYCL-1.2.1 implementation put all headers into CL directory. When we added support for SYCL-2020, we moved all headers from CL to sycl directory. It sounds like it's a leftover of this work. I expect CL to have only one file - sycl.hpp, which includes sycl/sycl.hpp and imports all SYCL declarations to cl namespace.

Good! I'll address it separately after this PR is merged in.

Copy link
Contributor

@uditagarwal97 uditagarwal97 left a comment

Choose a reason for hiding this comment

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

SYCL RT changes LGTM

@@ -37,7 +37,7 @@
#include <sycl/property_list.hpp> // for property_list
#include <sycl/range.hpp> // for range
#include <sycl/sampler.hpp> // for addressing_mode
#include <ur_api.h> // for UR_RESULT_ERRO...
#include <sycl/ur_api.h> // for UR_RESULT_ERRO...
Copy link
Contributor

Choose a reason for hiding this comment

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

This change makes me think that ur_api.h is our own header, but that's not true. I wonder if we need to put it into some _deps subfolder for clarity.

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've been thinking about this too. I think even sycl/_deps/ur_api.h might be questionable, because one might want to use both UR and SYCL on the application side and I'd expect user's UR must somehow match the one libsycl.so was built with. Maybe I should be deploying these ur_*.h/.hpp at root include/ directory instead.

Does anybody have any ideas here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Implemented the move in the latest revision.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Or should it be ur/ur_*.h ? @intel/unified-runtime-reviewers

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ping @intel/unified-runtime-reviewers to answer the question above. @AlexeySachkov just in case 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 don't think we ever intend for UR to be used directly by an application so we can eliminate that as a concern. In the UR repo the API header just lives in the root include so ur/ur_api.h would look a little weird from that perspective

Copy link
Contributor

Choose a reason for hiding this comment

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

If UR is not intended to be used by end users, then I think some generic _deps is good enough and it will be less confusing than ur/ for those who work with it.

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'm not sure if I prefer _deps/ur_api.h vs just ur_api.h, especially since the latter is the prior spelling of the includes. As such, _deps/* move should be in another PR, if at all.

Copy link
Contributor

@joeatodd joeatodd left a comment

Choose a reason for hiding this comment

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

SYCLcompat changes LGTM

Copy link
Contributor

@kbenzie kbenzie left a comment

Choose a reason for hiding this comment

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

UR LGTM

@aelovikov-intel
Copy link
Contributor Author

Ping @intel/bindless-images-reviewers .

Copy link
Contributor

@Seanst98 Seanst98 left a comment

Choose a reason for hiding this comment

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

Bindless LGTM

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.

[SYCL] Bug in SYCL header path