stefan auer computer graphics & visualization graphics processing unit general purpose...

Stefan Auer

computer graphics & visualization

GraphicsProcessingUnit

General Purpose Computation on


Stefan Auer

Inhalt

1) Motivation

2) Hardware Design aktueller GPUs

3) GPGPU mit Standard APIs

4) Anwendungsbeispiele

5) GPGPU a la Nvidia

6) GPGPU a la AMD/ATI


Stefan Auer

1) Motivation

- GPUs sind äußerst leistungsfähige Parallelrechner- Beispiel: Nvidia GeForce 8800 GTX

- 128 Stream Prozessoren- ~690 millionen Transistoren- 1350 MHz Shader clock speed- 86 GB/s Speicherbandbreite (Peak)- 345 Gflops Floatingpoint-Leistung (Peak, Multiply-

ADD)

- Vergleich: Intel Core 2 Quad Q6600- 4 Kerne (zwei Doppelkernprozessoren)- ~580 millionen Transistoren- 2400 MHz Takt- ~5 GB/s Speicherbandbreite (gemessen)- ~40 Gflops FPU-Leistung (gemessen, Whetstone)


Stefan Auer

1) Motivation

Gflops FMUL FADD50% FMUL / 50% FADD

FMADD

GeForce 8800 GTX 172,8 172,8 172,8 345,6

GeForce 8800 GTS 115,2 115,2 115,2 230,4

Core 2 Extreme QX6700 42,7 42,7 85,3 42,7

Core 2 Extreme X6800 23,5 23,5 46,9 23,5

Quelle: behardware.com

FMUL FADD 50% FMUL / 50% FADD

FMADD 0

100

200

300

400

GeForce 8800 GTX

GeForce 8800 GTS

Vergleich der Floatingpointleistung

Gflops


Stefan Auer

1) Motivation

- Leistungszuwachs war bei GPUs in letzter Zeit größer als bei CPUs (GPUs profitieren mehr als CPUs von Verbesserungen der Fertigung)

2004 2005 2006

Pentium 4 660

Pentium D 960

Core 2 Duo E6600

Core 2 Quad Q6600

CPU FPU-Leistung

2004 2005 2006

6800 GT

7900 GTX

8800 GTX

GPU Shader-Leistung (SM 2.0)

100%

1355%

100%

503%

Quelle: tomshardware.com


Stefan Auer

1) Motivation

- Einsatzzweck von GPUs ist das Rendering von interaktiven 3D Anwendungen

-> GPUs sind vergleichsweise preiswert (Videospiele sind Massenmarkt)

- GeForce 8800 GTX aktuell ~ 450.- €


Stefan Auer

GPUCPU

• Anwendung

• Transformation & (Vertex-) Beleuchtung

• Geometrie Verarbeitung

• Rasterisierung

• Schattierung

• Tests

• Render Target

• (Framebuffer,Texturen)

Vertices Primitive(z.B. Dreiecke)

Programmierbare Rendering Pipeline

Vertex Shader

Geometrie Shader (DX10)

Pixel Shader

Fragmente(„Pre-Pixels“)

Pixel(Farbe, Tiefe)

1) Motivation


Stefan Auer

Inhalt

1) Motivation







Stefan Auer


L2 Tex

Cull / Clip / Setup

Shader Instruction Dispatch

Fragment Crossbar

MemoryPartition

MemoryPartition

MemoryPartition

MemoryPartition

Z-Cull

DRAM(s) DRAM(s) DRAM(s) DRAM(s)

Host / FW / VTF

Quelle: Nvidia

8 vertex shaderpipelines

24 pixel shader pipelines

16 raster operation pipelines32 ppc

Nvidia G70Architektur(GeForce 7800)


Stefan Auer


Unified shader (1)

- Höhere Flexibilität- geometry shader, Spielphysik ?, general purpose

- Bessere Ausnutzung der Hardware

Viel GeometrieWenig Geometrie Lastverteilung

Quelle: Nvidia


Stefan Auer


Unified shader (2)

Vertex Shader

Pixel Shader

Idle hardware

Vertex Shader

Pixel Shader

Idle hardware

Heavy Geometry

Heavy Pixel

Quelle: Nvidia


Stefan Auer


Unified shader (3)

Heavy Geometry

Heavy Pixel

Quelle: Nvidia

Unified Shader

Unified Shader

Vertex workload

