Update GPU related dependencies #145
Open
Conversation
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
GPUArrays.jl now uses KernelAbstractions.jl as its generic kernel API. This does not directly impact NFFT.jl (yet), however it means that we need to update our dependencies, s.t. our extension is still loaded/compatible if a user loads a recent version of GPUArrays.
Otherwise upstream packages run into a stackoverflow issue during plan_creation as could be observed in LinearOperatorCollection.jl.
If we ever want to implement generic GPU kernels we now should use KernelAbstractions.jl to implement them. An example would be custom kernels for preprocessing for our GPU plans, so I opted to set the weak dependency as a new lower bound. I hope I find time this year to tackle this these kernels as well as the plan inference based on input type