[CUDA API] Le topic qui parle d'architecture et de GPGPU sur les cartes Nvidia

[Taro]

CUDA API
Hardware / API / Software

---

Salut les canards x86 !

J'ai récemment été accepté dans le groupe et j'en suis très honoré.
Pour ma part, je suis intéressé par tout (architecture processeurs, instructions, architectures exotiques, programmation bas-niveau, débats et boules de cristal), mais je ne suis expert dans aucun domaine (j'ai eu une formation de développeur d'abord orientée générique et haut-niveau, puis une spécialisation 3D temps réel, jeux vidéos et un peu plus bas-niveau, et enfin une ré-orientation vers la programmation sur GPU en autodidacte).

J'ai quand même un domaine que j'affectionne particulièrement : c'est ce dernier vers lequel je me suis redirigé. Après m'y être intéressé "comme ça" durant ma formation, à coups de quelques expérimentations et en commençant par OpenCL, je me suis procuré un très bon bouquin pour étudier cela de plus près et ce avec CUDA. Après avoir obtenu mon diplôme d'école de JV, j'ai intensivement travaillé avec pendant environ trois mois, et après au total six mois (trois mois intensifs de CUDA, et trois autres mois plus légers et plus axés sur ma recherche), j'ai trouvé un emploi dans le domaine.

Je ne m'en suis pas caché, et lorsque j'ai fait ma demande pour rejoindre le groupe Advanced, j'ai précisé que c'est essentiellement pour ce qui touche aux GPUs.

Après une recherche rapide sur le mot-clé "cuda" dans cette sextion x86, en incluant les forums enfants, il semble que ce mot ait été référencé à l'occasion mais qu'aucun "topic dédié" n'ait encore été créé.
Je propose donc d'ouvrir le bal avec cette ouverture de topic.

Officiellement, nous pourrons donc discuter des architectures GPU de Nvidia, et des potentiels liens avec l'API CUDA, voire même la Driver API. Si quelqu'un discute de l'un de ces aspects sans lien avec les autres, ce n'est pas grave, car les GPUs et les cartes graphiques en général nous intéressent et nous sommes pleins d'amour (mais aussi pleins de code PTX/SASS et pleins de TéraFlops, faut pas déconner).

Officieusement, je viendrai ici tenter d'aspirer toutes vos connaissances pointues sur ces GPUs et cette API afin d'enrichir mes actuelles maigres et propres connaissances.
Néanmoins mon bagage "minimum syndical" m'a permis de cacher ma grise et sombre fourrure de loup pour me déguiser en brebis et rejoindre le troupeau en douceur.

Ce topic peut donc servir :

• à discuter des différentes architectures
• à discuter des pilotes et des différents SDK et API
• à échanger des liens, des articles et des d'autres sources
• à partager ce que vous avez pu réaliser ou ce que d'autres ont fait et que vous trouvez intéressant
• à lancer des débats dans la bonne humeur
• à se faire plein de gros bisous partout

Si vous avez des idées de sections ou pour la structure de l'OP en lui-même, je prends toujours, je n'en suis pas à mon premier topic mais chaque sujet est unique et toute suggestion vaut la peine d'être considérée.

[Thamior]

Moi j'ai une question philosophique pour bien partir en week-end.
D'un côté, ok, les GPU ont du throughput sous le capot, donc si on a une application massivement parallèle, ça a du sens d'essayer de la faire tourner sur le GPU.
D'un autre côté, le GPU il est quand même fait pour faire de la 2D/3D, il me semble même qu'il y a du hard spécialement dédié à ça (au hasard, la sortie vidéo ). Bref, est-ce que ce n'est pas un contresens de pousser le GPGPU plutôt que de développer des trucs à la Xeon Phi, puisque le GPU, il faut qu'il soit bon en 2D/3D et en GPGPU, alors que le Xeon Phi, la 2D/3D, il s'en fout. Voilà, à vos insultes

[Taro]

Ce que tu dis se tient, mais à cet appel aux insultes (es-tu maso ? ) je répondrai simplement que les GPUs ont prouvé qu'ils avaient tout de même un intérêt dans ce domaine.
Dès lors que le calcul est massivement parallèle, ils font moins les mariolles tes Xeon.

