Replies: 17 comments 12 replies
|
Device: GeForce GTX 970; Mac Pro 1,1
|
|
Device: GeForce RTX 2070 with Max-Q Design; Razer Blade 15 RZ09-03017EM8
|
|
Device: GeForce RTX 2070 with Max-Q Design; Razer Blade 15 RZ09-03287EM2
|
|
Device: NVIDIA V100; Computer: Summit at OLCF
|
#!/bin/bash
rm -fr !("compile")
export CUDAHOME=/usr/local/cuda-11.2
export CUDACXX=$CUDAHOME/bin/nvcc
export FC=/usr/bin/gfortran
export CXX=/usr/bin/g++
export ACC=/home/liuchw/shared/nvidia/hpc_sdk/Linux_x86_64/21.1/compilers/bin/nvc++
export opt=release
export host=0
export prec=m
export compute_capability=80
export cuda_dir=$CUDAHOME
export CMAKEHOME=/home/liuchw/shared/cmake3.12/bin/
$CMAKEHOME/cmake ../
make -j
|
|
This commit "6a1c6104" was not found in the Git history. This must have been due to the local pull-merge operation. |
|
Oh, I see. This commit is the version of |
|
|
Fantastic and thanks! This is an issue I'd like to follow up with a bit more because it looks familiar to me and I still don't fully understand or replicate it on our multi-GPU machines. Is there any switch to set up the number of processes when you submit jobs to your nodes? This error message seemed to complain about cards being accessed/initialized by another process. |
|
This isn't a node, this is a standalone server. There is nothing to isolate any of the resources. However, I checked and I'm currently the only user on the machine (standard account, not root). There is no X running and nvidia-smi shows no processes running on either GPU on the machine. I can try comparing to some other machines I have access to that use Slurm and isolate resources, but this will take a while since I'll need to install the Nvidia pre-requisites. |
|
We think this is an issue related to the undocumented changes in CUDA 11. As the code was mostly tested with CUDA 11, not 10, we didn't find out the cause of this issue until recently. We believe that this issue is fixed now. |
OS: macOS High Sierra 10.13.6 (17G4015) |
|
Great! Tinker9 works on macOS, in addition to LInux. Now we just have to get Apple and NVIDIA to work together again, and support NVIDIA GPUs on macOS :) |
|
Reference: #199 CPU: 11th Gen Intel(R) Core(TM) i9-11950H @ 2.60GHz Tinker9 1.0.0 GIT 18f90f1 (+1 line :)) |
|
GPU: NVIDIA GeForce RTX 3080
create build directoryload spack packagesexport pathscompilation
|
|
Device: GPU; Computer
Had to manually edit CMakeLists.txt and comment those lines: mkdir build && cd build ../envs.sh ./tinker9 info |
|
Actually noticed that Number of CUDA cores is 8192, but |
|
Looks like just a mistake in number of cores calculation #223. |
|
|
Again, thank you for the pull request. But I still don't understand why commenting these lines in CMake script is necessary. The intension is to pass 'cc80' to nvc++. In your case, this would be 'cc86'. Would you help me understand the necessity? Is it because cc86 is not supported by nvc++ and it will result in compilation failure? |
|
Yes. Looks like nvc++ doesn't support ccXX in -ta argument. At least version 23.3. It gives this error in leave it as is: Its the same with 86. |
|
Hi, |
|
August 2023 GPU Device : Setting Device ID to 0 from GPU utilization Program Information |
|
September 2023 GPU Device : Setting Device ID to 0 from GPU utilization Program Information |
|
Used native nvidia utilities, no ACC calls.
Also had to install catch2 utility on one of my Debian systems to get cmake to do 100% build. |
|
Device: GPU; Computer
Did all the changes in #121 (comment) |
|
@zhi-wang We were able to compile it for RTX5090 on Rocky linux10, with CUDA-12.9 (0r 12.6) and hpc_sdk 25, and gcc 12.4. Anything else needs to be changed/optimized for RTX5090? |
|
Thanks for keeping me in the loop. We are talking about two questions here: (1) Can the code compile and run? (2) Is it running at the highest speed? For (1), the changes you or your group made look fine. The code only needs a small amount of hardware information that isn’t available from the driver -- most of it still comes from the driver or runtime libraries. If cc=12.0 doesn’t compile, my guess is simply that the compiler hasn’t caught up to supporting 12.0 yet. For (2), that’s the trickier one. When I originally wrote the code, I treated those hardware values (whether coded or obtained at runtime) only as hints to guide performance tuning. It was basically some manual tweaking that gave good enough speed for the typical atom numbers we were running back then. But I can’t claim it’s still optimal today -- the hardware, drivers, and system sizes may have all changed. To be sure, it would take some semi-serious (or at least semi-casual) benchmarking. Best, |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I'll use this thread to record the successful builds on the new machines or with the new softwares (drivers, compilers, etc.).
You are welcome to paste your
tinker9 infooutput as well.Template (feel free to modify):
Useful commands:
All reactions