2017-08-30 2 views
0

Je suis intéressé à utiliser l'API d'exécution PGI OpenACC directement à partir du code compilé par GCC.Liaison de la bibliothèque d'exécution OpenACC PGI directement avec gcc

J'ai remarqué que l'installation de PGI OpenACC fournit deux en-têtes openacc.h. Un pour PGI (situé dans include/openacc.h) et un autre qui semble être compatible avec GCC (etc/include_acc/openacc.h). Il est sûr d'utiliser le deuxième en-tête avec GCC?

Jusqu'à présent, j'ai pu compiler & terme un petit test:

#include <openacc.h> 
#include <cuda_runtime_api.h> 
#include <stdio.h> 

int main() 
{ 
    acc_init(acc_device_nvidia); 

    int ndev = acc_get_num_devices(acc_device_nvidia); 

    printf("Num OpenACC devices: %d\n", ndev); 

    cudaGetDeviceCount(&ndev); 

    printf("Num CUDA devices: %d\n", ndev); 

    return 0; 
} 

utilisant IGP:

pgcc -acc -ta=tesla,cuda8.0 -Mcuda ./test.c -o oacc_test.pgi

utilisant GCC + PGI OpenACC:

gcc -isystem /usr/local/cuda-8.0/include -isystem /usr/local/pgi/linux86-64/17.4/etc/include_acc -o oacc_test.both test.c -L/usr/local/cuda-8.0/lib64 -Wl,-rpath,/usr/local/cuda-8.0/lib64 -lcudart -lcuda -L/usr/local/pgi/linux86-64/17.4/lib -Wl,-rpath,/usr/local/pgi/linux86-64/17.4/lib -laccapi -laccg -laccnc -laccn -laccg2 -ldl -lpgc -lm

U chanter GCC + GCC OpenACC: (pour comparaison)

gcc -fopenacc -isystem /usr/local/cuda-8.0/include -o oacc_test.gnu test.c -L/usr/local/cuda-8.0/lib64 -Wl,-rpath,/usr/local/cuda-8.0/lib64 -lcudart -lcuda

et exécuter:

$ ./oacc_test.pgi 
Num OpenACC devices: 4 
Num CUDA devices: 4 
$ ./oacc_test.both 
Num OpenACC devices: 4 
Num CUDA devices: 4 
$ ./oacc_test.gnu 

libgomp: device type nvidia not supported 

Plus d'infos:

$ ldd oacc_test.pgi 
    linux-vdso.so.1 (0x00007ffd843f8000) 
    libaccapi.so => /usr/local/pgi/linux86-64/17.4/lib/libaccapi.so (0x00007fa5a2b9f000) 
    libaccg.so => /usr/local/pgi/linux86-64/17.4/lib/libaccg.so (0x00007fa5a2981000) 
    libaccnc.so => /usr/local/pgi/linux86-64/17.4/lib/libaccnc.so (0x00007fa5a2777000) 
    libaccn.so => /usr/local/pgi/linux86-64/17.4/lib/libaccn.so (0x00007fa5a2552000) 
    libaccg2.so => /usr/local/pgi/linux86-64/17.4/lib/libaccg2.so (0x00007fa5a233c000) 
    libcudapgi.so => /usr/local/pgi/linux86-64/17.4/lib/libcudapgi.so (0x00007fa5a213b000) 
    libcudart.so.8.0 => /usr/local/cuda/lib64/libcudart.so.8.0 (0x00007fa5a1ed5000) 
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa5a1b49000) 
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa5a1945000) 
    libcudadevice.so => /usr/local/pgi/linux86-64/17.4/lib/libcudadevice.so (0x00007fa5a1731000) 
    libpgmp.so => /usr/local/pgi/linux86-64/17.4/lib/libpgmp.so (0x00007fa5a14af000) 
    libnuma.so => /usr/local/pgi/linux86-64/17.4/lib/libnuma.so (0x00007fa5a12ae000) 
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa5a1091000) 
    libpgc.so => /usr/local/pgi/linux86-64/17.4/lib/libpgc.so (0x00007fa5a0dae000) 
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa5a0aaa000) 
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa5a070b000) 
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa5a04f2000) 
    /lib64/ld-linux-x86-64.so.2 (0x000055767be3b000) 
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa5a02ea000) 

