Ilość bloków/wątków oraz pamięć lokalna w CUDA

Ja interesuję się OpenCL i Radeonami, ale może coś przydatnego napiszę.

Z tego co gdzieś doczytałem najoptymalniej tworzyć wielokrotność 32 wątków w każdym bloku (Warp).
Mając jednak 640 rdzeni wydaje mi się, że najlepiej tworzyć 640 bloków.
Innymi słowy, jeśli ilość obliczeń na to pozwala, najlepiej tworzyć 640 bloków po 32 wątki (lub ew. ich wielokrotność) (?).

GPU składa się z wielu SIMDów i jeden blok jest odpalany na jednym SIMDzie (u AMD to Compute Unit/ CU, u nVidii to chyba SMX, SMM, czy jakoś tak). Każdy SIMD ma swoją pamięć lokalną i jeden SIMD nie może odwoływać się do pamięci lokalnej innego SIMDa. SIMDy nie są zsynchronizowane, tzn mogą wykonywać inne instrukcje w danym momencie (ale czy z innych kerneli to inna sprawa, zależy od konkretnej wersji GPU).

Innymi słowy, jeśli ilość obliczeń na to pozwala, najlepiej tworzyć 640 bloków po 32 wątki (lub ew. ich wielokrotność) (?).
Pomijam tutaj kwestię pamięci współdzielonej wspólnej tylko dla wątków w danym bloku.

Przy okazji pytanie: czy jest sens tworzyć więcej bloków niż posiada się rdzeni na karcie? Czy nie lepiej zrobić pętlę wewnątrz funkcji urządzenia, by wykorzystywać maksymalną ilość bloków a jednocześnie nie wymuszać na karcie, by to ona organizowała które rdzenie i kiedy mają pracować?

Blok a wątek to inna sprawa. Trochę mi się wydaje, że mieszasz te pojęcia. Zdecydowanie opłaca się odpalać wielokrotnie więcej wątków niż jest fizycznie potoków obliczeniowych na karcie, GPGPU są wręcz do tego stworzone. Jest tak dlatego, że GPU bardzo szybko przełączają się między wątkami, a jednocześnie inny zestaw wątków jest niezależny od obecnego, więc takie przełączanie między wątkami maskuje opóźnienia instrukcji i to bez trików typu out-of-order execution.

Mam jednak dylemat jak interpretować pamięć lokalną, gdyż każdy wątek może dysponować aż (/tylko) 512 KB. Zakładając jednak, że zrobię tak, jak napisałem wcześniej tj. utworzę 640 bloków a każdy blok składać się będzie z 32 wątków to wychodzi mi, że będę mógł korzystać z: 512 KB x 640 x 32 ~10GB(?!?) pamięci. Mam więc pytanie: skąd jest ta pamięć (czy rezerwując taką pamięć ograniczam sobie pamięć globalną?). Jak należy to interpretować?
Co jeśli na karcie mam tylko 2 GB pamięci a będę wykorzystywał np. 5GB biorąc pod uwagę powyższe obliczenia?

Wątpię by jakiś wątek miał dostęp do 512 KiB pamięci lokalnej. Na mój gust cała pamięć lokalna na GPU ma rozmiar 512 KiB i jest równo podzielona pomiędzy SIMDy.
Edit: Hmm, chyba pomyliłem lokalną z współdzieloną. W OpenCL jest lokalna pamięć współdzielona dla danego SIMDa. O tym myślałem.

Jeśli chcesz efektywnie wykorzystać wszystkie potoki na GPGPU, to pojedynczy wątek musi mieć co najwyżej kilka kilobajtów pamięci prywatnej (czyli rejestrów w pamięci SRAM na czipie; najlepiej poniżej kilobajta) i wykonywać względnie mało odwołań do pamięci globalnej, no chyba że dane "dobrze się keszują", tzn w rzeczywistości GPU rzadko sięga do VRAMu.

Temat jest złożony i myślę, że najlepiej ogarnąć go metodą prób i błędów. Sam wgryzam się w OpenCL i Radeony (ponownie, bo kiedyś już próbowałem, ale to była stara generacja) i jakoś nie widzę żebym miał to ogarnąć przez samo czytanie i rozmyślanie.

@Wibowit dzięki za szybką odpowiedź ;-)

Wibowit napisał(a):

Blok a wątek to inna sprawa. Trochę mi się wydaje, że mieszasz te pojęcia. Zdecydowanie opłaca się odpalać wielokrotnie więcej wątków niż jest fizycznie potoków obliczeniowych na karcie, GPGPU są wręcz do tego stworzone. Jest tak dlatego, że GPU bardzo szybko przełączają się między wątkami, a jednocześnie inny zestaw wątków jest niezależny od obecnego, więc takie przełączanie między wątkami maskuje opóźnienia instrukcji i to bez trików typu out-of-order execution.

