2012-09-12 15 views
14

Próbuję zrozumieć użycie zasobów dla każdego z moich wątków CUDA dla ręcznie pisanego jądra.Interpretowanie danych wyjściowych --ptxas-options = -v

Skompilowałem mój plik kernel.cu do pliku kernel.o z nvcc -arch=sm_20 -ptxas-options=-v

i mam następujący wynik

ptxas info : Compiling entry function '_Z12searchkernel6octreePidiPdS1_S1_' for 'sm_20' 
ptxas info : Function properties for _Z12searchkernel6octreePidiPdS1_S1_ 
    72 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads 
ptxas info : Used 46 registers, 176 bytes cmem[0], 16 bytes cmem[14] 

Patrząc na wyjściu powyżej, jest to prawdą, że

  • każdy wątek CUDA używa 46 rejestrów?
  • nie ma rejestru przechodzenia na lokalną pamięć?

Mam również pewne problemy ze zrozumieniem wyników.

  • Moje jądro wywołuje wiele funkcji __device__. IS 72 bajty suma całkowita pamięci dla ramek stosów funkcji __global__ i __device__?

  • Jaka jest różnica między 0 byte spill stores i 0 bytes spill loads

  • Dlaczego informacji cmem (co zakładam jest stała pamięć) powtarzające się dwa razy z różnymi postaciami? W jądrze nie używam żadnej stałej pamięci . Czy to oznacza, że ​​kompilator jest, pod maską, czy powie firmie GPU, aby używał jakiejś stałej pamięci?

+0

„używane 46 rejestry” oznacza, że ​​kompilator zastrzeżone rejestrów 46 na gwint do sporządzonej jądro i inne rejestry rozlania. Liczbę rozlanych rejestrów można znaleźć, odejmując tę ​​liczbę (46) od całkowitej liczby rejestrów używanych w PTX kernela. – ahmad

+2

@Ahmad: Pierwsze zdanie jest poprawne, ale drugie nie. Jądro może używać mniej niż maksymalne dopuszczalne rejestry na wątek i nie ma rozlania na pamięć lokalną. – talonmies

+1

Aby rozwinąć odpowiedź w sprawie talii, PTX jest abstrakcją wysokiego poziomu z nieskończonymi rejestrami. Dzieje się tak dlatego, że można go skompilować na wiele generacji procesorów graficznych, a liczba rejestrów może być różna. Dopiero po kompilacji do kodu specyficznego dla maszyny można naprawdę spojrzeć na użycie rejestru. W każdym razie ptxas (kompilując PTX do kodu specyficznego dla maszyny) informuje o ilości wycieków. Kompilator – Tom

Odpowiedz

13
  • Każda nić CUDA użyciu 46 rejestrów? Tak, poprawne
  • Nie ma rejestru rozlewania się na pamięć lokalną? Tak, zgadza
  • wynosi 72 bajtów suma-całkowite pamięci dla ramek stos funkcji __global__ i __device__? Tak, poprawne
  • Jaka jest różnica między 0-bajtowymi sklepami rozlewowymi i 0 bajtami rozlanych ładunków?
    • Uczciwe pytanie, obciążenia mogą być większe niż sklepy, ponieważ można wylać wyliczoną wartość, załadować ją raz, odrzucić (to znaczy przechowywać coś innego w tym rejestrze), a następnie załadować ponownie (to znaczy ponownie użyć). Aktualizacja: Zauważ też, że liczba wyciek obciążenia/sklep jest na podstawie analizy statycznej, jak opisano przez @njuffa w komentarzach poniżej
  • Dlaczego jest informacja dla CMEM (co zakładam jest stała pamięć) powtórzono dwukrotnie z różnymi liczbami? W jądrze nie używam żadnej stałej pamięci. Czy to oznacza, że ​​kompilator będzie pod maską informował GPU o używaniu stałej pamięci?
    • Stała pamięć służy do kilku celów, w tym __constant__ zmiennych i argumentów jądra, różne „banki” są stosowane, to zaczyna się trochę szczegółowe, ale tak długo jak używasz mniej niż 64KB dla __constant__ zmiennych i mniej niż 4KB dla argumentów jądra będziesz w porządku.
+2

Pamiętaj, że obciążenia i magazyny rozlania są liczone statycznie, tj. Liczba instrukcji lokalnego obciążenia i magazynu lokalnego pomnożona przez szerokość dostęp do każdego ładunku/sklepu. Są one znormalizowane do bajtów, ponieważ kompilator może być w stanie wektoryzować obciążenia/zapisy wycieków, jeśli ma wystarczającą ilość informacji o wyrównaniu i umożliwia to alokacja rejestru. Ponieważ liczby są statyczne, nie jest to bezpośrednio miarą natężenia ruchu w przypadku wycieków, ponieważ wycieki/wypełnienia mogą znajdować się wewnątrz pętli. Obciążenia rozładowaniem mogą przekroczyć wyprzedaże, jeśli nastąpi ponowne wykorzystanie rozlanych danych. Oznaczałoby to, że bajty obciążenia rozładowaniem> = rozlewają bajty magazynu. – njuffa

+2

Dzięki @njuffa - doskonałe punkty. Kompilator nie może znać liczników wyzwalaczy dla pętli (chyba że stała czasu kompilacji). Najlepszym sposobem na realną analizę kosztów wycieku/wypełnienia jest użycie profilera takiego jak Nsight (lub samodzielny NVVP), który da ci dane oparte na wykonaniu, a nie na kompilacji. – Tom

+0

Uzgodniono w odniesieniu do profilowania. Statystyki wycieku kompilatora są umiarkowanie przydatne jako wskaźniki pierwszego rzutu. Jeśli nie ma rozlewania, nie ma się czym martwić. Jeśli liczby są małe (na przykład <32 bajty), pamięć podręczna L1 powinna zająć się nimi bez wpływu na wydajność (pamiętaj, że liczby są dla jednego wątku, ponieważ dla wycieków używana jest pamięć lokalna wątku). Jeśli liczby są w tysiącach, prawdopodobny jest negatywny wpływ na wyniki i może to być czas na bardziej szczegółową analizę. – njuffa

Powiązane problemy