Pixelworkload

Pixel workload

Vertexworkload


Stefan Auer


L2

FB

SP SP

L1

TF

Th

read

Pro

cessor

Vtx Thread Issue

Setup / Rstr / ZCull

Geom Thread Issue Pixel Thread Issue

Data Assembler

Host

SP SP

L1

TF

SP SP

L1

TF

SP SP

L1

TF

SP SP

L1

TF

SP SP

L1

TF

SP SP

L1

TF

SP SP

L1

TF

L2

FB

L2

FB

L2

FB

L2

FB

L2

FB

Quelle: Nvidia

12

8 u

nifi

ed sh

ader p

ipelin

es

6 R

OPs 1

92

ppc

Nvidia G80Architektur

(GeForce 8800)


Stefan Auer


CPU vs. GPU: CPU Architektur

- CPUs implementieren Von Neumann Architektur

- Von Neumann Flaschenhals- Teilung von ALU und Speicher schafft Bandbreitenprobleme- heutige ALUs sind wesentlich schneller als die

Datenverbindungen- cache management notwendig > großer Kontroll-Overhead- > für rechenintensive Anwendungen verbleibt weniger Leistung


Stefan Auer


CPU vs. GPU: GPU Architektur

- GPUs entsprechen annähernd Stream Processing Architektur

- Anwendung organisiert in Streams und Kernel- fördert Lokalität der Daten und Parallelität ihrer Verarbeitung


Stefan Auer


CPU vs. GPU: Gegenüberstellung

- CPU: profitiert hauptsächlich von Aufgabenparallelität

- schnelle (aber kostspielige) Caches- Pipelines auf Sprünge optimiert- wenige Ausführungseinheiten (1,2,4,...)- hohe Leistung bei Bearbeitung einzelner Threads

- GPU: profitiert zusätzlich von Datenparallelität

- sehr viele ALUs, spezialisiert auf floating-point Arithmetik

- sehr hohe Speicherbandbreite (aber hohe Latenz)- tausende Threads mit gleichem Kernel


Stefan Auer

Inhalt

1) Motivation







Stefan Auer


„Standard“-Verwendung der Pipeline bei GPGPU

FragmentProzessor

2„s

cree

n“

0 1

1

2

FrameBuffer(s)

TextureBuffer

RasterisiererVertexProzessor

VertexTextureFetch

Renderto

TextureTexture

Sampling(Gather)


Stefan Auer


Texturen als computational grids

- (ein) typischer GPGPU Programmierstil

- Texturen repräsentieren Streams (Texel = Datenelement)

- Fragmentprogramme (pixel shader) repräsentieren Kernel

- Zeichnen eines Full-Screen-Rechtecks repräsentiert Berechnungschritt


Stefan Auer


- viele Berechnungen lassen sich gut auf Grids abbilden:- Matrix Algebra- Bild- und Volumenverarbeitung- Physiksimulationen- Global Illumination

- ray tracing, photon mapping, radiosity

- Streams die keinen Grids entsprechen lassensich meist darauf abbilden


Stefan Auer


GPGPU „Hello World“ (1)

- Bildverarbeitung: 3x3 Faltung - Input: Bild, Gewichtungen- Output: „geblurrtes“ Bild

CPU Version:

image = loadImage(WIDTH, HEIGHT);blurImage = allocZeros(WIDTH, HEIGHT);

for (x=0; x < WIDTH; x++) for (y=0; y < HEIGHT; y++) for (i=-1; i <= 1; i++) for (j=-1; j <= 1; j++) float w = computeWeight(i,j); blurImage[x][y] += w * image[x+i, y+j];


Stefan Auer



GPU Version:

1) Lade image als Textur

2) erstelle blurImage Texturwelche das Ergebnis aufnimmt


Stefan Auer



GPU Version:

3) Lade Fragment-Programm (Kernel)Beispielcode in CG:

float4 blurKernel(uniform samplerRECT image, float2 winPos : WPOS, out float4 blurImage ) { blurImage = float4(0,0,0,0); for (i=-1; i <= 1; i++) { for (j=-1; j <= 1; j++) { float2 texCoord = winPos + float2(i,j); float w = computeWeight(i,j); blurImage += w * texRECT( image, texCoord ); } }}


Stefan Auer



GPU Version:

4) wähle Viewport-Größe entsprechend Bildgrößekonfiguriere Vertex Pipeline so dass sie „nichts“ tutBeispielcode für OpenGl:

glMatrixMode( GL_PROJECTION );glLoadIdentity();gluOrtho2D(0, 1, 0, 1);glViewport(0, 0, WIDTH, HEIGHT );glMatrixMode( GL_MODELVIEW );glLoadIdentity();


Stefan Auer



GPU Version:

5) binde image als Textur, blurKernel als Fragment-Programm und blurImage als Render-Target

6) zeichne ein Full-Screen-Rechteck

glBegin( GL_TRIANGLES );glVertex2f(0, 0);glVertex2f(2, 0);glVertex2f(0, 2);glEnd();

„scr

een“

0 1

1

2

2


Stefan Auer


Was passiert?

- blurKernel wird für jedes Fragment einmal ausgeführt

- das Rendering ersetzt die äußeren beiden Schleifen der CPU-Version

- blurKernel führt für jedes Fragment9 Gather (p=a[i]) Operationen durch undgewichtet jeden Wert

- die „geblurrten“ Ergebnis-Pixel werdenin den Framebuffer bzw. in dieblurImage Textur geschrieben


Stefan Auer


GPGPU Techniken (1)

- Scatter Nachbildung- Problem: a[i]=p

- indirektes Schreiben- Position des Fragments kann

im Pixel-Shader nicht mehrgeändert werden

- Lösung 1: Auf Gather abbilden- erster Schritt: Kernel 1 ermittelt

Werte und speichert inZwischenergebnis

- zweiter Schritt: Kernel 2 sammeltZwischenergebnisse an derpassenden Stelle ein

1 2


Stefan Auer


GPGPU Techniken (2)

- Scatter Nachbildung- Lösung 2: Adresssortierung

- erster Schritt: Kernel 1 ermitteltWerte und speichert sie gemeinsammit Zieladresse in Zwischenergebnis

- zweiter Schritt: Kernel 2 führt aufdem Zwischenergebnis bitonic-sortnach Adressen durch

- dritter Schritt: Kernel 3 findet diepassenden Werte durch binäreSuche

1 9 5

8 1 3

3 6 5

1

1 1 3

3 5 5

6 8 9

2

1+1 3+3

5+5 6

8 9

3


Stefan Auer


GPGPU Techniken (3)

- Scatter Nachbildung- Lösung 3: Vertex Shader

- führe Rechnung im Vertex Shader durch

- Zeichne Punkte

- Vertex Position = Adresse

- führe Rechnung im Pixel Shader durch

- schreibe Adresse und Wert in Textur

- Zeichne Punkte

- lies Textur im Vertex Shader (Vertex Texture Fetch)und passe Position an Adresse an


Stefan Auer


GPGPU Techniken (4)

- Reduce- Problem: Reduktion der Wertanzahl durch

Zusammenfassung- Lösungen: Zeilen-/Spaltenweise, Blockweise

immer mehrere Passes notwendig

- Filtering- Problem: Reduktion der Wertanzahl durch entfernen

bestimmter Werte

- Sortierung- Lösung: Sorting Networks


Stefan Auer


GPGPU Techniken (5)

- Suche- Problem: Suche nach bestimmten Werten, Werten die

bestimmte Eigenschaften erfüllen oder Nachbarn von bestimmten Werten

- sinnvoll auf GPU bei vielen parallelen Suchen

- Datenstrukturen- Arrays und Matrizen (dicht- und dünnbesetzt)- adaptive Datenstrukturen (adp. shadow maps, octrees,…)


Stefan Auer


GPGPU Techniken (6)

- Branching- statisch

- vermeiden von Branches, wenn vorab bekannt ist welche Elemente betroffen sind

- Nutzung des z-Buffers- bedingte writes- Nutzung mathematischer Konstrukte als Branch-Ersatz- sinnvolle Verwendung der Branching-Unterstützung in

shader-model 3 und 4


Stefan Auer

Inhalt

1) Motivation







Stefan Auer


Grundlegende (aus der Mathematik):

- Differentielle Gleichungen & …

- gewöhnliche (ODE), z.B. für Partikel Systeme

- partielle (PDE), z.B. für Fluid Simulationen (Navier Stokes)

- … Lineare Algebra

- z.B. für numerische Simulation, Ray tracing, realtime Shading & Lighting


Stefan Auer


Allgemeine (1):

- Relationale Datenbanken