Nie, nie chodziło mi o wątki tylko o bloki, które zdaje się odpowiadają właśnie SIMD/rdzeniu/multiprocesory (? - nie jestem pewny).
Z wątkami to masz rację, że dobrze tworzyć ich więcej - gdzieś przeczytałem, że optymalnie jest tworzyć 32 wątki w każdym bloku, bo tyle jest w warpie. Do tego każdy wątek w bloku ma dostęp do szybkiej pamięci wspólnej.
Natomiast, jeśli się nie mylę, i 1 blok reprezentuje jeden multiprocesor lub coś w tym stylu, a oczywistym jest, że nie może pracować równocześnie więcej procesorów niż jest fizycznie na karcie. Dlatego zastanawiam się nad sensem tworzenia ich większej ilości, niż posiada karta.

Wibowit napisał(a):

Wątpię by jakiś wątek miał dostęp do 512 KiB pamięci lokalnej. Na mój gust cała pamięć lokalna na GPU ma rozmiar 512 KiB i jest równo podzielona pomiędzy SIMDy.
Edit: Hmm, chyba pomyliłem lokalną z współdzieloną. W OpenCL jest lokalna pamięć współdzielona dla danego SIMDa. O tym myślałem.

No właśnie na stronie NVIDI jest informacja, że Amount of local memory per thread wynosi 512 KB dla Compute Capability >= 2.0
Z jednej strony to dużo a z drugiej malutko... Zależy jak chce się to wykorzystać.

Wibowit napisał(a):

Jeśli chcesz efektywnie wykorzystać wszystkie potoki na GPGPU, to pojedynczy wątek musi mieć co najwyżej kilka kilobajtów pamięci prywatnej (czyli rejestrów w pamięci SRAM na czipie; najlepiej poniżej kilobajta) i wykonywać względnie mało odwołań do pamięci globalnej, no chyba że dane "dobrze się keszują", tzn w rzeczywistości GPU rzadko sięga do VRAMu.

No i tu zaczynają się problemy bo na GPU jest w ogóle bardzo mało pamięci współdzielonej a niewiele więcej tej lokalnej, natomiast nie każdy problem polega na przemnażaniu macierzy...
Inny problem polega na ograniczeniu przesyłania danych pomiędzy hostem a urządzeniem (wąskie gardło).

Wibowit napisał(a):

Temat jest złożony i myślę, że najlepiej ogarnąć go metodą prób i błędów. Sam wgryzam się w OpenCL i Radeony (ponownie, bo kiedyś już próbowałem, ale to była stara generacja) i jakoś nie widzę żebym miał to ogarnąć przez samo czytanie i rozmyślanie.

Jak najbardziej masz rację ;-). Chcę sobie jednak dobrze poukładać teorię, by później mniej czasu siedzieć nad testami.

W OpenCLu jest trochę inna terminologia, więc moje wywody moga nieco wprowadzać w błąd.

Natomiast, jeśli się nie mylę, i 1 blok reprezentuje jeden multiprocesor lub coś w tym stylu, a oczywistym jest, że nie może pracować równocześnie więcej procesorów niż jest fizycznie na karcie. Dlatego zastanawiam się nad sensem tworzenia ich większej ilości, niż posiada karta.

Napisałem już wcześniej, że optymalnym jest mieć więcej odpalonych wątków niż jest potoków obliczeniowych (czyli, marketingowo, procesorów strumieniowych) ze względu na opóźnienia instrukcji. Załóżmy że masz tyle wątków co potoków. Z tego powodu nie następuje przełączanie wątków na SIMDach, bo nie ma to tutaj sensu (nie ma wątków czekających w kolejce). Jednak np opóźnienie instrukcji dodawania wynosi np 5 taktów. Oznacza to, że każdy SIMD musi sobie poczekać 5 taktów gdy natrafi na operację dodawania, a kolejna instrukcja wykorzystuje wynik tego dodawania. Ponieważ instrukcje wykonywane są w kolejności w jakiej przybyły, to w ciągu tych 5 taktów SIMD nie robi nic innego. Gdyby natomiast było więcej wątków niż jest potoków, to SIMD mógłby przełączyć się na inne wątki i odpalić inne instrukcje w czasie gdy liczy się to dodawanie w 5 taktach. Podobnie ma się sprawa z dostępem do pamięci - jeden warp (czy jak to tam nazwać) czeka sobie na dostęp do pamięci globalnej, a SIMD natychmiastowo przełącza się na inny warp, który ma już w pamięci lokalnej/ prywatnej gotowe dane do obrabiania.