[HFR] Actu : GTC: Tesla P100: débits PCIe et NVLink mesurés

Actu : GTC: Tesla P100: débits PCIe et NVLink mesurés [HFR] - HFR - Hardware

Marsh Posté le 08-04-2016 à 14:37:56   0  

Lors d'une session de la GTC consacrée à GPUDirect, qui regroupe les techniques de communications entre GPU et avec d'autres éléments d'un système, nous avons ...
Lire la suite ...

Reply

Marsh Posté le 08-04-2016 à 14:37:56   

Reply

Marsh Posté le 08-04-2016 à 14:50:16   0  

moteurs de copies?

Reply

Marsh Posté le 08-04-2016 à 15:06:43   0  

fredo3 a écrit :

moteurs de copies?


Cela me fait penser à un équivalent du CPPI/packetDMA (Multicore Navigator) que l'on utilise dans les puces TI.
Cela permet de faire des copies d'un accélérateur à un autre sans faire intervenir le processeur.


Message édité par Nono0000 le 08-04-2016 à 15:09:42
Reply

Marsh Posté le 08-04-2016 à 15:10:37   3  

C'est cela. Les GPUs ont des unités qui se chargent de copier les données entre le host et le GPU (dans les deux sens) ou directement entre plusieurs GPU. Elles fonctionnent indépendamment du reste du GPU. Ces unités sont les copy engines. Le fonctionnement permet de faire des copies en parallèle du calcul. Elles sont aussi capables de faire des réorganisations de mémoire à la volée.

Reply

Marsh Posté le 08-04-2016 à 15:38:11   0  

jdemouth a écrit :

Ces unités sont les copy engines.


 
Les mêmes que ces copy engines qu'on cherche à faire travailler en parallèle aux autres tâches en Vulkan / DirectX 12 ?

Reply

Marsh Posté le 08-04-2016 à 15:52:35   2  

Oui c'est le même principe mais pour l'appliquer à NVLink il a fallu multiplier les copy engines du GPU et probablement leur ajouter quelques fonctionnalités supplémentaires.

Reply

Marsh Posté le 08-04-2016 à 15:56:41   0  

Info très importante, alors. Merci pour la réponse. :)

Reply

Marsh Posté le 08-04-2016 à 16:07:01   0  

Quid de la latence ?  
Si on doit tranférer des données avec une fréquence de synchronisation très élevés, c'est une info intéréssante  

Reply

Marsh Posté le 09-04-2016 à 09:33:26   0  

la latence c'est simple, tu multiplies le débit par la taille du packet, tu ajoutes 30%, et tu as une estimation de première approche.
 
Mais effectivement, pour des petits packets la latence n'est pas le fort. Les GPU sont adapté pour traiter des quantités de données massives.
 
Ce qui est dommage c'est qu'il n'y a pas de compression hardware dans le moteurs de copy ...


Message édité par barbare128 le 09-04-2016 à 09:34:11
Reply

Marsh Posté le 10-04-2016 à 03:41:11   0  

barbare128 a écrit :

la latence c'est simple, tu multiplies le débit par la taille du packet, tu ajoutes 30%, et tu as une estimation de première approche.
 
Mais effectivement, pour des petits packets la latence n'est pas le fort. Les GPU sont adapté pour traiter des quantités de données massives.
 
Ce qui est dommage c'est qu'il n'y a pas de compression hardware dans le moteurs de copy ...

La compression ajouterait qûrement une latence suppl3mentaire. Ainsi qu'un temps supplémentaire de traitement en bout de course.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed