-
Notifications
You must be signed in to change notification settings - Fork 236
feat: add Cupy samples #518
base: master
Are you sure you want to change the base?
Conversation
fbddfa3
to
0b1f36b
Compare
def get_cupy() -> str: | ||
CUDA_VERSION = os.environ.get("CUDA_VERSION", None) | ||
if CUDA_VERSION>="11.2": # after 11.2 use | ||
cupy_pack = f"cupy-cuda{CUDA_VERSION[:2]}x" | ||
else: | ||
cupy_pack = f"cupy-cuda{CUDA_VERSION[:4].replace('.','')}" | ||
return cupy_pack |
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.
This fails if the env variable is not set. Can we have a check that in this case does not install any cupy or installs just the latest ?
Also you could do a fall through check: env variable -> nvcc subprocess -> nvidia-smi.
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 considered the approach of env, nvcc and nvidia-smi, and there will encounter some issues like
- no env var set
- nvcc not available in the runtime image, like
nvidia/cuda:11.7.1-runtime-ubuntu22.04
- nvidia-smi always shows the latest CUDA version 12.2 by the host driver while docker is using 11.7
or even has no nvidia-smi for some cases I have seen.
Can I list all cuda versions in cuda directory /usr/local/cuda*
?
while I have no idea about windows cuda
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.
Yeah as usual windows is the annoying part. This is why I though you could do a fall through approach, trying one after the other and if nothing works just assume a version ?
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.
For linux, I check /usr/local/cuda-*
to extract the version.
For windows, I implemented the fall-through approach (nvcc > nvidia-smi).
This approach should handle most of the cases.
There are some potential issues still in the fall-through approach.
- nvcc not available.
utility
not inNVIDIA_DRIVER_CAPABILITIES=compute,video
(also a conflict in Dockerfile.tensorrt)- CUDA version in nvidia-smi does not match the cuda installed.
Since cupy package conflict with each other, assume one is not a good idea. I prefer not to install it if the CUDA version cannot be accessed correctly.
If the complexity goes up, I think we should let the user install it manually.
hello world,
this PR do the followings:
SampleTensorRTResnet.py
please review