- Query-Beschleunigung z.B. durch beschleunigtes Join

- Simulation physikalischer Phänomene

- finite Differenzen & finite Elemente

- z.B. für Fluide (Flüssigkeiten, Gase)

- Signal- und Bildverarbeitung

- Segmentierung: Erkennen von „Objekten“(z.B. Tumor in medizinischen Scans)

- Computer Vision

- ...


Stefan Auer


Allgemeine (2):

- Global Illumination- Ray tracing- Photon mapping- Radiosity- Subsurface scattering


Stefan Auer


Havok FX

- entstanden durch Zusammenarbeit von Havok und Nvidia

- Nutzung der GPU für Effekt Physik in Spielen


Stefan Auer

Inhalt

1) Motivation







Stefan Auer

5) GPGPU alla Nvidia

Nachteile von Grafik APIs:

- sehr hohe Lernkurve für Nicht-Grafik-Entwickler- Pipeline?- Texturen? (sampler, filtering, blending)- Framebuffer?

- unpassende Abstraktionen für Nicht-Grafik-Programme- Vertices/Primitive/Fragmente + jeweils spezielle Programme dafür

- unflexibler Speicherzugriff- fehlendes Scatter

- zuwenig Kontrolle- (Grafik-) Treiber + API treffen wichtige Entscheidungen- Treiber ändern sich- Grafik-Optimierungen teilweise kontrapoduktiv


Stefan Auer


L2

FB

SP SP

L1

TF

Th

read

Pro

cessor

Vtx Thread Issue

Setup / Rstr / ZCull

Geom Thread Issue Pixel Thread Issue

Data Assembler

Host

SP SP

L1

TF

SP SP

L1

TF

SP SP

L1

TF

SP SP

L1

TF

SP SP

L1

TF

SP SP

L1

TF

SP SP

L1

TF

L2

FB

L2

FB

L2

FB

L2

FB

L2

FB

Quelle: Nvidia

Nvidia G80als GPU


Stefan Auer


Quelle: Nvidia

Load/store

Global Memory

Thread Execution Manager

Input Assembler

Host

Texture Texture Texture Texture Texture Texture Texture TextureTexture

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Load/store Load/store Load/store Load/store Load/store

Nvidia G80als GPGPU


Stefan Auer


CUDA

- Compute Unified Device Architecture

- Plattform für GPGPU auf Nvidia G80 (und höher)

- nutzt das C Subset von C++ (mit ein paar Erweiterungen) als Programmiersprache

- ersetzt (für GP-Anwendungen) Grafik API und Treiber

- CUDA und Grafik Anwendungen parallel möglich (OS-Multitasking)


Stefan Auer

CUDA Software Stack


CPU(Host)

Anwendung

CUDALibraries

CUDARuntime

CUDA Driver

GPU


Stefan Auer


CUDA aus Compiler-Sicht

- NVCC ist compiler driver (ähnlich gcc)

- NVCC verarbeitet CUDA Programme (.cu)

- Host-Code wird entweder extrahiert (-> .cpp) odersofort kompiliert (z.B. Visual Studio Kompilier)

- Device Code wird für PTX kompiliert

- PTX Code wird zur Installationszeit für dasjeweilige Device (z.B. G80) kompiliert


Stefan Auer


PTX- PTX: parallel thread execution

- virtuelle Maschine und ISA

- Programmiermodell

- Abstraktion von Ressourcen und State

- ISA: instruction set architecture

- formale Spezifikation des Verhaltens eines Prozessors aus Sicht des Programmierers

- PTX-Übersetzter ist optimizing compiler

- übersetzt PTX in Zielmaschinencode (z.B. für G80)

- wird zur Installationszeit ausgeführt

- CUDA Treiber implementiert die virtuelle Maschine

- stellt Übersetzer zur Verfügung


Stefan Auer


CUDA Programmiermodell

- GPU ist Coprozessor der CPU (CPU = Host)

- datenparallele Programmteile werden für die GPU kompiliert und dort als Kernel ausgeführt

- implizites Multithreadding: derselbe Kernel wird auf der GPU (hundertfach) parallel von (tausenden) Threads auf unterschiedlichen Daten (SIMD) ausgeführt

- eigener Speicher für CPU (host memory) und GPU (device memory); Hin-und-Her-Kopieren durch DMA

