-
Notifications
You must be signed in to change notification settings - Fork 738
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
Conversation
There was a problem hiding this 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
Driver changes look fine - seeing the number of header inclusion changes we have had to make internally - how do we minimize impact on users? |
Thanks for fixing this long-standing issue!
The spec says that
It doesn't require implementation to put it into
What is your concern about the |
Yeah, I wasn't precise in what I said. What I meant is that |
It feels awkward to me that our implementation detail is located in OpenCL-specific folder. It might better be suited for |
My personal opinion: we don't - it was a bug and now it's fixed. |
Agree. SYCL-1.2.1 implementation put all headers into |
Good! I'll address it separately after this PR is merged in. |
There was a problem hiding this 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
sycl/include/sycl/accessor.hpp
Outdated
@@ -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... |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SYCLcompat changes LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UR LGTM
Ping @intel/bindless-images-reviewers . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bindless LGTM
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 intoinclude/CL/sycl.hpp
per the specification.