›

OpenCL : idées pour le debugging

SethySethy Membre
dans Xcode et Developer Tools #1

Bonjour à  tous,


 


Je suis actuellement confronté à  quelques "bug" en OpenCL que je ne parviens pas à  résoudre. Je précise que je n'ai pas une énorme expérience en OpenCL, j'ai juste fait quelques programmes de calculs scientifiques.


 


Actuellement, j'ai un programme qui fonctionne parfaitement bien tant que je reste sur le CPU, mais lorsque j'essaie de le faire tourner sur le GPU, je reçois des erreurs étranges.


 


J'ai essayé de débugger (pour se faire une idée, le printf ne donne rien quand on tourne sur GPU, sans compter la disparition de free et de son coupaing malloc). Malgré cela, j'ai pu écrire un code viable sur CPU mais autant je peux isoler la ligne de code qui fait crasher le code en GPU, autant je suis sûr que cette pauvre ligne n'y est pour rien.


 


Quelqu'un a-t-il une piste à  exploiter ?


 


Merci,


 


Sethy


Réponses

  • klogklog Membre
    #2


    Bonjour à  tous,


     


    Je suis actuellement confronté à  quelques "bug" en OpenCL que je ne parviens pas à  résoudre. Je précise que je n'ai pas une énorme expérience en OpenCL, j'ai juste fait quelques programmes de calculs scientifiques.


     


    Actuellement, j'ai un programme qui fonctionne parfaitement bien tant que je reste sur le CPU, mais lorsque j'essaie de le faire tourner sur le GPU, je reçois des erreurs étranges.


     


    J'ai essayé de débugger (pour se faire une idée, le printf ne donne rien quand on tourne sur GPU, sans compter la disparition de free et de son coupaing malloc). Malgré cela, j'ai pu écrire un code viable sur CPU mais autant je peux isoler la ligne de code qui fait crasher le code en GPU, autant je suis sûr que cette pauvre ligne n'y est pour rien.


     


    Quelqu'un a-t-il une piste à  exploiter ?


     


    Merci,


     


    Sethy




     


    Quel est ton GPU ? AMD ? Nvidia ? Intel ?


     


    Le printf fonctionne sur GPU, mais il faut restreindre le domaine d'application de tes kernels.


    En général, je diminue considérablement la taille de mes buffers (souvent réduit à  un seul élément)... On est obligé de tâtonner un peu pour cibler le bon index en entrée...


     


    La deuxième option, un peu couteuse en temps de dev mais malheureusement souvent indispensable, c'est d'utiliser des buffers supplémentaires pour stocker des résultats intermédiaires et de les "exporter" sur le CPU. Pour ce faire, il n'est pas inutile d'encapsuler les buffers OpenCL dans une petite classe C++ ou Objective-C afin de lui adjoindre des fonctions souvent utilisées : la copie dans un buffer temporaire afin de débugger et autres joyeusetés.


     


    Bon courage... OpenCL n'est pas très stable sur Mac :(


     


    J'ai souvent atteint les limites de ce qu'un kernel est en mesure d'accepter sur les procs AMD... Le problème c'est que cela se fait en silence, et qu'il est initialement impossible de dire si c'est de notre faute ou de la faute des drivers.

  • SethySethy Membre
    juillet 2015 modifié #3

    Merci beaucoup pour ces informations.


     


    Si j'ai tardé à  répondre, c'est que j'essayais encore de débugger par moi-même, mais quand j'avance dans les itérations, je me rends compte que même en mode CPU, j'ai des problèmes. J'essaye de manipuler des longues chaines de caractères (de longueur variable) et ça coince.


     


    Je vais repartir sur une base plus classique où je dispose des mallocs et autre strlen et strcpy.


     


    Edit :


     


    Je réponds quand même aux questions. J'ai une Geforce GTX 970 installée dans un Hackintosh.


  • klogklog Membre
    #4


    Merci beaucoup pour ces informations.


     


    Si j'ai tardé à  répondre, c'est que j'essayais encore de débugger par moi-même, mais quand j'avance dans les itérations, je me rends compte que même en mode CPU, j'ai des problèmes. J'essaye de manipuler des longues chaines de caractères (de longueur variable) et ça coince.


     


    Je vais repartir sur une base plus classique où je dispose des mallocs et autre strlen et strcpy.


     


    Edit :


     


    Je réponds quand même aux questions. J'ai une Geforce GTX 970 installée dans un Hackintosh.




     


    Je ne sais pas ce que tu appelles "en mode CPU", mais en supposant qu'il s'agisse du device CPU, notes bien que la taille maximale d'un workgroup est 1 ! Du coup, tous les algorithmes classiques de scans, tris, réductions sont inutilisables sur le device CPU.


     


    Il est donc nécessaire de disposer (pour ce type d'algorithmes) d'un code différent pour le device CPU... Et on perd pratiquement tout l'intérêt du support CPU d'OpenCL...

  • SethySethy Membre
    #5

    En fait, je teste des candidats par lots (actuellement 750.000). Les longueurs des chaines sont variables, mais l'algorithme est toujours le même.



    
kernel void explore(
    
__global unsigned int* oTarget,
    
__global char* iBase,
    
unsigned int d0, // strlen(Base)
    
unsigned int n2,
    
unsigned int n3,
    
unsigned int n7,
    
const unsigned int count)
    
{

    C'est quand j'appelle ce genre de routine que les problèmes surviennent :



    
unsigned int multiply_cc (__constant char *operande, unsigned int olength, __constant char *multiplier, unsigned int mlength, char *product)
    
{
    
int table[10][mlength+1];
    
int report;
    
int abaque[olength+1][olength+mlength];
    

    
for (int j = 0; j < 10; j++)
    
{
    
table[j][0] = 0;
    
}
  • DrakenDraken Membre
    #6


    J'ai une Geforce GTX 970 installée dans un Hackintosh.  >:)



Connectez-vous ou Inscrivez-vous pour répondre.