-
Notifications
You must be signed in to change notification settings - Fork 275
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
Sanity checks for GPU tests, 3rd party framework tensor conversion changes #646
Sanity checks for GPU tests, 3rd party framework tensor conversion changes #646
Conversation
…E_DEVICES=-1`) Add `has_tensorflow_gpu`
…nversions Refactor 3rd party framework GPU tensor detection
I'm not sure I understand this? If we squash this one, can't you rebase the next PR or merge in |
Actually, please ignore that last bit - Looks like I misunderstood how stacked PRs work. The original intention was to work on a PR that was dependent on these changes whilst waiting for it to be merged. I was hoping to stack the 2nd PR on this in such a way that I wouldn't have to do any additional merges (i.e., from So, this PR can be squashed/rebased into |
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.
All of these changes feel pretty reasonable to me!
Maybe the only thing I was wondering about is whether the ops
argument should be keyword-only. Then again I don't think we'll likely be expanding these methods with many more arguments in the future?
From a practical point of view, I'd love it if Daniël could give this a quick review as well. Considering he's out at the moment, we can either just merge this already (it's to develop
anyway) or wait for him to get back - do you have a preference, especially considering the follow-up PR?
Re. Re. merging - I'm fine with leaving this open until Daniël gets a chance to take a look at it. The other PR doesn't include any urgent fixes, and we still need to fix the Buildkite GPU build environment to actually test the changes in CI. So, it can wait. |
Add `Ops` type to `..2xp` functions Defer `cupy` deprecation-related changes to a different PR
|
cupy
deprecation changes, 3rd party framework tensor conversion changes
Merging, since @svlandeg also approved, and this is to |
…anges (explosion#646) * Add sanity checks to handle cases of hidden GPU devices (`CUDA_VISIBLE_DEVICES=-1`) Add `has_tensorflow_gpu` * Allow `...2xp` utility methods to accept a target `Ops` object for conversions Refactor 3rd party framework GPU tensor detection * Handle `cupy.fromDlpack` deprecation for `cupy >= 10.0.0` * Make `ops` arg in `...2xp` functions keyword-only * Short-circuit `..._gpu_array` functions Add `Ops` type to `..2xp` functions Defer `cupy` deprecation-related changes to a different PR * Fix type annotation * Defer sanity check in `_custom_kernels.py` to another PR
…anges (explosion#646) * Add sanity checks to handle cases of hidden GPU devices (`CUDA_VISIBLE_DEVICES=-1`) Add `has_tensorflow_gpu` * Allow `...2xp` utility methods to accept a target `Ops` object for conversions Refactor 3rd party framework GPU tensor detection * Handle `cupy.fromDlpack` deprecation for `cupy >= 10.0.0` * Make `ops` arg in `...2xp` functions keyword-only * Short-circuit `..._gpu_array` functions Add `Ops` type to `..2xp` functions Defer `cupy` deprecation-related changes to a different PR * Fix type annotation * Defer sanity check in `_custom_kernels.py` to another PR
...2xp
utility methods to accept a targetOps
object for conversions