Jolie signature, sinon.

[Thamior]

Ah mais c'est sûr, dans les faits les GPUs s'en sortent parfois (souvent?) mieux. C'est plus l'idée qu'ils doivent se trainer le "boulet" de la 2D/3D lors du design, alors que les accélérateurs types Xeon Phi non.
Bon cela dit je peux entendre que tous les PC ont un GPU alors que tous les PC n'ont pas un accélérateur dédiés aux workloads massivement parallèles.

[Taro]

Ouaip. C'est ptet pour ça que les suites logicielles connues qui ont besoin d'accélération utilisent de l'OpenCL, du CUDA ou encore autre chose d'équivalent pour booster leurs calculs, et pas des Xeon Phi.
Chez Nvidia Maxwell est un peu le mauvais élève, mais quand tu regardes les perfs des Kepler en double précision même la 770 était pas trop mal pour son prix, et la Titan (ou de manière générale, les trois premières Titan) n'en parlons pas le ratio était très intéressant.

Pour étaler un peu ma vie : perso actuellement je bosse dans une startup parisienne (j'ai quitté ma Drôme natale et bien-aimée pour eux ) qui accélère sur GPU des calculs de propagation radio dans le domaine des télécoms.

[Møgluglu]

Moi j'ai une question philosophique pour bien partir en week-end.
D'un côté, ok, les GPU ont du throughput sous le capot, donc si on a une application massivement parallèle, ça a du sens d'essayer de la faire tourner sur le GPU.
D'un autre côté, le GPU il est quand même fait pour faire de la 2D/3D, il me semble même qu'il y a du hard spécialement dédié à ça (au hasard, la sortie vidéo ). Bref, est-ce que ce n'est pas un contresens de pousser le GPGPU plutôt que de développer des trucs à la Xeon Phi, puisque le GPU, il faut qu'il soit bon en 2D/3D et en GPGPU, alors que le Xeon Phi, la 2D/3D, il s'en fout. Voilà, à vos insultes

Le truc, c'est que les développeurs de moteurs graphiques sont les premiers à réclamer plus de flexibilité. Par exemple Tim Sweeney.
Et ils l'obtiennent : Vulkan est la dernière étape en date. Du point de vue de Vulkan, un GPU c'est essentiellement un processeur généraliste masisvement parallèle et quelques unités spécialisées à côté.

Et ce n'est pas plus choquant de faire tourner du LINPACK sur un GPU avec des rasterizer et des unités de sampling de texture que de faire tourner les SPECint sur un CPU avec des FPU, du SIMD, du chiffrement AES et j'en passe.
Et avec 5 Tflops double précision dans Pascal, je soupçonne que les unités graphiques ne pèsent pas bien lourd dans le budget power global.

Au passage, le Xeon Phi n'aurait probablement pas existé s'il n'y avait pas eu Larrabee.

[Taro]

Et ce n'est pas plus choquant de faire tourner du LINPACK sur un GPU avec des rasterizer et des unités de sampling de texture que de faire tourner les SPECint sur un CPU avec des FPU, du SIMD, du chiffrement AES et j'en passe.
Et avec 5 Tflops double précision dans Pascal, je soupçonne que les unités graphiques ne pèsent bien pas lourd dans le budget power global.

Alors là je réponds tout de suite : THIS.
Clairement d'accord avec toi.

Nvidia a probablement enfin compris que les gamers s'en fichent d'avoir 1/8 ou 1/32 en rapport DP/FP et que les machines de calcul n'ont pas besoin de faire tourner The Witcher III en Ultra.

[Møgluglu]

Ouaip. C'est ptet pour ça que les suites logicielles connues qui ont besoin d'accélération utilisent de l'OpenCL, du CUDA ou encore autre chose d'équivalent pour booster leurs calculs, et pas des Xeon Phi.

Techniquement tu peux quand-même programmer les Xeon Phi et autres CPU AVX en OpenCL. À plus haut niveau, Intel pousse OpenMP 4.0 contre l'OpenACC de Nvidia, mais ça reste essentiellement la même chose. Le Xeon Phi, c'est jamais qu'un GPU à l'architecture un peu rigide et sans accélération graphique. Et l'AVX 512 permettra enfin d'avoir du "vrai" SIMD dans les CPU... enfin à condition que ça soit des Xeon.

Pour étaler un peu ma vie : perso actuellement je bosse dans une startup parisienne (j'ai quitté ma Drôme natale et bien-aimée pour eux ) qui accélère sur GPU des calculs de propagation radio dans le domaine des télécoms.

C'est quels genre de calculs ?

[Taro]

C'est quels genre de calculs ?

De la propagation. Pour divers buts (par exemple, réorganisation du réseau ou visualisation) on considère la carte sous forme d'une image de pixels, pour chaque pixel on considère chaque antenne et on fait un calcul pour estimer le signal reçu, en prenant en compte les aléas du terrain entre les deux, et tout un tas de paramètres.

[vectra]

Mais y'a pas de l'AVX 512 sur les Haswell et les Skylake déjà? C'est pas spécifique à Xéon Phi?

Et j'arrive pas à me figurer si Xeon Phi est un secteur de niche soutenu par Intel mais on ne sait pas combien de temps encore, où si y'a déjà plusieurs générations de CPU qui ont été déclinées en Xeon Phi comme c'est déjà largement le cas chez Nvidia.

L'idée n'étant pas de foutre la merde dans ce beau topic, mais de me faire une idée globale de la big picture qui figure le truc, tu vois.
Oui, à 5h du mat' après une nuit blanche de réda corrections, je suis d'humeur lyrique

[Taro]

Au secours ! Un tournevis lyrique s'attaque à mon topic !

[Taro]

En effet l'AVX 512 semble être de la partie sur Skylake : voir cet article sur HFR.

[Møgluglu]

De la propagation. Pour divers buts (par exemple, réorganisation du réseau ou visualisation) on considère la carte sous forme d'une image de pixels, pour chaque pixel on considère chaque antenne et on fait un calcul pour estimer le signal reçu, en prenant en compte les aléas du terrain entre les deux, et tout un tas de paramètres.

C'est un genre de lancer de rayon du coup ?
C'est compute-bound ?

Mais y'a pas de l'AVX 512 sur les Haswell et les Skylake déjà? C'est pas spécifique à Xéon Phi?

C'est spécifique au prochain Xeon Phi (Knights Landing) et aux prochains Skylake Xeon mais pas non plus les Skylake Xeon E3 que tu peux acheter maintenant hein, ils sont pas assez cher. Donc en fait, en dehors des effets d'annonce il n'y a pas d'AVX 512 du tout actuellement. Mais pour contrer la sortie de Pascal on peut penser qu'Intel va se bouger.

Et j'arrive pas à me figurer si Xeon Phi est un secteur de niche soutenu par Intel mais on ne sait pas combien de temps encore, où si y'a déjà plusieurs générations de CPU qui ont été déclinées en Xeon Phi comme c'est déjà largement le cas chez Nvidia.

Après quelques protos de Larrabee plus ou moins mort-nés, tu as :
- Knights Ferry, 32 cores en 45nm avec des vrais morceaux de Larrabee, distribué comme proto aux VIP,
- Knights Corner, 60 cores en 22nm, le Xeon Phi actuel, commercialisé,
- Knights Landing, 72 cores en 14nm, le prochain Xeon Phi incessamment sous peu.
Et ils en prévoient un autres après je crois.

[Taro]

C'est un genre de lancer de rayon du coup ?
C'est compute-bound ?

Mouais, ça pourrait être vu comme un lancer de rayon, mais c'est quand même vachement plus complexe.
Il y a énormément de trucs en plus : réflection, réfraction, électromagnétisme, conductivité terrestre, polarisation, et j'en passe...
Je sais pas si je suis clair. Ça se base sur des algorithmes qui existent déjà, et ce depuis longtemps, par exemple le populaire Longley-Rice / ITM.

On est pas tout à fait compute-bound. On est actuellement plutôt limités par l'occupancy, elle-même restreinte de par l'utilisation complètement aberrante des registres.
Pour illustrer on doit taper dans les 10-15% d'occupancy réelle sur les Titan X... On est en train d'investiguer sur le cas de l'algorithme en lui-même pour voir ce qu'on peut faire.
Derrière ça, ensuite oui on sera/serait compute-bound, c'est hyper lourd comme calcul et les cartes prennent relativement cher, sans compter que sur les Titan X la double-précision c'est vraiment pas ça...

Récemment on a chopé des 770 neuves sorties par magie sur TopAchat et RDC, pour la moitié du prix d'une seule Titan X avec deux 770 on a de meilleurs performances en double-précision.

[Møgluglu]

On est pas tout à fait compute-bound. On est actuellement plutôt limités par l'occupancy, elle-même restreinte de par l'utilisation complètement aberrante des registres.
Pour illustrer on doit taper dans les 10-15% d'occupancy réelle sur les Titan X... On est en train d'investiguer sur le cas de l'algorithme en lui-même pour voir ce qu'on peut faire.
Derrière ça, ensuite oui on sera/serait compute-bound, c'est hyper lourd comme calcul et les cartes prennent relativement cher, sans compter que sur les Titan X la double-précision c'est vraiment pas ça...

OK, donc tu as des formules immondes à évaluer pour chaque pixel avec plein de variables, sans aucun parallélisme qui te permettrait de distribuer le calcul et les données d'un pixel entre plusieurs threads.
Et ça ne marche qu'en double précision. Tu as regardé s'il y a des bouts qui pouvaient passer en simple ? Apparemment c'est plein de fonctions élémentaires genre puissance, log, exp et trigo vos trucs, en simple précision ça devrait poutrer avec les opérateurs hardware sur GPU.

[Taro]

OK, donc tu as des formules immondes à évaluer pour chaque pixel avec plein de variables, sans aucun parallélisme qui te permettrait de distribuer le calcul et les données d'un pixel entre plusieurs threads.
Et ça ne marche qu'en double précision. Tu as regardé s'il y a des bouts qui pouvaient passer en simple ? Apparemment c'est plein de fonctions élémentaires genre puissance, log, exp et trigo vos trucs, en simple précision ça devrait poutrer avec les opérateurs hardware sur GPU.

Une belle analyse que voilà.
Tu as pointé du doigt le truc important : et malheureusement oui.

En passant "tout" en SP on gagnait masse en temps de calcul total, sans même chercher à augmenter l'occupancy si possible.

Pour les mêmes paramètres on avait :

• 10 minutes sur CPU
• 1 minute 20 sur deux Titan X en DP
• 35 secondes sur deux Titan X en SP

Le problème étant alors les valeurs complètement erronées...
Après avoir joué à la pêche aux valeurs, bourré des printf dans des fichiers de 3000 lignes de code (projet Linux compilé par Makefile, sans commentaire, avec des copies/remplacements de fichiers dans tous les sens, sans IDE mais juste avec un éditeur de texte... et me voilà à débugger au printf... ), et couru après les valeurs erronées en SP pendant un mois environ, j'ai réussi à corriger toutes les valeurs aberrantes, parfois en laissant certaines parties en DP.

Malheureusement ces logs et ces exps s'enchaînent et s'imbriquent et l'on arrive à des variations de quelques points sur certaines des valeurs finales, par exemple -90 dB au lieu de -88 dB.
Seulement, 3 décibels de plus/moins c'est le double/moitié de niveau de signal perçu. Donc ça pète tout et il faudrait tomber sur les mêmes valeurs exactes à l'unité près après cast en entier.

On a fini par abandonner l'idée du float, donc.

Le boss a fini par arrêter de faire une fixette et m'écouter, quand je dis qu'on optimise d'abord la complexité de l'algo mathématique avant de vouloir optimiser le code source (voire le code généré) pour du hardware précis.
Donc en parallèle à mon propre travail, on est entrés en relation avec deux mecs calés qui pourraient nous aider à ré-écrire l'algo lui-même en prenant en considération qu'on va bosser sur GPU. Car oui à l'heure actuelle c'est du code C écrit il y a 20 ans et adapté il y a quelques années pour CUDA par le prédécesseur de mon prédécesseur dans la boite. C'est pas joli joli.

Tu vois un peu mon calvaire ?

[vectra]

Sinon, t'as vu qu'on peut récupérer des Tesla série M à pas très cher sur eBay?
Faut voir quelles générations sont disponibles, mais moi qui me contente d'une M2090 / C2075, j'ai pu trouver mon bonheur pour une centaine d'eurals.

[Taro]

Ah non, je ne savais pas. Merci pour l'info !

Le boss est un peu réfractaire à l'occasion, je le comprends quelque part, mais je vais zieuter et lui en parler.
On attend de voir si Nvidia va sortir une Titan Pascal qui dépote, ou à défaut s'en sort mieux que la misérable et détestable et méprisable Titan X, pour s'équiper sans avoir à mettre genre 10'000 $ dans un GP100 ou 129'000 $ dans le supercomputer de Nvidia qui en contient 8.

Actuellement c'est plus du debug au printf, j'ai profité d'un redesign complet du projet (peu après mon arrivée dans la boite) pour repartir sur une base saine avec un IDE (Visual Studio sous Windows), des commentaires (que j'écris) et un code bien structuré.

Je sens que je vais me plaire dans cette section Advanced

[Møgluglu]

Tu vois un peu mon calvaire ?

Tout à fait. Je suppose que le code C écrit il y a 20 ans est adapté littéralement d'un code Fortran écrit il y a 40 ans, et qu'on trouve des pow(x, 2.0) et des exp(y / constante) un peu partout dans le code ?

[Taro]

Tout à fait. Je suppose que le code C écrit il y a 20 ans est adapté littéralement d'un code Fortran écrit il y a 40 ans, et qu'on trouve des pow(x, 2.0) et des exp(y / constante) un peu partout dans le code ?

Hum, le coup des pow à l'exposant 2 je crois pas en avoir vu. Ça n'en est pas à ce point là, ça va plus vite d'écrire x * x
Mais sinon oui, c'est du vieux code adapté de vieux modèles par des mathématiciens probablement vieux ou disparus aujourd'hui, c'est assez vomitif.

En plus, du fait de la présence de plein de paramètres variés, on a du code décisionnel un peu partout dans ce processus de calcul d'une valeur pour chaque pixel (if, boucles for / while), ce pourquoi les GPUs ne sont clairement pas optimisés.
C'est tellement lourd qu'au final ça va quand même plus vite que sur CPU, mais bon, c'est quand même pas prévu pour ça à la base.
J'en ai déjà touché deux mots au patron, du peu que j'en sais il s'avère que d'une manière générale je vulgarise bien, ça fait que je n'ai pas trop de soucis pour expliquer ou illustrer quelque chose même à ceux qui ne sont pas des programmeurs de métier.

Bon, s'il fallait expliquer ça à mes parents qui ne font pas la nuance entre l'OS et la suite bureautique, je ne dis pas, mais au boulot je m'en sors

[Møgluglu]

En plus, du fait de la présence de plein de paramètres variés, on a du code décisionnel un peu partout dans ce processus de calcul d'une valeur pour chaque pixel (if, boucles for / while), ce pourquoi les GPUs ne sont clairement pas optimisés.

Là je m'inscris en faux. S'il y a un truc que les GPU font bien par rapport aux autres archis SIMD ou vectorielles, c'est bien les branchements dépendant des données. Va écrire le même code en SSE ou même en AVX 2 pour voir...
Si en plus tes données sont vaguement corrélées et que les threads voisins ont un comportement similaire, les if et boucles while peuvent te faire gagner beaucoup par rapport à tout calculer tout le temps.

[vectra]

Ah c'est bon à savoir.
Effectivement, en SIMD, on est obligé de passer par des masques d'une part, et d'évaluer les deux branches d'autre part, si j'ai bien compris. Ca transforme quand-même pas mal le code par rapport à la version C de base.

[Taro]

Je ne savais pas. Mais je ne sais pas si le comportement est similaire de thread à thread.

Bref y'a pas de honte après tout je suis venu sur cette section pour ça.

Donc du coup, y'a un moyen que tu m'en dises plus ? Ou que tu m'aiguilles vers un article qui explique un peu le concept ? Sachant que j'ai pas non plus un niveau fou fou en architecture.

[Møgluglu]

En SIMT, tu dois évaluer les deux branches aussi, mais seulement si la condition est partiellement vraie et partiellement fausse. Si tous les threads actifs suivent la même direction, c'est un branchement normal.

Après, on peut faire la même chose en software avec un jeu d'instruction SIMD explicite décent comme AVX 512 ou celui des GPU AMD GCN, et ça ne coûte pas plus cher.
En gros on convertit le code scalaire :

float x = ..., y = ..., z = ...;
bool cond = x < 2.f;
if(cond) {
  y = a;
}
else {
  z = b;
}

en code vectoriel, en considérant qu'un entier 32 bits c'est pareil qu'un vecteur de 32 booléens :

Vec32f X = ..., Y = ..., Z = ...; // Vecteurs de 32 floats
uint32_t Cond = CompareLess(X, Vec32f(2.f)); // Comparaison de vecteurs -> vecteur de 32 bits
if(Cond != 0xffffffff) {
  // Au moins un thread exécute la branche a
  Y = Select(Cond, A, Y); // Y[i] = Cond[i] ? A[i] : Y[i]
}
if(Cond != 0) {
  // Au moins un thread exécute la branche b
  Z = Select(~Cond, B, Z);
}

(Je pensais que c'était archi connu depuis les années 80, jusqu'à ce qu'un papier d'une conf d'archi majeure l'"invente" en 2014.)

[Taro]

C'est bon, ça y est vous m'avez perdu

[Taro]

De nouvelles infos, et notamment des estimations des dates (RC / Release) pour CUDA 8 :

http://www.hardware.fr/news/14594/gt...et-pascal.html

[vectra]

On a des nouvelles de la mémoire 3-D?

C'est prévu "un de ces 4" sur la roadmap de Nvidia, mais ça serait vraiment la killer-app paradigm-breaker tout ça.

[Taro]

Qu'entends-tu par "la mémoire 3D" ?

Si tu parles de gérer des tableaux à trois dimensions, pour ma part j'ai toujours opté pour un buffer linéaire (parce qu'après tout, c'est comme ça que c'est stocké en mémoire) et une linéarisation de l'index à partir des coordonnées.

