Programowanie GPU jako procesora ogólnego przeznaczenia.

Transkrypt

1 Programowanie GPU jako procesora ogólnego przeznaczenia Wykład III Architektura CUDA Witold Rudnicki Łukasz Ligowski Interdyscyplinarne Centrum Modelowania Matematycznego i Komputerowego Uniwersytet Warszawski Odwrócone więzy STARE Moc jest za darmo, tranzystory kosztują JeŜeli moc jest problemem to jest to moc dynamiczna Procesory nie zawierają błędów, błędy mogą się zdarzać jedynie na połączeniach MoŜemy w nieskończoność zwiększać poziom abstrakcji i rozmiar logiczny układów Nowe pomysły mogą być testowane w postaci układów scalonych Wzrost wydajności pozwala na wzrost pasma i zmniejszenie latencji MnoŜenie jest powolne, load & store są szybkie NOWE Moc jest droga, tranzystory są za darmo Moc spoczynkowa to do 40% mocy maksymalnej. (POWER WALL) Procesory produkowane w procesie poniŝej 65 nm będą miały duŝy poziom błędów (miękkich i twardych) Opóźnienia sygnału, szumy, sprzęŝenia elektryczne i magnetyczne, niedokładność zegarów uniemoŝliwiają w praktyce dowolne zwiększanie rozmiarów układów scalonych Koszty produkcji układów < 65nm, oprogramowania, i projektowania sprawiają, Ŝe prototypy stają się zawodne Wzrost pasma jest co najmniej kwadratowy jako funkcja spadku latencji Load & store są wolne, mnoŝenie jest szybkie (MEMORY WALL) 1