- indirekte Ressourcenverteilung (Threads, Register, Shared-Memory) durch Programmierer notwendig



Stefan Auer Zahlen gelten für GeForce 8800

CUDA Threadmanagement- Grid

- alle Threads führen denselben Kernel aus

- alle Blöcke haben die selben Dimensionen

- Block- zu jeder Zeit nur ein

Block aktiv auf jedem Multiprozessor

- alle Threads teilen sich Register (per Thread) und Shared Memory (per Block)

- Synchronisation zwischen Threads möglich

GridGrid

Grid

Block(0,0)

Block(0,1)

Block(0,2)

Block(0,3)

Block(1,0)

Block(1,1)

Block Block

Block(2,0)

Block(2,1)

Block Block

Block…

Block…

Block…

Block…

65535

65

53

5

BlockThread(0,0)

Thread(0,1)

Thread(0,2)

Thread(1,0)

Thread(1,1)

Thread(1,2)

Thread(2,0)

Thread(2,1)

Thread(2,2)

Thread Thread Thread

512

51

2

64

512


GPU


Stefan Auer Zahlen gelten für GeForce 8800

CUDA Threadausführung


Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Streaming Multiprocessor (SM)

SP 0

SP 1

SP 2

SP 3

SP 4

SP 5

SP 6

SP 7

Constant L1 Cache

SFU

SFU

Instruction Fetch

Instruction L1 Cache

Thread / Instruction Dispatch

Shared Memory

RF 0

RF 1

RF 2

RF 3

RF 4

RF 5

RF 6

RF 7

- ein Multiprozessor führt zu jeder Zeit nur einen aktiven Block aus

- ein Multiprozessor kann 8 Blöcke ausführen (scheduling)

- die Threads eines Blocks werden ausgeführt als „Warps“ a 32 Threads

- ein Multiprozessor kann insgesamt 24 Warps ausführen (scheduling)

- eine Instruktion benötigt pro Warp je nach Art zwischen 4 (z.B. FMADD) und 32 (z.B. IMUL) clock cycles


Stefan Auer

GPU


CUDA Speicherbereiche (1)


Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache


SP 0

SP 1

SP 2

SP 3

SP 4

SP 5

SP 6

SP 7

Constant L1 Cache

SFU

SFU

Instruction Fetch



Shared Memory

RF 0

RF 1

RF 2

RF 3

RF 4

RF 5

RF 6

RF 7

DeviceMemory

Constants(cached)

Textures(cached)

Global(uncached)

Local(uncached)

Jeder Thread kann:

- pro Thread Register Lesen/Schreiben

- pro Thread Local Memory L/S

- pro Block Shared Memory L/S

- pro Grid Global Memory L/S

- pro Grid Constant Memory nur L

- pro Grid Texture Memory nur L


Stefan Auer

GPU




Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache


SP 0

SP 1

SP 2

SP 3

SP 4

SP 5

SP 6

SP 7

Constant L1 Cache

SFU

SFU

Instruction Fetch



Shared Memory

RF 0

RF 1

RF 2

RF 3

RF 4

RF 5

RF 6

RF 7

DeviceMemory

Constants(cached)

Textures(cached)

Global(uncached)

Local(uncached)

Alle Threads eines Blocks teilen sich Shared Memory (per Block) und Register (per Thread)

-> verfügbare Registerzahl = Register pro SM / Threads pro Block

Kernel die mehr Register verwenden können nicht gestartet werden


Stefan Auer

GPU




Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache


SP 0

SP 1

SP 2

SP 3

SP 4

SP 5

SP 6

SP 7

Constant L1 Cache

SFU

SFU

Instruction Fetch



Shared Memory

RF 0

RF 1

RF 2

RF 3

RF 4

RF 5

RF 6

RF 7

DeviceMemory

Constants(cached)

Textures(cached)

Global(uncached)

Local(uncached)

Der Host kann:

- Constant Memory L/S

- Texture Memory L/S

- Global Memory L/S


GPU


Stefan Auer Zahlen gelten für GeForce 8800 GTX

CUDA Speicherbereichgrößen


Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache


SP 0

SP 1

SP 2

SP 3

SP 4

SP 5

SP 6

SP 7

Constant L1 Cache

SFU

SFU

Instruction Fetch



Shared Memory

RF 0

RF 1

RF 2

RF 3

RF 4

RF 5

RF 6

RF 7

DeviceMemory

Constants(cached)

