Cuda Speicherhierarchie

Transkript

1 Cuda Speicherhierarchie Threads eines Blocks können über Shared Memory kommunizieren Der Shared Memory ist klein aber sehr schnell Alle Threads können nur über Global Memory kommunizieren Der Global Memory ist groß aber langsam. Der Host hat ebenfalls hierauf Zugriff. Zusätzlich Constant Memory und Registers

2 Cuda nvcc nvcc kann den Device Code in Assembly Form (PTX Code) kompilieren, der dann für die jeweilige Hardware Just-In-Time in Byteform kompiliert wird. direkt in Byteform (cubin object) kompilieren, die dann Compute Capability abhängig ist. Der -code Parameter generiert Binärcode, -arch generiert PTX und Binärcode: nvcc test.cu -arch=sm_13,-code=sm_12 Kompatibilität von Bytecode wird über minor revisions garantiert, sonst aber nicht. Um zukünftige Hardware zu unterstützen: PTX generieren!

3 Cuda Speicherverwaltung Der Host kann nicht direkt auf den Speicher des Devices zugreifen. Das Device kann nicht direkt auf den Speicher des Hosts zugreifen. Debugging wurde gerade interessant, denn das heißt kein printf!

4 Cuda Kernel Cuda fügt C/C++ neue Function Qualifier hinzu. Funktionen die auf dem Host laufen und von dem Host aufgerufen werden: host Funktionen die auf dem Device laufen und von dem Host aufgerufen werden (access point): global Funktionen die auf dem Device laufen und von dem Device aufgerufen werden: device Das Device kann keine Funktionen auf dem Host aufrufen! Es gibt Restriktionen für Device-Code: Nur C, keine Rekursion, keine variable Anzahl Parameter...

5 Cuda Kernel Um Kernel aufzurufen muss angegeben werden wie viele threads gestartet werden sollen. Neue Syntax: <<< >>> global mykernel(float*p) { }; mykernel<<<blockgrid,threadgrid[, Ns]>>>(h_p); Wobei blockgrid die Dimension der Blocks threadgrid die Dimension der Threads pro Block Ns die größe des benutzten Shared Memory Diese Parameter sind vom Typ dim3, einen durch Cuda definierten Typ, 3 Integer, wobei nicht initialisierte per Default 1 sind. Sie können durch x,y,z angesprochen werden. 1d Syntax ist bei Kernelaufrufen erlaubt: mykernel<<<4,6>>>(h_p); Startet 4 Blocks (linear) mit jeweils 6 Threads von mykernel.

6 Cuda Kernel Im Kernel existieren vordefinierte Variablen: dim3 griddim Dimensionen des Grids uint3 blockidx Position des Blocks im Grid dim3 blockdim Dimension des Blocks uint3 threadidx Position des Threads im Block Nun kann man also die Thread Id berechnen: int X = blockdim.x * blockidx.x + threadidx.x; int Y = blockdim.y * blockidx.y + threadidx.y; int Z = blockdim.z * blockidx.z + threadidx.z;

7 Cuda Speichervergleich Speicher Scope Besonderheiten Register Thread On-Chip Local Memory Thread On-Chip uncached Shared Memory Block On-Chip, so schnell wie Register, 16Kb Global Memory Device Off-Chip, uncached, bis 4 GB groß Constant Memory Device cached Texture Memory Device cached

8 Cuda Cuda Notizen Anzahl der Register ist beschränkt, d.h. nicht viele lokale Variablen verfügbar (hardwareabhängig) Per Default sind Kernelaufrufe asynchron also: synchthreads() auch im Hostcode nicht vergessen Verzweigung im Kernel vermeiden und for loops unrollen Es können maximal 4 verschiedene Kernels parallel ausgeführt werden Globaler Speicher ist langsam ( Takte), daher viele Threads starten um die Latenz zu verstecken Alle Beispiele und Diagramme stammen aus dem Cuda Programmers Manual

