Unified memory allocations #630
Conversation
|
Your PR no longer requires formatting changes. Thank you for your contribution! |
|
Perhaps we can make this backwards portable and add it to 0.9 first? |
|
Thanks once we have it merged in 0.9, please update this PR so that the implementations match. |
christiangnrd
changed the title
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #630 +/- ##
==========================================
+ Coverage 47.54% 51.24% +3.70%
==========================================
Files 22 21 -1
Lines 1729 1610 -119
==========================================
+ Hits 822 825 +3
+ Misses 907 785 -122 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
ready to merge? |
| Returns whether unified memory arrays are supported by the backend. | ||
| !!! note | ||
| Backend implementations **must** implement this function |
There was a problem hiding this comment.
@vchuravy Yes ready to merge. Only thing I want to make sure you didn't miss is that contrary to the 0.9 PR, this has supports_unified as "must". I you would rather it still say "should" commit the suggestion. Either way merge away!
| Backend implementations **must** implement this function | |
| Backend implementations **should** implement this function |
Close #601
@vchuravy The idea is that you request unified if you want to uallocate some memory with unified memory to speed up operations that necessitate CPU access (like 1d reduce result or the indices container in
findall). Otherwise just use the default storage type. Backends would have to add support for theunifiedkwarg.