-
Notifications
You must be signed in to change notification settings - Fork 796
[SYCL][Bindless] Device 'image_mem_handle' to 'image_mem_handle' Sub-Region Copy #15579
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
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
46666c1
[SYCL][Bindless] Device 'image_mem_handle' to 'image_mem_handle' Sub-…
DBDuncan 7700111
Rename 'SrcImageDesc' and 'DestImageDesc' to 'SrcImgDesc' and 'DescIm…
DBDuncan 9befa55
Merge remote-tracking branch 'origin/sycl' into duncan/sub-copy
DBDuncan 0ec04d4
Update windows symbols test
DBDuncan ab38b3d
Fix order of new functions
DBDuncan de540bd
Add missing full stops
DBDuncan 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 hidden or 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 hidden or 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 hidden or 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 hidden or 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 hidden or 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.
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.
are we sure about this name? For something so generic like
ext_oneapi_copyI would expect something that handles any type of memory (not just image data) and maybe across all address spaces (host, device). Much like queue.copy() is now.But, the comments on this routine suggest its capability is much more focused. If so, I think it's name should express that. maybe something like
ext_oneapi_d2d_img_copyorext_d2d_img_copy?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.
We already have a lot of overloads that perform copies. The reason we chose this originally is we just intended to extend the existing copy functionality to support new bindless images. Also, our overloads are not just images to images but also memory to memory copies.
Uh oh!
There was an error while loading. Please reload this page.
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.
There are other new overloads planned to be added. Such as host to host and device usm to device
image_mem_handle.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 have been thinking that perhaps the amount of
ext_oneapi_copyoverloads we have is getting a bit unwieldy. Especially considering a number additional ones need to be added to support more device to device copy variants.I don't think it would be a good idea to start making changes involving other copy functions here. But something to be looked into 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.
sorry for not responding to your comments earlier. If there are other overloads that handle other data types, it wouldn't hurt to mention that in the comment. Even just "this overload of ext_copy is for bindless images".
Uh oh!
There was an error while loading. Please reload this page.
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.
No problem, thanks for the approval! On your suggestion, it would likely be best to apply a comment like you suggest to all the overloads at the same time which is a bit out of scope it feels for this PR. As there are 50~ of them (Have to triple them in queue.hpp...). queue.hpp and handler.hpp need a bit of a refactor which is very tentatively planned early next year. Double checking the order of the functions and their corresponding comments. Comments stating they are overloads for bindless images can be added then.