$ ldd oacc_test.both 
    linux-vdso.so.1 (0x00007ffe55753000) 
    libcudart.so.8.0 => /usr/local/cuda/lib64/libcudart.so.8.0 (0x00007f7ddfe3c000) 
    libcuda.so.1 => /usr/lib/x86_64-linux-gnu/libcuda.so.1 (0x00007f7ddf3d8000) 
    libaccapi.so => /usr/local/pgi/linux86-64/17.4/lib/libaccapi.so (0x00007f7ddf1b8000) 
    libaccg.so => /usr/local/pgi/linux86-64/17.4/lib/libaccg.so (0x00007f7ddef9a000) 
    libaccnc.so => /usr/local/pgi/linux86-64/17.4/lib/libaccnc.so (0x00007f7dded90000) 
    libaccn.so => /usr/local/pgi/linux86-64/17.4/lib/libaccn.so (0x00007f7ddeb69000) 
    libaccg2.so => /usr/local/pgi/linux86-64/17.4/lib/libaccg2.so (0x00007f7dde955000) 
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7dde751000) 
    libpgc.so => /usr/local/pgi/linux86-64/17.4/lib/libpgc.so (0x00007f7dde46e000) 
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7dde16a000) 
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7ddddcb000) 
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7dddbac000) 
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7ddd9a4000) 
    libnvidia-fatbinaryloader.so.378.13 => /usr/lib/x86_64-linux-gnu/libnvidia-fatbinaryloader.so.378.13 (0x00007f7ddd753000) 
    /lib64/ld-linux-x86-64.so.2 (0x00005593f06f5000) 

$ ldd oacc_test.gnu 
    linux-vdso.so.1 (0x00007ffd967d7000) 
    libcudart.so.8.0 => /usr/local/cuda/lib64/libcudart.so.8.0 (0x00007f9002679000) 
    libcuda.so.1 => /usr/lib/x86_64-linux-gnu/libcuda.so.1 (0x00007f9001c15000) 
    libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f90019e8000) 
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f90017cb000) 
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f900142c000) 
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9001226000) 
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f900101e000) 
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9000d1a000) 
    libnvidia-fatbinaryloader.so.378.13 => /usr/lib/x86_64-linux-gnu/libnvidia-fatbinaryloader.so.378.13 (0x00007f9000ac9000) 
    /lib64/ld-linux-x86-64.so.2 (0x0000563eee684000) 

Est-ce est sûr d'utiliser l'API PGI OpenACC Runtime façon?

Y a-t-il également une différence entre l'exécution de CUDA fournie par Nvidia (habituellement dans /usr/local/cuda) et celle fournie par PGI (dans mon cas dans /usr/local/pgi/linux86-64/2017/cuda)? J'ai remarqué que pgcc utilise le CUDA 7.5 à partir de son propre chemin d'installation mais lorsque -ta=cuda8.0 est fourni, il utilise celui de /usr/local/cuda. Une raison particulière?

Répondre

1

Les objets compilés PGI sont interopérables avec GNU et il est bon de mélanger le code compilé PGI OpenACC avec les objets compilés GNU. Bien que les bibliothèques d'exécution OpenACC ne soient pas compatibles, je vous recommande de ne pas mélanger le code OpenACC. Notez que le support de GNU pour OpenACC a été amélioré dans leur version 7.0, donc pendant que je travaille pour PGI, je vous encourage à essayer les deux compilateurs. Le seul inconvénient est qu'ils (GNU) ne supportent pas la construction "kernels", donc vous voudrez vous en tenir à l'utilisation de régions "parallèles". En ce qui concerne les bibliothèques CUDA, PGI envoie toutes les bibliothèques dont nous avons besoin pour compiler votre code OpenACC. Cependant, il n'y a pas de différence dans les bibliothèques CUDA elles-mêmes. Nous ne voulions pas que les utilisateurs aient à co-installer le SDK CUDA et cela nous permet d'ajouter des indicateurs de commodité tels que "-Mcudalib [= cublas | cufft | curand | cusolver | cusparse]" puisque nous savons où se trouvent ces bibliothèques ainsi que nos propres modules d'interface Fortran à ces bibliothèques. Si vous ne disposez pas de l'indicateur "CUDAROOT =" sur votre ligne de compilation, "-ta = tesla: cuda8.0" doit utiliser le répertoire CUDA 8.0 fourni par le PGI situé dans "$ PGI/linux86-64/2017/cuda/8.0 ". Êtes-vous sûr d'utiliser l'installation/usr/local/cuda? Vous pouvez vérifier en ajoutant l'indicateur verbose (-v) pour voir ce que le pilote du compilateur est en train d'exécuter ou "-dryrun" pour voir les commandes sans que le pilote les exécute.Une autre possibilité est que vous utilisiez des drapeaux "-L" ou "-Wl" pour pointer vers l'installation de CUDA (comme avec GNU), auquel cas l'éditeur de liens récupèrera les bibliothèques CUDA de ces répertoires . Bien que ce soit les mêmes bibliothèques que nous expédions, cela ne devrait pas poser de problème.

+0

Merci, je vais vérifier gcc 7.0. La chose à propos du répertoire CUDA 8.0 ... C'était de ma faute parce que 'LD_LIBRARY_PATH' était réglé sur':/usr/local/cuda/lib64' – Hopobcn