CUDA: copie de la mémoire au GPU 1 est plus lent en multi-GPU

Question

Mon entreprise a une configuration de deux GTX 295, donc un total de 4 processeurs graphiques dans un serveur, et nous avons plusieurs serveurs. Nous GPU 1 spécifiquement était lent, par rapport au GPU 0, 2 et 3 donc j'écrit un petit test de vitesse pour aider à trouver la cause du problème.

//#include <stdio.h>
//#include <stdlib.h>
//#include <cuda_runtime.h>
#include <iostream>
#include <fstream>
#include <sstream>
#include <string>
#include <cutil.h>

__global__ void test_kernel(float *d_data) {
    int tid = blockDim.x*blockIdx.x + threadIdx.x;
    for (int i=0;i<10000;++i) {
        d_data[tid] = float(i*2.2);
        d_data[tid] += 3.3;
    }
}

int main(int argc, char* argv[])
{

    int deviceCount;                                                         
    cudaGetDeviceCount(&deviceCount);
    int device = 0; //SELECT GPU HERE
    cudaSetDevice(device);


    cudaEvent_t start, stop;
    unsigned int num_vals = 200000000;
    float *h_data = new float[num_vals];
    for (int i=0;i<num_vals;++i) {
        h_data[i] = float(i);
    }

    float *d_data = NULL;
    float malloc_timer;
    cudaEventCreate(&start);
    cudaEventCreate(&stop); cudaEventRecord( start, 0 );
    cudaMemcpy(d_data, h_data, sizeof(float)*num_vals,cudaMemcpyHostToDevice);
    cudaMalloc((void**)&d_data, sizeof(float)*num_vals);
    cudaEventRecord( stop, 0 ); cudaEventSynchronize( stop ); cudaEventElapsedTime( &malloc_timer, start, stop );
    cudaEventDestroy( start );
    cudaEventDestroy( stop );


    float mem_timer;
    cudaEventCreate(&start);
    cudaEventCreate(&stop); cudaEventRecord( start, 0 );
    cudaMemcpy(d_data, h_data, sizeof(float)*num_vals,cudaMemcpyHostToDevice);
    cudaEventRecord( stop, 0 ); cudaEventSynchronize( stop ); cudaEventElapsedTime( &mem_timer, start, stop );
    cudaEventDestroy( start );
    cudaEventDestroy( stop );

    float kernel_timer;
    cudaEventCreate(&start);
    cudaEventCreate(&stop); cudaEventRecord( start, 0 );
    test_kernel<<<1000,256>>>(d_data);
    cudaEventRecord( stop, 0 ); cudaEventSynchronize( stop ); cudaEventElapsedTime( &kernel_timer, start, stop );
    cudaEventDestroy( start );
    cudaEventDestroy( stop );

    printf("cudaMalloc took %f ms\n",malloc_timer);
    printf("Copy to the GPU took %f ms\n",mem_timer);
    printf("Test Kernel took %f ms\n",kernel_timer);

    cudaMemcpy(h_data,d_data, sizeof(float)*num_vals,cudaMemcpyDeviceToHost);

    delete[] h_data;
    return 0;
}

Les résultats sont

GPU0 cudaMalloc a pris 0.908640 ms Copie au GPU a pris 296.058777 ms Test du noyau a 326.721283 ms

GPU1 cudaMalloc a pris 0.913568 ms Copie au GPU a pris 663.182251 ms Test du noyau a 326.710785 ms

GPU2 cudaMalloc a pris 0.925600 ms Copie au GPU a pris 296.915039 ms Test du noyau a 327.127930 ms

GPU3 cudaMalloc a pris 0.920416 ms Copie au GPU a pris 296.968384 ms Test du noyau a 327.038696 ms

Comme vous pouvez le voir, le cudaMemcpy au GPU est bien le double de la quantité de temps pour GPU1. Ceci est cohérent entre tous nos serveurs, il est toujours GPU1 qui est lent. Toutes les idées pourquoi cela peut être? Tous les serveurs sont Windows XP en.

Answer 1

Ce fut un problème de pilote. Mise à jour de la dernière version du pilote qu'il fixe

Answer 2

Cela peut être un problème avec votre bus pci, essayez d'échanger les cartes dans les différents emplacements pour voir si le problème persiste. Si cela est un problème, copiez toutes vos données sur la GTX295 via la fente plus rapide et utiliser le dessus sli le copier sur l'autre (bus pci lent) gpu.

Answer 3

Si vous pouvez utilisé la GDDR de carte vidéo plus rapide à charger, vous pouvez faire un dispositif de dispositif tansfer à beaucoup de bande passante plus élevée, qui pourrait aider à éliminer la question aussi. En outre, vérifiez votre bande passante avec le test de bande passante de NVidia pour obtenir des résultats physiques et test.

Bonne chance!

Answer 4

Êtes-vous en cours d'exécution dans une configuration bi-processeur? Il y a un bogue dans les jeux de puces Tylersburg actuelles, telles que la bande passante du chemin de x86 (0) à GPU (1) est plus lent que le trajet direct à partir de 86 (0) à GPU (0). Intel devrait sortir une nouvelle version pour corriger ce bug. Essayez le verrouillage de votre processus de test à une unité centrale de traitement spécifique en utilisant taskset et voir quels sont les résultats que vous obtenez.

concerne Mark