Textures(cached)

Global(uncached)

Local(uncached)

- Register pro SM 8192 (-> 16-256 pro Thread)

- Shared Memory pro SM 16 kB

- Constant Memory 64 kB

- Constant Mem. Cache pro SM 8 kB

- Kernelsize 2 M Instr.

- Device Memory gesamt 758 MB


Stefan Auer

GPU


CUDA Synchronisation


Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache

Parallel DataCache


SP 0

SP 1

SP 2

SP 3

SP 4

SP 5

SP 6

SP 7

Constant L1 Cache

SFU

SFU

Instruction Fetch



Shared Memory

RF 0

RF 1

RF 2

RF 3

RF 4

RF 5

RF 6

RF 7

DeviceMemory

Constants(cached)

Textures(cached)

Global(uncached)

Local(uncached)

- keine Synchronisation zwischen Threads unterschiedlicher Blöcke

- Ausführungsreihenfolge generell undefiniert

- Scattersuppport -> Schreiben mehr als ein Thread an selbe Stelle (shared oder global)-> undefiniert

- Synchronisationspunkte (Barrieren)

- Atomare Operationen (Read-Modify-Write)(nur Compute Capability 1.1, nur 32 bit INT)


Stefan Auer


CUDA aus Programmierersicht (1)

C/C++ mit ein paar kleinen Erweiterungen:

- Spezifikation des Funktionstyps

- __host__, __global__, __device__

- Spezifikation des Variablentyps

- __device__, __constant__, __shared__

- Kernelausführungskonfiguration

- KernelFunc<<<500, 123>>>(...)


Stefan Auer


CUDA aus Programmierersicht (2)

Einige integrierte Variablen:

- gridDim, blockIdx, blockDim, threadIdx

zusätzliche Speicherverwaltungs-Funktionen

- cudaMalloc(), cudaFree()

- cudaMemcpy(), cudaMemcpy2D()


Stefan Auer


CUDA Beispiel: Matrix Mul- P=M*Njeweils mit Größe WIDTH x WIDTH

- jeder Thread behandelt ein Element aus P

- Nutzung nur eines Blocks-> WIDTH <= sqrt(512)

- schlechtes Verhältnis vonOPs zu Speicherzugriffen(ca. 1:1) -> keinMusterbeispiel

M

N

P

WID

TH

WID

TH

WIDTH WIDTH


Stefan Auer


Matrix Mul als Host (CPU) Programm

void MatrixMulOnHost(const Matrix M, const Matrix N, Matrix P){ for (int i = 0; i < M.height; ++i) for (int j = 0; j < N.width; ++j) { double sum = 0; for (int k = 0; k < M.width; ++k) { double a = M.elements[i * M.width + k]; double b = N.elements[k * N.width + j]; sum += a * b; } P.elements[i * N.width + j] = sum; }} M

N

P

WID

TH

WID

TH

WIDTH WIDTH


Stefan Auer


CUDA Matrix Mul: Hauptprogramm

int main(void) { // Allocate and initialize the matrices Matrix M = AllocateMatrix(MATRIX_SIZE, MATRIX_SIZE, 1); Matrix N = AllocateMatrix(MATRIX_SIZE, MATRIX_SIZE, 1); Matrix P = AllocateMatrix(MATRIX_SIZE, MATRIX_SIZE, 0);

// M * N on the device MatrixMulOnDevice(M, N, P);

// Free matrices FreeMatrix(M); FreeMatrix(N); FreeMatrix(P); return 0;}

M

N

P

WID

TH

WID

TH

WIDTH WIDTH


Stefan Auer


CUDA Matrix Mul: Host Funktion (1)

// Matrix multiplication on the devicevoid MatrixMulOnDevice(const Matrix M, const Matrix N, Matrix P){ // Load M and N to the device

Matrix Md = AllocateDeviceMatrix(M); // contains cudaMalloc() CopyToDeviceMatrix(Md, M); // contains cudaMemcpy() Matrix Nd = AllocateDeviceMatrix(N); CopyToDeviceMatrix(Nd, N);

// Allocate P on the device Matrix Pd = AllocateDeviceMatrix(P); CopyToDeviceMatrix(Pd, P); // Clear memory

...

M

N

P

WID

TH

WID

TH

WIDTH WIDTH


Stefan Auer


CUDA Matrix Mul: Host Funktion (2) ... // Setup the execution configuration dim3 dimBlock(MATRIX_SIZE, MATRIX_SIZE); dim3 dimGrid(1, 1);

// Launch the device computation threads! MatrixMulKernel<<<dimGrid, dimBlock>>>(Md, Nd, Pd);

// Read P from the device CopyFromDeviceMatrix(P, Pd); // contains cudaMemcpy()

// Free device matrices FreeDeviceMatrix(Md); // contains cudaFree() FreeDeviceMatrix(Nd); FreeDeviceMatrix(Pd);}

M

N

P

WID

TH

WID

TH

WIDTH WIDTH


Stefan Auer


CUDA Matrix Mul: Kernel// Matrix multiplication kernel – thread specification__global__ void MatrixMulKernel(Matrix M, Matrix N, Matrix P){ // 2D Thread ID int tx = threadIdx.x; int ty = threadIdx.y;

// Pvalue is used to store one matrix element computed by the thread

float Pvalue = 0; for (int k = 0; k < MATRIX_SIZE; ++k) { float Melement = M.elements[ty * M.pitch + k]; float Nelement = N.elements[k * N.pitch + tx]; Pvalue += Melement * Nelement; } P.elements[ty * P.pitch + tx] = Pvalue;}

