-
Notifications
You must be signed in to change notification settings - Fork 126
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
GCC/CUDA compatibility table #526
Comments
On a happy note, current master doesn't need boost anymore, so this was more feasible as we now eliminated added complexities from various boost incompatibilities. |
GCC 9.2 Works with Cuda 10.2 Tested on my machine Cheers, Nick |
I edited the original post adding that CUDA 8 is no longer supported. |
I added CUDA 10.2 into the table with GCC versions that I have had a chance to test. |
In most things, these work but the CUSparse tensor operations are complaining at compilation.
Note:
|
We will take a look. I am wonder if we should make compilation support for GPUs below Maxwell optional. Or even below Pascal? It would make compilation quite a bit faster. Currently that can be disabled manually. |
The compilation issue is that function @emjotde , we should just generate the CUDA targets based on the CUDA version. E.G. if you are using CUDA11, don't target old architectures. |
@XapaJIaMnu there is really no correlation between CUDA version and architectures though. I can run CUDA11 on Maxwell perfectly fine, I just cannot use some newer features, I think? |
@emjotde as far as I understand, and reading this and this, the nvcc compiler drops old target architectures with new releases, making it impossible to compile code that will run on a |
compute_20 is not supported, I think we start with _35. Need to check. |
I'm trying to build on Ubuntu 20.04, CUDA 11.0, GCC 9.3.0 In addition to the CUSparse tensor errors mentioned by @alvations, and the deprecated targets, I'm getting:
I updated lines 169 and 304 of CMakeLists.txt ( Also removing |
Hi everyone. Is there someone here who would know if CUDA 11.0 (or higher ?) is compatible with the latest version of marian (1.10) ? I have two 3090RTX but they require CUDA 11 at minima :/. Thanks ! |
Hi, yes, we haven't updated the table yet, but should just work. At least with newer Ubuntu versions, like 18.04 and higher. |
Do these GPUs have Ampere chips? If yes, then we are not using the newest bits for those yet, since I didn't have a chance to test things on those archs, but should arrive very soon. I have access to a couple of shiny A100s now. |
Wow, such a reactivity ! Yes, the RTX 3090 are Ampere arch. Also, I am on Ubuntu 18.04. So you think it should work, but just not optimized yet ? |
Yes. Exactly. |
Ok ! Thanks ! (I got multiple errors while compiling marian since this morning, but probably because I am switching between cuda/cudnn/gcc versions and it's creating a mess. If the error persist , I will maybe open an issue (if it's Marian related)) |
Any updates on support for this configuration?
Seems like there is a need to install
But cmake is still complaining =( Also, normally people would put cuda in
Any clues where should BTW, this didn't work:
Note: This config above is the default config that comes with https://lambdalabs.com/service/gpu-cloud/pricing on machine with 1x A100 |
For anyone dealing with:
Try:
Then:
And check:
|
Hi, I'm a Linux Support Engineer for Lambda Cloud. I may be missing something important here, but I was able to successfully build marian (without testing the resulting executable yet) on a fresh 1x A6000 instance from Lambda Cloud by following the instructions at https://marian-nmt.github.io/docs/ . Since CUDA is installed via Lambda Stack, it's not installed in /usr/local/ like a "non-default" install would be, and so you shouldn't need to follow the "Non-default CUDA" instructions. I did run into the problem with cuBLASLt not being found by cmake when building a dynamically linked executable, but building a staticly linked executable seems to work. Here's a script confirmed to work on a fresh 1x A6000 instance on May 23rd 2022. (We're pushing out a new VM image later today, I'll try to double check that this works with the new image as well. If it doesn't, I'll try to post an updated version that does).
|
Putting this here into an issue for later. Should push this tomorrow to fix the Jenkins issues. Gawd, that was horrible :) good FAQ item though. BUG are bugs in GCC or CUDA or combination, not in Marian and will not be fixed. Plain NO means CUDA does not support that particular compiler by design, this cannot be fixed either. In the case of gcc 4.9 and lower this is our choice to not support that compiler as its stdlib does not have full C++11 compatibility.
If you are in a "NO" cell, there is no way we can help you other than suggesting to upgrade/downgrade GCC and upgrade CUDA.
8.0NOYESNO/BUGNONONONOThe text was updated successfully, but these errors were encountered: