- 
                Notifications
    You must be signed in to change notification settings 
- Fork 79
Unified memory allocations #630
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
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. | 
| Codecov Report❌ 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? | 
Add to docs
Also remove unused file
98ba890    to
    7d5f80c      
    Compare
  
    Co-authored-by: Christian Guinard <[email protected]>
Close #601
@vchuravy The idea is that you request unified if you want to allocate 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.