J'ai horreur des tableaux à plusieurs dimensions et des pointeurs de pointeurs.

[Møgluglu]

Pascal P100, 16 Gio de HBM2 4096 bits à ~717 Go/s :
http://www.hardware.fr/news/14577/gt...lops-hbm2.html

Et le même genre de truc chez AMD et Intel.

[vectra]

Ca tape grave

Mais le NVlink, qui supprimerait les 16Go/s de bande passante unitaire en PCIe3 pour la porter à 10x plus environ, ça va être pour qui?
Intel va supporter ça sur ses CM orientées Xeon? Quelque part, va bien falloir qu'un CPU gère tout ça?

http://www.hardware.fr/news/14579/gt...rce-gp100.html

Ah ouais. Donc visiblement, on parle bien de serveurs propriétaires Nvidia.
Et la gamme de GPU dont on parle sera certainement une gamme propriétaire qui va coûter la peau du.
La mémoire 3D ne sera pas généralisée tout de suite, on aura visiblement de la GDDR5 sur les prochaines cartes de jeu Pascal.



Mais je pense que la mémoire 3-D ça serait encore plus "paradigm breaker" sur CPU. Quand on commence à dépasser les 100Go/s de BP sur une machine avec un seul CPU, ça met en perspective les achats complémentaires de Tesla ou de Xéfi.

- - - Mise à jour - - -

Qu'entends-tu par "la mémoire 3D" ?
J'ai horreur des tableaux à plusieurs dimensions et des pointeurs de pointeurs.

Oula non, jamais.
Toutes les libs que je connais implémentent les images 2-D, 3-D, par des tableaux 1-D en row-major order (OpenCV, VTK, FFTW).

Quand tu traites en flux, que t'as pas besoin de connaitre la valeur des coordonnées de la case où tu es, tu traites le volume comme un simple tableau.