2010-10-04 15 views
1

J'utilise Compute Prof 3.2 et une Geforce GTX 280. J'ai la capacité de calcul 1.3 alors je crois.Calculer les champs Prof pour incohérent et cohérent gst/gld? (CUDA/OpenCL)

This file, semble montrer que je devrais être capable de voir ces champs puisque j'utilise un périphérique de calcul 1.x. Eh bien, je ne les vois pas et le Guide de l'utilisateur pour 3.2 boîte à outils dit que je ne peux pas les voir, mais les appelle gst_uncoalesced et gst_coalesced. En résumé, je suis confus sur la façon dont je devrais comprendre à partir du profileur si je fais des lectures non coalesced de la mémoire globale. Il ne semble pas que les cartes Fermi disent non plus, mais je ne suis pas inquiet pour eux pour l'instant. Si quelqu'un peut élaborer sur la situation, je l'apprécierais.

En outre, on m'a dit de regarder l'assemblage de mes noyaux pour comprendre ce truc, donc toute élaboration sur comment faire ceci est appréciée aussi. Je commence juste à essayer de comprendre ce truc aussi :)

Répondre

1

J'ai eu des problèmes similaires avec la sortie de profilage. Alors que sur un 8600 (capacité de calcul 1.0), il affichait à la fois des lectures/écritures coalescées et non coalescées, il ne montrait qu'une fusion sur GTX280. J'ai supposé que c'était dû à la meilleure coalescence sur le gtx 280 rendant la coupure moins claire (est-ce une lecture de la mémoire pour laquelle tous les mots sauf un n'est pas nécessaire non coalisés?). Cependant, vous pouvez simplement regarder dans le tableau récapitulatif. Vous y trouverez une charge et une efficacité de stockage pour chaque noyau. Si tous les accès sont coalisés, cette efficacité doit être 1, sinon elle est inférieure à un (0,5 signifiant que seulement la moitié des octets chargés sont utilisés). Bien sûr, cela ne vous aide pas à déterminer exactement où se trouvent exactement vos accès non coalisés dans votre noyau, le meilleur moyen reste de savoir comment fonctionne la coalescence (les adresses de chaque demi-intervalle sont regroupées en accès de 32, 64 et 128 octets). , les valeurs non accessibles à l'intérieur de cette zone sont transférées de toute façon) et l'analyse de votre accesspatterns est toujours la voie à suivre à la fin.

+0

Merci pour la réponse. Je pense que vous devez avoir raison sur gld_efficiency et gst_efficiency. Je cherche encore des exemples concrets sur quel type de code CUDA ou OpenCL génère des lectures/écritures non coalescées. Idem pour les conflits bancaires. Les docs de Nvidia montrent de beaux diagrammes, mais pas le code qui les accompagnerait. Y a-t-il des exemples concrets? – smuggledPancakes

+0

@ user464095: Le Guide des meilleures pratiques de NVIDIA OpenCL contient quelques exemples (Matrixmultiply dans plusieurs variantes avec des performances de mémoire massivement différentes). Je posterais une partie de mon code avec le raisonnement correspondant, mais comme la plupart d'entre eux sont liés au travail, je ne peux pas le partager comme ça. Alors peut-être plus tard – Grizzly