Both sides previous revision
Previous revision
Next revision
|
Previous revision
Next revision
Both sides next revision
|
gpu [2018/01/15 10:39] popel [Set-up CUDA and CUDNN] |
gpu [2018/01/23 23:16] popel [Servers with GPU units] |
| |
| machine | GPU type | [[https://en.wikipedia.org/wiki/CUDA#GPUs_supported|cc]] | GPUs | GPU RAM | Comment | | | machine | GPU type | [[https://en.wikipedia.org/wiki/CUDA#GPUs_supported|cc]] | GPUs | GPU RAM | Comment | |
| iridium | Quadro K2000 | cc3.0 | 1| 2 GB | | | | iridium | Quadro K2000 | cc3.0 | 1| 2 GB | driver(iridium)=367.48 | |
| titan-gpu | GeForce GTX Titan Z | cc3.5 | 2| 6 GB | | | | titan-gpu | GeForce GTX Titan Z | cc3.5 | 2| 6 GB | driver(titan-gpu)=381.22 | |
| twister1; twister2; kronos | Tesla K40c | cc3.5 | 1| 12 GB | | | | twister1; twister2; kronos | Tesla K40c | cc3.5 | 1| 12 GB | driver(twister*)=367.48, driver(kronos)=384.81 | |
| dll1; dll2 | GeForce GTX 1080 | cc6.1 | 8| 8 GB | | | | dll1; dll2 | GeForce GTX 1080 | cc6.1 | 8| 8 GB | driver(dll1)=375.66, driver(dll2)=387.26 | |
| titan | GeForce GTX 1080 | cc6.1 | 1| 8 GB | | | | titan | GeForce GTX 1080 | cc6.1 | 1| 8 GB | driver(titan)=381.22| |
| dll4; dll5 | GeForce GTX 1080 Ti | cc6.1 | 10| 11 GB | | | | dll4; dll5 | GeForce GTX 1080 Ti | cc6.1 | 10| 11 GB | driver(dll4)=375.66, driver(dll5)=384.69 | |
| dll3; dll6 | GeForce GTX 1080 Ti | cc6.1 | 9| 11 GB | | | | dll3; dll6 | GeForce GTX 1080 Ti | cc6.1 | 9| 11 GB | driver(dll3)=375.66, driver(dll6)=384.69 | |
| |
Desktop machines: | Desktop machines: |
* All the rules from [[:Grid]] apply, even more strictly than for CPU because there are too many GPU users and not as many GPUs available. So as a reminder: always use GPUs via ''qsub'' (or ''qrsh''), never via ''ssh''. You can ssh to any machine e.g. to run ''nvidia-smi'' or ''htop'', but not to start computing on GPU. Don't forget to specify you RAM requirements with e.g. ''-l mem_free=8G,act_mem_free=8G,h_vmem=12G''. | * All the rules from [[:Grid]] apply, even more strictly than for CPU because there are too many GPU users and not as many GPUs available. So as a reminder: always use GPUs via ''qsub'' (or ''qrsh''), never via ''ssh''. You can ssh to any machine e.g. to run ''nvidia-smi'' or ''htop'', but not to start computing on GPU. Don't forget to specify you RAM requirements with e.g. ''-l mem_free=8G,act_mem_free=8G,h_vmem=12G''. |
* Always specify the number of GPU cards (e.g. ''gpu=1''), the minimal Cuda capability you need (e.g. ''gpu_cc_min3.5=1'') and you GPU memory requirements (e.g. ''gpu_ram=2G''). Thus e.g. <code>qsub -q gpu.q -l gpu=1,gpu_cc_min3.5=1,gpu_ram=2G</code> | * Always specify the number of GPU cards (e.g. ''gpu=1''), the minimal Cuda capability you need (e.g. ''gpu_cc_min3.5=1'') and you GPU memory requirements (e.g. ''gpu_ram=2G''). Thus e.g. <code>qsub -q gpu.q -l gpu=1,gpu_cc_min3.5=1,gpu_ram=2G</code> |
* If you need more than one GPU card (on a single machine), always require as many CPU cores (''-pe cmp X'') as many GPU cards you need. E.g. <code>qsub -q gpu.q -l gpu=4,gpu_cc_min3.5=1,gpu_ram=7G -pe smp 4</code> **Warning**: currently, this does not work, so you can omit the ''-pe cmp X'' part. Milan Fučík is working on a fix. | * If you need more than one GPU card (on a single machine), always require as many CPU cores (''-pe smp X'') as many GPU cards you need. E.g. <code>qsub -q gpu.q -l gpu=4,gpu_cc_min3.5=1,gpu_ram=7G -pe smp 4</code> **Warning**: currently, this does not work, so you can omit the ''-pe smp X'' part. Milan Fučík is working on a fix. |
* For interactive jobs, you can use ''qrsh'', but make sure to end your job as soon as you don't need the GPU (so don't use qrsh for long training). **Warning: ''-pty yes bash'' is necessary**, otherwise the variable ''$CUDA_VISIBLE_DEVICES'' will not be set correctly. E.g. <code>qrsh -q gpu.q -l gpu=1,gpu_ram=2G -pty yes bash</code>In general: don't reserve a GPU (as described above) without actually using it for longer time. (E.g. try separating steps which need GPU and steps which do not and execute those separately on our GPU resp. CPU cluster.) Ondřej Bojar has a script /home/bojar/tools/servers/watch_gpus for watching reserved but unused GPU on most machines which will e-mail you, but don't rely on in only. | * For interactive jobs, you can use ''qrsh'', but make sure to end your job as soon as you don't need the GPU (so don't use qrsh for long training). **Warning: ''-pty yes bash'' is necessary**, otherwise the variable ''$CUDA_VISIBLE_DEVICES'' will not be set correctly. E.g. <code>qrsh -q gpu.q -l gpu=1,gpu_ram=2G -pty yes bash</code>In general: don't reserve a GPU (as described above) without actually using it for longer time. (E.g. try separating steps which need GPU and steps which do not and execute those separately on our GPU resp. CPU cluster.) Ondřej Bojar has a script /home/bojar/tools/servers/watch_gpus for watching reserved but unused GPU on most machines which will e-mail you, but don't rely on in only. |
* Note that the dll machines have typically 10 cards, but "just" 250 GB RAM. So the expected (maximal) ''mem_free'' requirement for jobs with 1 GPU is 25GB. If your 1-GPU job takes e.g. 80 GB and you submit three such jobs on the same machine, you have effectively blocked the whole machine and seven GPUs remain unused. | * Note that the dll machines have typically 10 cards, but "just" 250 GB RAM. So the expected (maximal) ''mem_free'' requirement for jobs with 1 GPU is 25GB. If your 1-GPU job takes e.g. 80 GB and you submit three such jobs on the same machine, you have effectively blocked the whole machine and seven GPUs remain unused. |