2 Odwrócone więzy STARE Wzrost wydajności moŝna uzyskać przez równoległość na poziomie instrukcji (ILP) dzięki rozwojowi architektury i kompilatorów (przewidywanie rozgałęzień, wykonanie out-of-order, zgadywanie wyników instrukcji warunkowych, układy VLSI. Wydajność pojedynczego procesora podwaja się co 18 miesięcy Nie ma sensu zrównoleglać aplikacji wystarczy poczekać Zwiększanie wydajności odbywa się przez zwiększanie częstotliwości zegara Słabsze niŝ liniowe zwiększenie wydajności dzięki zrównoleglaniu jest poraŝką. NOWE Wzrost wydajności dzięki równoległości na poziomie instrukcji się wyczerpał. (ILP WALL) POWER WALL + MEMORY WALL + ILP WALL = BRICK WALL. Podwajanie się wydajności pojedynczego procesora to co najmniej 5 lat. To sobie jeszcze poczekasz Zwiększanie wydajności odbywa się przez zwiększanie równoległości. KaŜde zwiększenie wydajności dzięki zrównolegleniu jest sukcesem Jest jeszcze nadzieja Prawo Moore a obowiązuje: Setki rdzeni obliczeniowych w jednym układzie scalonym Brak latencji i duŝe pasmo dla komunikacji wewnątrz układu scalonego 2

3 Jak to GPU wykorzystuje prawo Moore a Podwajanie wydajności co 18 miesięcy. Dzięki wzrostowi liczby tranzystorów Architektura CUDA ZałoŜenia DuŜa przepustowość DuŜa moc obliczeniowa DuŜa równoległość (model data parallel) Ukrywanie latencji pamięci Skalowalność 3

4 Model Programowania Architektura CUDA Kernele obliczeniowe uruchamiane na GPU są zarządzane przez główny program uruchamiany na CPU Grid (kernel) = N Bloków Blok = K x 64 wątków Wątek = program Bloki muszą być niezaleŝne kolejność wykonywania bloków jest dowolna Ilość bloków jest (niemal) dowolna Wątki w ramach jednego bloku mogą się komunikować przy uŝyciu pamięci współdzielonej Wszystkie wątki mają dostęp do wspólnej pamięci globalnej Architektura CUDA Realizacja Sprzętowa Karta koprocesora (graficznego/obliczeniowego) połączona z CPU za pomocą szybkiego złącza o duŝej przepustowości Macierz procesorów strumieniowych (SPA) Architektura SIMT (Single Instruction Multiple Threads) Hierarchiczna budowa Karta TPC (thread processing cluster / texture processing cluster) 2 (3) x SM (Streaming Multiprocessor)» 8 x SP (Streaming Processor)» Inne jednostki wykonawcze» 8 x TF (Texture Filtering Unit) 4

5 Architektura CUDA G80 Streaming Processor Array TPC TPC TPC TPC TPC TPC Texture Processor Cluster SM Streaming Multiprocessor Instruction L1 Data L1 Instruction Fetch/Dispatch TEX SP Shared Memory SP SM SP SP SFU SP SP SFU Zródlo: David Kirk/NVIDIA and Wen-mei W.Hwu, 2007 ECE 498AL, University of Illinois, Urbana-Champaign SP SP Architektura CUDA SM (Streaming Multiprocessor) Instruction Issuing Unit 8 x SP (Streaming Processor) 2 x SFU (Special Function Unit) 1 x DPALU 16 kb pamięci współdzielonej 8 x Texture Filtering Unit Instruction & Data cache Texture & Constant memory cache 5

6 Architektura CUDA gtx 200 (procesowanie grafiki) TPC texture processing cluster SM streaming multiprocessor SP streaming processor Architektura CUDA GTX 200 obliczenia 6

7 Specyfikacja CUDA TPC texture processing cluster SM streaming multiprocessor SP streaming processor TF texture filtering Specyfikacja CUDA TPC texture processing cluster SM streaming multiprocessor SP streaming processor 7

8 Streaming Multiprocessor (SM) Streaming Multiprocessor (SM) 8 Streaming Processors (SP) 2 Super Function Units (SFU) Wielowątkowe wykonywanie rozkazów dla 1 do 1024 (768) jednocześnie aktywnych wątków Wspólne pobieranie instrukcji dla 32 wątków tworzących osnowę (warp) Wspólne dla wszystkich aktywnych wątków zasoby multiprocesora (8192) rejestry 16 KB shared memory (4K zmiennych typu float lub int) w 16 bankach Osnowa (warp) składa się z 32 wątków Cache dla constant memory 8 KB na multiprocesor Cache dla texture memory 6-8 KB na multiprocesor Max 8 aktywnych bloków na multiprocesor Max 32 (24) aktywne osnowy Dla compute capabilitiy 1.2 wsparcie dla głosowania wątków Operacje atomowe na bitowych zmiennych w pamięci globalnej Architektura CUDA a nowy paradygmat projektowania sprzętu Równoległość jest efektywną energetycznie formą zwiększania wydajności. Wiele małych rdzeni daje większą wydajność na powierzchnię chipu dla kodów równoległych DuŜo małych rdzeni pozwala na elastyczną politykę zarządzania energią Defekty w małych rdzeniach mało kosztują (układy z wadami w pojedynczych rdzeniach są nadal funkcjonalne SP3 uŝywa 7 z 8 rdzeni procesora Cell) Małe rdzenie jest łatwiej zaprojektować, zweryfikować i przetestować a ich charakterystyka elektryczna jest łatwiejsza do przewidywania 8

9 Hierarchia wykonywania programu Wątek Half warp (16 wątków) Warp (32 wątki) Block ( wątków) Grid max 64Kx64Kx64K bloków Hierarchia wątków Pół osnowa (half warp) 16 wątków Zarządzanie dostępem do pamięci Osnowa (warp) Blok Wspólne wykonywanie instrukcji (4 cykle na osnowę) Grupa wątków wykonująca ten sam kod, mająca dostęp do wspólnej pamięci współdzielonej Grid Program składający się z wielu bloków (im więcej tym lepsza skalowalność kodu) 9

10 Specyfikacja CUDA TPC texture processing cluster SM streaming multiprocessor SP streaming processor Memory Wall Problemy - Pasmo - Opóźnienia - Pojemność CUDA nie ma na to wpływu Pasmo częstotliwość x szerokość szyny Architektura CUDA oparta jest na bardzo szerokiej szynie danych 384 bity w poprzedniej generacji 512 bitów w najnowszej generacji Opóźnienia ukrywanie opóźnień dzięki duŝej ilości niezaleŝnych wątków 10

11 Architektura pamięci Rodzaje pamięci Pamięć globalna Pamięć lokalna Pamięć współdzielona Pamięć stała Pamięć tekstur Pliki rejestrów Hierarchia pamięci 11

12 Hierarchia pamięci Pamięć lokalna prywatna dla wątku, wydzielony obszar pamięci RAM karty Pamięć współdzielona widoczna dla wszystkich wątków w bloku pamięć wewnętrzna procesora Plik rejestrów prywatna dla wątku ograniczona. Ilość rejestrów przypadających na jeden wątek zaleŝy od ilości wątków. Pamięć globalna On device Widoczna dla wszystkich wątków Opóźnienie dostępu rzędu 200 cykli zegara Nie ma cache a Dostęp RW Widoczna dla hosta 12

13 Pamięć lokalna On device Prywatna dla jednego wątku Opóźnienie dostępu rzędu 200 cykli zegara Nie ma cache a Dostęp RW niewidoczna dla hosta Pamięć tekstur On device Wszystkie wątki Cache Dostęp ReadOnly Jedynie host moŝe do niej pisać 13

14 Pamięć stała On device Wszystkie wątki Cache Dostęp ReadOnly Jedynie host moŝe do niej pisać On chip Pamięć współdzielona Wszystkie wątki w bloku Dostęp RW Niewidoczna dla hosta Dzielona między wszystkie jednocześnie aktywne bloki 14

15 On chip Plik rejestrów Prywatne dla jednego wątku w bloku Dostęp RW Niewidoczna dla hosta Dzielona między wszystkie jednocześnie aktywne bloki Efektywne kodowanie Jednoczesna optymalizacja zuŝycia wielu zasobów Minimalizacja dostępu do pamięci globalnej Maksymalizacja liczby wątków 15

16 Optymalizacja dostępu do pamięci Latencja dostępu do pamięci głównej i lokalnej ~200 cykli zegara Czas wykonania jednej instrukcji dla jednej osnowy (warp) 4 cykle (32 / 8) kolejne osnowy na jednym multiprocesorze powinny wykonać 50 instrukcji zanim bieŝąca będzie otrzyma dane z pamięci globalnej. Dla prostych kodów maksymalizacja liczby wątków umoŝliwia chowanie latencji JeŜeli kod jest gęsty obliczeniowo, lub operacje są bardziej kosztowne optymalna ilość wątków będzie mniejsza Optymalizacja dostępu do pamięci Teoretyczna wydajność obliczeniowa karty GTX 280 wynosi 933 GFlops Operacja polegająca na wzięciu trzech argumentów z pamięci wykonaniu na nich mnoŝenia i zapisaniu wyniku wykorzystuje maksymalnie moc obliczeniową (MULADD + MUL) A=k*(A+C*D) JeŜeli operacje odbywałyby się na zmiennych pobieranych z pamięci głównej i zapisywane do pamięci głównej wymagane pasmo wynosi: 4 (Operacje RW/ Cykl) *4B (Sizeof(float)) *311G (cykli /s) = 4976 GB/s Dostępne pasmo wynosi ~140 GB/s 16

17 Uwaga na marginesie Teoretyczna wydajność obliczeniowa karty GTX 280 wynosi 933 GFlops Ta wydajność jest moŝliwa do osiągnięcia tylko dla kodu, który ma właściwą proporcję operacji elementarnych ALU moŝe wykonać jednocześnie MULADD MUL A zatem wymagane są obliczenia w których występuje odpowiednia proporcja operacji typu MULADD i MUL Jeśli obliczenia składają się np. głównie z dodawania, to wydajność będzie mniejsza Dla oszacowania teoretycznej wydajności swojego kodu trzeba zanalizować wewnętrzną pętlę i policzyć elementarne operacje arytmetyczne, sprawdzić ile z nich da się pogrupować w trójki realizowane jako MULADD + MUL Policzyć przewidywaną ilość instrukcji procesora Optymalizacja dostępu do pamięci NaleŜy minimalizować odwołania do pamięci głównej! Wczytaj często uŝywane dane do pamięci współdzielonej Wykonaj obliczenia Zapisz wyniki do pamięci głównej Ograniczenia Niewielka ilość pamięci współdzielonej (16 KB na multiprocesor) 17

18 Optymalizacja dostępu do pamięci Dodatkowe optymalizacje dostępu do pamięci Dostęp odbywa się dla pół-osnowy (half-warp) jednocześnie w jednej transakcji dostępu do pamięci Zasada ogólna: Dostęp jest optymalny, gdy kolejne wątki odwołują się do kolejnych lokalizacji w pamięci, tak Ŝeby transakcja odwoływała się do ciągłego obszaru, zaczynającego się na granicy banku pamięci. Optymalizacja dostępu do pamięci Odczyt z pamięci odbywa się za pomocą operacji 32, 64 i 128 bitowych (4, 8 i 16 bajtowych). Instrukcje dla kolejnych wątków mogą być sklejane dla uzyskania efektywnych transakcji z pamięcią. Najbardziej efektywny dostęp jest jeŝeli uda się skleić odwołania pochodzące z kolejnych wątków w 32, 64 lub 128 bajtowe transakcje z pamięcią. Transakcje 32-bajtowe są uŝywane przez urządzenia z compute capability 1.2 i więcej 18

19 Optymalizacja dostępu do pamięci Compute capability 1.0 i 1.1 Aby sklejanie mogło się powieść wątki muszą uŝywać zmiennych: 32-bitowych (transakcja 64 bajtowa), 64-bitowych (transakcja 128 bajtowa), 128-bitowych (dwie transakcje 128 bajtowe); Wszystkie 16 zmiennych musi znajdować się w tym samym segmencie pamięci o wielkości odpowiadającej wielkości transakcji (podwójnej dla zmiennych 128 bitowych); Kolejność zmiennych musi odpowiadać kolejności wątków k-ty wątek w półosnowie musi odwoływać się do k-tej zmiennej. Dobrze 1 transakcja Optymalizacja dostępu do pamięci 19

20 Compute capability 1.0 & 1.1 Źle - 16 oddzielnych transakcji Optymalizacja dostępu do pamięci Optymalizacja dostępu do pamięci Compute capability 1.2 i więcej Aby sklejanie mogło się powieść wszystkie 16 zmiennych musi znajdować się w tym samym segmencie o wielkości: 32 bajty (zmienne 8-bitowe), 64 bajty (zmienne 16-bitowe), 128 bajtów (zmienne 32 i 64 bitowe); Restrykcje dotyczące kolejności wątków zostały zniesione Restrykcje dotyczące granic segmentów zostały częściowo zniesione 20

21 Optymalizacja dostępu do pamięci compute capability 1.2 Dwie transakcje Jedna transakcja Optymalizacja dostępu do pamięci Pamięć lokalna Zmienne automatyczne, dla których nie ma miejsca w rejestrach Umieszczana w pamięci karty Nie jest buforowana w cache u, Problemy z wydajnością Odwołania są zawsze sklejone (dba o to kompilator). UNIKAĆ!! 21

22 Optymalizacja dostępu do pamięci Pamięć stała Umieszczana w pamięci karty Jest buforowana w cache u, Wszystkie wątki w półosnowie (hal-warp) powinny czytać z tego samego adresu wtedy szybkość odczytu z cache a jest równa szybkości korzystania z rejestrów Zalecane jest by wszystkie wątki z całej osnowy czytały z tego samego adresu. Miejsce na przechowywanie stałych Optymalizacja dostępu do pamięci Pamięć tekstur Umieszczana w pamięci karty Jest buforowana w cache u, Nie zmniejsza latencji (ale lepsze ukrywanie latencji) Hit zmniejsza uŝycie szyny pamięci moŝe zwiększyć przepustowość innych obliczeń Nie ma ograniczeń dotyczących adresów, z których moŝna czytać (przydatne dla dostępu w losowej kolejności) Zalecane jest by wątki z tej samej osnowy (warp) czytały z bliskich adresów. 22

23 Optymalizacja uwagi ogólne Moc obliczeniowa wielokrotnie większa niŝ dostępne pasmo Optymalizacja to przede wszystkim algorytmy optymalnie wykorzystujące pamięć Jednoczesne Ŝonglowanie wieloma parametrami Optymalizacja uwagi ogólne Zwiększanie ilości wątków Pomaga ukryć latencję pamięci głównej ALE Zwiększa zuŝycie cennych lokalnych zasobów Rejestrów Pamięci współdzielonej Pamięć współdzielona jest mała i dzielona przez bardzo duŝą liczbę wątków Rejestry mogą być ograniczeniem przy bardziej wymagających kodach Warto pamiętać o pamięci constant i pamięci tekstur 23

24 Architektura CUDA a wymarzony model ManyCore computing CUDA vs C for CUDA 24

25 Modele programowania Zorientowane na sprzęt Efektywność Mała przenośność Trudne programowanie Zorientowane na aplikacje Łatwość tworzenia kodów specyficznych dla danej domeny Stosunkowo niska wydajność Słabe wsparcie dla równoległości Zorientowane na poprawność formalną Zmniejszanie szans popełnienia błędu Modele programowania Brak powiązań z psychologią Jakie zadania są łatwe Jakie zadania są trudne Gdzie łatwo popełnić błędy Pamięć transakcyjna przykład modelu pomagającego w trudnych zadaniach 25

26 Modele programowania Wymagania wobec nowych modeli programistycznych NiezaleŜne od liczby procesorów ~OK Wspieranie bogatego zestawu rodzajów i wielkości danych NIE 1 bit (Boolowskie) 8 bit (ASCI, Integer) 16 bit (Integer, DSP fixed point, Unicode) 32 bit (Integer, SP FP, Unicode) 64 bit (Integer, DP FP) 128 bit (Integer, QP FP) > 128 bit (crypto) Miary sukcesu Maksymalizacja produktywności programisty (time to running code) Maksymalizacja wydajności aplikacji (time to solution) 26

27 Krasnale - podsumowanie Krasnale - podsumowanie 27

28 Krasnale - podsumowanie Krasnale - podsumowanie 28

29 Wykonanie programu Specyfikacja CUDA Specifications for Compute Capability 1.0 The maximum number of threads per block is 512; The maximum sizes of the x-, y-, and z-dimension of a thread block are 512, 512, and 64, respectively; The maximum size of each dimension of a grid of thread blocks is 65535; The warp size is 32 threads; The number of registers per multiprocessor is 8192; The amount of shared memory available per multiprocessor is 16 KB organized into 16 banks (see Section ); The total amount of constant memory is 64 KB; The cache working set for constant memory is 8 KB per multiprocessor; The cache working set for texture memory varies between 6 and 8 KB per multiprocessor; The maximum number of active blocks per multiprocessor is 8; The maximum number of active warps per multiprocessor is 24; The maximum number of active threads per multiprocessor is 768; For a texture reference bound to a one-dimensional CUDA array, the maximum width is 213; For a texture reference bound to a two-dimensional CUDA array, the maximum width is 216 and the maximum height is 215; For a texture reference bound to a three-dimensional CUDA array, the maximum width is 211, the maximum height is 211, and the maximum depth is 211; For a texture reference bound to linear memory, the maximum width is 227; The limit on kernel size is 2 million ptx instructions; Each multiprocessor is composed of eight processors, so that a multiprocessor is able to process the 32 threads of a warp in four clock cycles. 29

30 Specyfikacja CUDA Specifications for Compute Capability 1.1 Support for atomic functions operating on 32-bit words in global memory (see Section 4.4.4). Specifications for Compute Capability 1.2 Support for atomic functions operating in shared memory and atomic functions operating on 64-bit words in global memory (see Section 4.4.4); Support for warp vote functions (see Section 4.4.5); The number of registers per multiprocessor is 16384; The maximum number of active warps per multiprocessor is 32; The maximum number of active threads per multiprocessor is Specifications for Compute Capability 1.3 Support for double-precision floating-point numbers. Specyfikacja CUDA SIMT Architecture NVIDIA s unified shading and compute architecture uses two different processing models. For execution across the TPCs, the architecture is MIMD (multiple instruction, multiple data). For execution across each SM, the architecture is SIMT (single instruction, multiple thread). SIMT improves upon pure SIMD (single instruction, multiple data) designs in both performance and ease of programmability. Being scalar, SIMT has no set vector width and therefore performs at full speed irrespective of vector sizes. In contrast, SIMD machines operate at a reduced capacity if the input is smaller than the MIMD or SIMD width. SIMT ensures the processing cores are fully utilized at all times. From the programmer s perspective, SIMT also allows each thread to take on its own TPC path. Since texture branching processing is handled by the cluster hardware, there is no need to manually manage branching within the vector width. SM streaming multiprocessor SP streaming processor 30

31 Specyfikacja CUDA Improved Dual Issue Special function units (SFUs) in the SMs compute transcendental math, attribute interpolation (interpreting pixel attributes from a primitive s vertex attributes), and perform floating-point MUL instructions. The individual streaming processing cores of GeForce GTX 200 GPUs can now perform near full-speed dual-issue of multiply-add operations (MADs) and MULs (3 flops/sp) by using the SP s MAD unit to perform a MUL and ADD per clock, and using the SFU to perform another MUL in the same clock. Optimized and directed tests can measure around 93-94% efficiency. The entire GeForce GTX 200 GPU SPA delivers nearly one teraflop of peak, singleprecision, IEEE 754, floating-point performance. Double Precision Support A very important new addition to the GeForce GTX 200 GPU architecture is doubleprecision, 64-bit floating point computation support. This benefits various high-end scientific, engineering, and financial computing applications or any computational task requiring very high accuracy of results. Each SM incorporates a double-precision 64- bit floating math unit, for a total of 30 double-precision 64-bit processing cores. The double-precision unit performs a fused MAD, which is a high-precision implementation of a MAD instruction that is also fully IEEE 754R floating-point specification compliant. The overall double-precision performance of all 10 TPCs of a GeForce GTX 280 GPU is roughly equivalent to an eight-core Xeon CPU, yielding up to 78 gigaflops. Obszary aplikacji równoległych Metafora Siedmiu krasnali (Seven Dwarfs). Algorytmy o podobnej strukturze komunikacji i organizacji danych zostały pogrupowane w klasy równowaŝności nazwane przez autorów krasnalami. Programy mogą składać się z wielu problemów kaŝdy z nich moŝe być rozwiązywany przy pomocy innego krasnala. 31

32 Specyfikacja CUDA 512-bit Memory Interface Maximum memory interface width is expanded from 384 bits in previous-generation GPUs to 512 bits in GeForce GTX 200 GPUs, using eight 64-bitwide frame buffer interface units. Memory bandwidth has been significantly increased. 32

33 Thread Batching: Grids and Blocks Host Device A kernel is executed as a grid of thread blocks All threads share data memory space A thread block is a batch of threads that can cooperate with each other by: Synchronizing their execution For hazard-free shared memory accesses Efficiently sharing data through a low latency shared memory Two threads from two different blocks cannot cooperate Kernel 1 Kernel 2 Block (1, 1) Thread (0, 0) Thread (0, 1) Thread (0, 2) Thread (1, 0) Thread (1, 1) Thread (1, 2) Grid 1 Block (0, 0) Block (0, 1) Grid 2 Thread (2, 0) Thread (2, 1) Thread (2, 2) Block (1, 0) Block (1, 1) Thread (3, 0) Thread (3, 1) Thread (3, 2) Courtesy: NDVIA Thread (4, 0) Thread (4, 1) Thread (4, 2) Block (2, 0) Block (2, 1) Each thread can: Programming Model: Memory Spaces Read/write per-thread registers Read/write per-thread local memory Read/write per-block shared memory Read/write per-grid global memory Read only per-grid constant memory Read only per-grid texture memory Grid Block (0, 0) Registers Shared Memory Thread (0, 0) Local Memory Registers Thread (1, 0) Local Memory Block (1, 0) Registers Shared Memory Thread (0, 0) Local Memory Registers Thread (1, 0) Local Memory The host can read/write global, constant, and texture memory Host Global Memory Constant Memory Texture Memory 33

34 CUDA Device Memory Space Overview Each thread can: R/W per-thread registers R/W per-thread local memory R/W per-block shared memory R/W per-grid global memory Read only per-grid constant memory Read only per-grid texture memory (Device) Grid Block (0, 0) Registers Shared Memory Thread (0, 0) Registers Thread (1, 0) Block (1, 0) Registers Shared Memory Thread (0, 0) Registers Thread (1, 0) The host can R/W global, constant, and texture memories Host Local Memory Global Memory Constant Memory Local Memory Local Memory Local Memory Texture Memory Programmer View of Register File There are 8192 registers in each SM in G80 This is an implementation decision, not part of CUDA Registers are dynamically partitioned across all Blocks assigned to the SM Once assigned to a Block, the register is NOT accessible by threads in other Blocks Each thread in the same Block only access registers assigned to itself 4 blocks 3 blocks 34

35 Shared Memory Each SM has 16 KB of Shared Memory 16 banks of 32bit words CUDA uses Shared Memory as shared storage visible to all threads in a thread block read and write access Not used explicitly for pixel shader programs we dislike pixels talking to each other I$ L1 Multithreaded Instruction Buffer R F C$ L1 Operand Select MAD Shared Mem SFU Thread Scheduling/Execution Each Thread Blocks is divided in 32- thread Warps This is an implementation decision, not part of the CUDA programming model Warps are scheduling units in SM If 3 blocks are assigned to an SM and each Block has 256 threads, how many Warps are there in an SM? Each Block is divided into 256/32 = 8 Warps There are 8 * 3 = 24 Warps At any point in time, only one of the 24 Warps will be selected for instruction fetch and execution. Block 1 Warps t0 t1 t2 t31 Block 2 Warps t0 t1 t2 t31 Streaming Multiprocessor Instruction L1 SP SP SP SP Instruction Fetch/Dispatch Shared Memory SFU Data L1 SP SP SP SP SFU 35

36 SM Executes Blocks t0 t1 t2 tm SM 0 SM 1 t0 t1 t2 tm MT IU SP MT IU SP Blocks Blocks Shared Memory TF Shared Memory Texture L1 Memory L2 Threads are assigned to SMs in Block granularity Up to 8 Blocks to each SM as resource allows SM in G80 can take up to 768 threads Could be 256 (threads/block) * 3 blocks Or 128 (threads/block) * 6 blocks, etc. Threads run concurrently SM assigns/maintains thread id #s SM manages/schedules thread execution CUDA Thread Block: Review Programmer declares (Thread) Block: Block size 1 to 512 concurrent threads Block shape 1D, 2D, or 3D Block dimensions in threads All threads in a Block execute the same thread program Threads have thread id numbers within Block Threads share data and synchronize while doing their share of the work Thread program uses thread id to select work and address shared data CUDA Thread Block Thread Id #: m Thread program Courtesy: John Nickolls, NVIDIA 36

37 CUDA Processor Terminology SPA Streaming Processor Array (variable across GeForce 8- series, 8 in GeForce8800) TPC Texture Processor Cluster (2 SM + TEX) SM Streaming Multiprocessor (8 SP) Multi-threaded processor core Fundamental processing unit for CUDA thread block SP Streaming Processor Scalar ALU for a single CUDA thread Matrix Multiplication Example If each Block has 16X16 threads and each thread uses 10 registers, how many thread can run on each SM? Each Block requires 10*256 = 2560 registers 8192 = 3 * change So, three blocks can run on an SM as far as registers are concerned How about if each thread increases the use of registers by 1? Each Block now requires 11*256 = 2816 registers 8192 < 2816 *3 Only two Blocks can run on an SM, 1/3 reduction of parallelism!!! 37

38 GeForce 8800 Series Technical Specs Maximum number of threads per block: 512 Maximum size of each dimension of a grid: 65,535 Number of streaming multiprocessors (SM): GeForce 8800 GTX: 675 MHz GeForce 8800 GTS: 600 MHz Device memory: GeForce 8800 GTX: 768 MB GeForce 8800 GTS: 640 MB Shared memory per multiprocessor: 16KB divided in 16 banks Constant memory: 64 KB Warp size: 32 threads (16 Warps/Block) What is the GPU Good at? The GPU is good at data-parallel processing The same computation executed on many data elements in parallel low control flow overhead with high SP floating point arithmetic intensity Many calculations per memory access Currently also need high floating point to integer ratio High floating-point arithmetic intensity and many data elements mean that memory access latency can be hidden with calculations instead of big data caches Still need to avoid bandwidth saturation! 38

39 More Terminology Review device = GPU = set of multiprocessors Multiprocessor = set of processors & shared memory Kernel = GPU program Grid = array of thread blocks that execute a kernel Thread block = group of SIMD threads that execute a kernel and can communicate via shared memory Memory Location Cached Access Who Local Off-chip No Read/write One thread Shared On-chip N/A - resident Read/write All threads in a block Global Off-chip No Read/write All threads + host Constant Off-chip Yes Read All threads + host Texture Off-chip Yes Read All threads + host 39

40 CUDA Programming Model: A Highly Multithreaded Coprocessor The GPU is viewed as a compute device that: Is a coprocessor to the CPU or host Has its own DRAM (device memory) Runs many threads in parallel Data-parallel portions of an application are executed on the device as kernels which run in parallel on many threads Differences between GPU and CPU threads GPU threads are extremely lightweight Very little creation overhead GPU needs 1000s of threads for full efficiency Multi-core CPU needs only a few 40