Comment quantifier les compromis de traitement des périphériques CUDA pour les kernelx C?

Pas exactement une réponse à votre question, mais quelques informations qui pourraient aider à comprendre les performances du GK104 (Kepler, GTX680) par rapport au GF110 (Fermi, GTX580):

Sur Fermi, les cœurs sont deux fois plus fréquents que le rest de la logique. Sur Kepler, ils fonctionnent à la même fréquence. Cela réduit de moitié le nombre de kernelx sur Kepler si l’on veut comparer plus de pommes à Fermi. Donc, il rest le GK104 (Kepler) avec 1536/2 = 768 “kernelx équivalents de Fermi”, ce qui ne représente que 50% de plus que les 512 cœurs du GF110 (Fermi).

En regardant les comptages des transistors, le GF110 possède 3 milliards de transistors alors que le GK104 en a 3,5 milliards. Ainsi, même si le Kepler a 3 fois plus de cœurs, il ne comporte qu’un peu plus de transistors. Donc, non seulement le Kepler a seulement 50% plus de “kernelx équivalents à Fermi” que Fermi, mais chacun de ces kernelx doit être beaucoup plus simple que ceux de Fermi.

Donc, ces deux problèmes expliquent probablement pourquoi beaucoup de projets voient un ralentissement lors du portage vers Kepler.

De plus, le GK104, étant une version de Kepler conçue pour les cartes graphiques, a été réglé de manière à ce que la coopération entre les threads soit plus lente que sur Fermi (car cette coopération n’est pas aussi importante pour les graphiques). Tout gain potentiel de performance potentiel, après avoir pris en compte les faits ci-dessus, peut être annulé par ceci.

Il y a aussi le problème des performances en virgule flottante à double précision. La version de GF110 utilisée dans les cartes Tesla peut effectuer une virgule flottante double précision à la moitié des performances de précision simple. Lorsque la puce est utilisée dans les cartes graphiques, les performances en double précision sont limitées artificiellement à 1/8 des performances en simple précision, mais cela rest bien supérieur aux performances en double précision de 1/24 du GK104.

L’une des avancées de la nouvelle architecture Kepler est constituée de 1536 cœurs regroupés en 8 SMX à 192 cœurs, mais en même temps, ce nombre de cœurs est un gros problème. Parce que la mémoire partagée est toujours limitée à 48 Ko. Donc, si votre application nécessite beaucoup de ressources SMX, vous ne pouvez pas exécuter 4 warps en parallèle sur un seul SMX. Vous pouvez profiler votre code pour trouver une occupation réelle de votre GPU. Les moyens possibles pour améliorer votre application:

1. utiliser les fonctions de vote en chaîne au lieu des communications en mémoire partagée;
2. augmenter le nombre de blocs de la bande de roulement et diminuer le nombre de threads dans un bloc;
3. optimiser les charges / magasins globaux. Kepler a 32 modules de chargement / stockage pour chaque SMX (deux fois plus que sur Kepler).

J’installe nvieuw et j’utilise coolbits 2.0 pour déverrouiller vos cœurs de shader par défaut pour des performances maximales. De plus, vous devez disposer des deux connecteurs de votre appareil sur un seul écran, qui peut être activé sur les écrans 1/2 et 2/2 du panneau de configuration nVidia. Maintenant, vous devez cloner cet écran avec l’autre, et la résolution Windows définit le mode écran sur le bureau étendu.

Avec nVidia inspector 1.9 (pilotes de niveau BIOS), vous pouvez activer ce mode en configurant un profil pour l’application (vous devez append le fichier exe de l’application au profil). Maintenant, vous avez presque deux fois plus de performance (surveillez la température).

DX11 comporte également une tesselation, de sorte que vous souhaitez remplacer cela et adapter votre résolution native. Votre résolution native peut être obtenue en effectuant un rendu inférieur à 960-540P et en laissant le rest aux pipelines 3D pour évoluer jusqu’à la résolution HD complète (en taille et position du bureau du panneau de contrôle nv). Maintenant, redimensionnez la résolution inférieure en plein écran avec l’affichage, et vous obtenez un rendu Full HD avec le double du rendu de la taille de la texture à la volée et tout devrait bien restituer des textures 3D avec un biais LOD extrême (niveau de détail). Votre affichage doit être sur zoom automatique!

En outre, vous pouvez battre les ordinateurs de configuration sli. De cette façon, j’obtiens des scores plus élevés que les sli à 3 voies dans tessmark. Les réglages AA élevés, tels que les échantillons mixtes 32X, font en sorte que le format HD est de qualité AAA (dans les modèles tessmark et Heavon). Il n’y a pas de paramètre de résolution dans le résultat final, cela montre qu’il n’est pas important que vous rendiez votre résolution native!

Cela devrait vous donner de vrais résultats, alors s’il vous plaît lisez attentivement, pas littéraire.

Je pense que le problème réside peut-être dans le nombre de multiprocesseurs en streaming : le GTX 480 a 15 SM, le GTX 680 seulement 8.

Le nombre de SM est important, car au maximum des blocs 8/16 ou 1536/2048 (capacité de calcul 2.0 / 3.0) peuvent résider sur un seul SM. Les ressources qu’ils partagent, par exemple la mémoire partagée et les registres, peuvent limiter davantage le nombre de blocs par SM. De plus, le nombre plus élevé de cœurs par SM sur la GTX 680 ne peut raisonnablement être exploité qu’en utilisant le parallélisme au niveau des instructions , c’est-à-dire en pipelant plusieurs opérations indépendantes.

Pour connaître le nombre de blocs pouvant être exécutés simultanément par SM, vous pouvez utiliser la feuille de calcul CUDA Occupancy Calculator de nVidia. Pour voir la quantité de mémoire partagée et les registres requirejs par votre kernel, ajoutez -Xptxas –v à la ligne de commande nvcc lors de la compilation.