You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After reading conda cuda builds, I think we should do the same (if I understood the article correctly, please correct me if I may have misunderstood something). This would have the following advantages I think:
We wouldn't rely on a specific toolkit-version where some users might have issues if they a gpu-driver which is not up to date (even though the minimum required driver-version is only dependent on the major version of cuda-toolkit (see cuda compatibility).
We wouldn't have to worry about fixed-toolkit which could constrain us on which package & version we intend to include
This would imply changing the conda-build recipe of karabo and cuda-enabled packages of the Feedstock as well as changing the github-workflows and the dockerfiles.
The text was updated successfully, but these errors were encountered:
Wouldn't this mean we'd have to test against all CUDA versions?
Using the oldest-possible CUDA versions means we're compatible with most drivers. That looks like a win. This proposal would result in Karabo crashes for users with out-of-date drivers.
If we can test against CUDA (which we don't do at the moment because the CI doesn't have GPUs), I think we shouldn't have to care about the toolkit-version because conda should identify the highest compatible version according to the documentation.
After reading conda cuda builds, I think we should do the same (if I understood the article correctly, please correct me if I may have misunderstood something). This would have the following advantages I think:
This would imply changing the conda-build recipe of karabo and cuda-enabled packages of the Feedstock as well as changing the github-workflows and the dockerfiles.
The text was updated successfully, but these errors were encountered: