API du pilote CUDA vs. Runtime CUDA

Question

Lors de l'écriture d'applications CUDA, vous pouvez travailler soit au niveau du pilote, soit au niveau de l'exécution, comme illustré sur cette image (les bibliothèques sont CUFFT et CUBLAS pour les mathématiques avancées):

_{(source: tomshw.it )}

Je suppose que le compromis entre les deux est une amélioration des performances de l'API low-evel, mais au prix d'une complexité accrue du code. Quelles sont les différences concrètes et y a-t-il des choses importantes que vous ne pouvez pas faire avec l'API de haut niveau?

J'utilise CUDA.net pour l'interopérabilité avec C #. Il est conçu comme une copie de l'API du pilote. Cela encourage à écrire beaucoup de code assez complexe en C # alors que l'équivalent C ++ serait plus simple en utilisant l'API d'exécution. Y at-il quelque chose à gagner en le faisant de cette façon? L’un des avantages que je constate est qu’il est plus facile d’intégrer la gestion intelligente des erreurs au reste du code C #.

Answer 1

Le runtime CUDA permet de compiler et de lier vos noyaux CUDA en exécutables. Cela signifie que vous n'avez pas besoin de distribuer des fichiers cubin avec votre application, ni de les charger via l'API du pilote. Comme vous l'avez noté, il est généralement plus facile à utiliser.

En revanche, l’API du pilote est plus difficile à programmer, mais elle permet de mieux contrôler la façon dont CUDA est utilisé. Le programmeur doit s'occuper directement de l'initialisation, du chargement du module, etc.

Il est possible d’interroger des informations plus détaillées sur le périphérique via l’API du pilote que via l’API d’exécution. Par exemple, la mémoire disponible disponible sur le périphérique ne peut être interrogée que via l'API du pilote.

Extrait du Guide du programmeur CUDA:

  

Il est composé de deux API:

     

  
• Une API de bas niveau appelée API de pilote CUDA,
  
• Une API de niveau supérieur appelée API d'exécution CUDA implémentée au-dessus de   l'API du pilote CUDA.
  

     

Ces API s’excluent mutuellement: une application doit utiliser l’un ou l’autre   autre.

     

Le moteur d’exécution CUDA facilite la gestion du code de l’appareil en fournissant des   initialisation, gestion de contexte et gestion de module. Le code de l'hôte C   généré par nvcc est basé sur le runtime CUDA (voir Section 4.2.5), donc   Les applications liées à ce code doivent utiliser l'API d'exécution CUDA.

     

En revanche, l’API du pilote CUDA nécessite plus de code, est plus difficile à programmer et   débogage, mais offre un meilleur niveau de contrôle et est indépendant de la langue puisqu’il   traite des objets cubin (voir Section 4.2.5). En particulier, il est plus difficile de   configurer et lancer les noyaux à l’aide de l’API du pilote CUDA, depuis l’exécution   les paramètres de configuration et du noyau doivent être spécifiés avec des appels de fonction explicites   au lieu de la syntaxe de configuration d'exécution décrite à la Section 4.2.3. En outre, l'appareil   L’émulation (voir section 4.5.2.9) ne fonctionne pas avec l’API du pilote CUDA.

Il n'y a pas de différence de performances notable entre les API. La manière dont vos noyaux utilisent la mémoire et leur disposition sur le GPU (en chaînes et en blocs) aura un effet beaucoup plus prononcé.

Answer 2

J'ai constaté que pour le déploiement de bibliothèques dans des applications multithreads, le contrôle du contexte CUDA fourni par l'API du pilote était essentiel. La plupart de mes clients souhaitent intégrer l'accélération GPU dans les applications existantes. De nos jours, presque toutes les applications sont multi-threadées. Étant donné que je ne pouvais pas garantir que tout le code GPU serait initialisé, exécuté et désalloué à partir du même thread, je devais utiliser l'API du pilote.

Mes tentatives initiales avec diverses solutions de contournement dans l’API d’exécution ont toutes conduit à des échecs, parfois spectaculaires - j’ai constaté que je pouvais redémarrer plusieurs fois instantanément une machine en effectuant le mauvais ensemble d’appels CUDA à partir de threads différents.

Depuis que nous avons tout migré via l'API du pilote, tout va bien.

J

Answer 3

quelques points importants à noter:

d’abord, les différences entre les API s’appliquent uniquement au code côté hôte. Les noyaux sont exactement les mêmes. Du côté de l'hôte, la complexité de l'API des pilotes est assez triviale, les différences fondamentales sont les suivantes:

dans l’API du pilote, vous avez accès à des fonctionnalités qui ne sont pas disponibles dans l’API d’exécution, comme les contextes.

l'émulateur ne fonctionne qu'avec le code écrit pour l'API d'exécution.

oh et actuellement cudpp qui est une bibliothèque très pratique ne fonctionne qu'avec l’API d’exécution.

Answer 4

Il existe de vrais problèmes avec l'alignement des arguments et l'API du pilote. Consultez la documentation bêta de CUDA 2.2 (ou une version ultérieure) pour plus d'informations.