-
Notifications
You must be signed in to change notification settings - Fork 766
[SYCL] Add new aspect ext_oneapi_virtual_functions #15577
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
AlexeySachkov
merged 3 commits into
intel:sycl
from
KornevNikita:ext_oneapi_virtual_functions-aspect
Oct 10, 2024
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
3 changes: 0 additions & 3 deletions
3
sycl/test-e2e/VirtualFunctions/2/1/1/more-complex-hierarchy.cpp
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
3 changes: 0 additions & 3 deletions
3
sycl/test-e2e/VirtualFunctions/2/2/single-construct-single-use.cpp
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Is this something we'd want to move to UR eventually?
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.
What is the criteria of moving things to UR?
The only HW which we don't expect to support function pointers is FPGA. For now we also exclude CUDA & HIP, because we haven't tested those configurations. However, I can imagine that 3rd-party backends may not support necessary SPIR-V extensions we use for virtual functions and therefore the ultimate query should be about SPIR-V extension support 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.
My rule of thumb is: If you have to check for the backend, it should have been done in UR. On a more general note though, my concern is another implementation of L0 or OpenCL could come in and it wouldn't support these, then this would be invalid. In a case like that, it would have to be addressed in the UR adapters anyway.
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.
Good point. Even though I consider exclusion of CUDA & HIP backends temporary, I don't know if there are any other queries that should be performed for those backends (like checking CUDA SM version or something).
Do we have some generic API which we can extend (device info, I assume), i.e. what is the path of extending UR to support such query?
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.
It would be a query like for
aspect::ext_oneapi_virtual_mem
a couple of lines above. I don't remember if UR has some tooling to help generate more of these enums. @kbenzie is there?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.
Thanks. Long-term, I think that we should probably move this into UR, but I'm not entirely sure on the name yet. We may add support for generic function pointers later and I believe that aspect for them will be checking for the very same things as we check for virtual functions. Simply because virtual functions are function pointers under the hood.
Therefore, it probably makes sense to have a single generic UR query for both (something like "indirect calls"). However, since we are not yet there with function pointers, I'm hesitant to suggest such generic name just yet.
If there are no objections, I would suggest to have this aspect handled at SYCL level for now and leave a
TODO
comment to move it into UR later.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 would entail adding an entry to the
ur_device_info_t
enum here and runnign thegenerate
target to produce the header and validation layer source changes from that. Then it would be a case of implementing the query in each adapter.👍