9 Cilk++ Erweiterung von C++ um Mehrkernsysteme auszunutzen Oft: Konvertierung eines existierenden seriellen Programms. Wichtigste Erweiterungen: cilk_spawn Parallel ausführbarer Funktionsaufruf cilk_sync Block bis alle Spawn-Children returnen cilk_for Parallel ausführbare for Schleife

10 Cilk++ Kompilierung Compiliert wird durch cilk++ input -o output Der Default Workercount ist die Anzahl der Kerne auf dem ausführenden System Das Programm hat extra Command Line Optionen, die von der Cilk++ Runtime abgefangen werden, wenn cilk_main anstatt main verwendet wurde Um den Workercount manuell zu setzen:./output -cilk_worker_count 16

11 Cilk++ cilk::context C++ Funktionen könne nicht direkt cilk++ Funktionen aufrufen (verschiedene Calling Conventions) Daher in C++ Programmen: erst Context erstellen, dann cilk++ Funktion über den Context aufrufen cilk::context ctx; result = ctx.run(fib, (void*)&n); Erster Parameter ist Funktionspointer Zweiter Parameter ist Array von Pointern auf Funktionsargumente für fib Alternativ: cilk::run benutzen: result = cilk::run(&fib, n); Vorteil: Es muss kein Context explizit erstellt werden und die Argumente müssen nicht in ein Array zusammengefasst werden. Allerdings: für jeden Aufruf Generierung eines impliziten Contexts.

12 OpenCL Kernel Beispiel Beispielkernel, der von dem Hostprogramm dann in-order gequeued wird aber out-of-order ausgeführt wird. Wie bei Cuda ist dieser Kernel ein Beispiel für Data Level Parallelism. kernel void dp_mul(global const float *a, global const float *b, global float *result) { int id = get_global_id(0); result[id] = a[id] * b[id]; } //execute dp_mul over many work items

13 OpenCL Objekte Setup Devices GPU, CPU, Cell, Contexts Sammlungen von Devices Queues Verteilen Arbeit an die Device Memory Buffers Speicherblöcke Images 2d/3d Bilder Execution Kernels Programs Sammlungen von Kernels Synchronisation/Profiling Events

14 cl_uint num_devices; cl_device_id devices[2]; OpenCL Setup err = clgetdeviceids(null, CL_DEVICE_TYPE_GPU, 1, &devices[0], num_devices_returned); err = clgetdeviceids(null, CL_DEVICE_TYPE_CPU, 1, &devices[0], num_devices_returned); cl_context context; context= clcreatecontext(0,2,devices,null,null,&err); cl_command_queue queue_gpu, queue_cpu; queue_gpu = clcreatecommandqueue(context, devices[0], 0, &err); queue_cpu = clcreatecommandqueue(context, devices[1], 0, &err);

15 OpenCL Speicher Buffer/Images sind Speicher auf den Devices: cl_image_format format; format.image_channel_data_type = CL_FLOAT; format.image_channel_order = CL_RGBA; cl_mem img_ro = clcreateimage2d(context, CL_MEM_READ_ONLY, &format, img_width, img_height, 0, &err); cl_mem buf_wo = clcreatebuffer(context, CL_MEM_WRITE_ONLY, sizeof(cl_float)*4*img_width*img_height, NULL, &err);

16 OpenCL Speicher Wie in Cuda muss explizit von/zu den Devices kopiert werden: Lesen/Schreiben im Speicher object von/zu Speicher im Host clenqueuereadbuffer(queue, object, blocking, offset, size, *ptr, ) clenqueuewritebuffer(queue, object, blocking, offset, size, *ptr, ) Eine Region des object Speichers zu Hostspeicher mappen clenqueuemapbuffer(queue, object, blocking, flags, offset, size, ) Kopieren clenqueuecopybuffer(queue, srcobj, dstobj, src_offset, dst_offset, ) Diese Operation sind synchronisiert (blocking = CL_TRUE) oder asynchron