M

N

P

WID

TH

WID

TH

WIDTH WIDTH


Stefan Auer


CUDA Performance Guidelines- auf hohe arithmetische Dichte achten

- Speicher Latenz verbergen (teilweise schon durch Compiler)

- Shared Memory (on chip) ausnutzen

- Cache-freundliche Speicherzugriffe

- Zugriff auf lokalen und globalen Speicher (uncached) meiden

- viele (tausende) Blöcke und Threads verwenden


Stefan Auer


Zukunft von CUDA- Nvida bietet spezielle GP Hardware an: Tesla

- Nächste GPU Generation (G90) bringt wichtige Änderungen für GPGPU (z.B. double precision), jedoch teils nur für Tesla


Stefan Auer


CUDA Bewertung+ für nicht grafiknahe Anwendungen besser geeignet als

Grafik-API

+ erstes Produkt das eine kritische Masse von Nicht-Grafik-Programmierern für GPGPU interessieren könnte

+/- Weiterentwicklung könnte von kommerziellem Erfolg der damit verbundenen Nvidia Produkte (Tesla) abhängen

- noch nicht ausgereift (Dokumentation mager, Programmierung könnte eleganter sein)

- setzt zwingend Nvidia GPUs voraus


Stefan Auer

Inhalt

1) Motivation







Stefan Auer

6) GPGPU alla AMD/ATI

data parallel virtual machine (DPVM) (1)

- Grundgedanken:

- Programmierer soll GPGPU-relevante Hardware möglichst direkt ansteuern können- command processor:

liest command buffer und verteilt Arbeit auf prozessor arrays- data parallel processor arrays:

Floating Point Prozessoren; führen nativen Binärcode aus- memory controler:

verwaltet GPU zugreifbaren Speicher; Anwendung trägt Verantwortung: Speicherbereiche und -Formate, Cach-Invalidierung

- rein grafikrelevante Hardware bleibt versteckt

- Standard-API und Treiber wird umgangen


Stefan Auer




Stefan Auer



- Implementierung für die X1k Serie heißt CTM (close to metal)- Beschreibung der Architektur (ISA, Ressourcen, etc.)- Runtime als low level Treiberkomponenten- Support Librarys

- command buffer Generierung- Speicherallokation- Assembler

- Implementierung von high-level-Tools (Programmiersprachen, Debugger, Bibliotheken) bleibt Dritten überlassen


Stefan Auer


DPVM/CTM Bewertung

+ interessant für Tool-Entwickler

+ ermöglicht low-level Optimierungen

- für viele Programmierer uninteressant, da ZU nah an Hardware (unausgereifter GPU-Assembler vs. ausgereiftes aber unpassendes Grafik-API)


Stefan Auer


mögliche GPGPU Zukunft bei AMD

- AMD Fusion- heterogene Mehrkernprozessoren- CPUs und GPUs auf einem Die- Performancesteigerung bei

Speicherzugriff denkbar

Speicher

CPU GPU

General Purpose Data Centric Graphics Centric Media Centric

Quelle: AMD


fin

stefan auer computer graphics & visualization graphics processing unit general purpose...

Documents