Home » Grafikkort » Efter grafik kommer der GPGPU
Efter grafik kommer der GPGPU

Efter grafik kommer der GPGPU

Share

Din gpu kan klare meget andet end at rendere Lara Croft ved 120 fps – magtkampen om dit grafikkorts hjerte holder liv i en branche, der jonglerer med mange milliarder dollars

Grafikkort har udviklet sig meget siden de tider, da vi havde 3dfx Voodoo-kort. Ingen forventer at se pipelines med fikserede funktioner nu om dage, men da 3D-acceleration dukkede op, var de nødvendige. De gode, gamle – og enkle – dage. Moderne grafikkort udgør den fagre nye verden. Programmerbare funktioner har åbnet for nye anvendelser, der går videre end rendering af polygoner. I dag eksisterer der hele serverfarme, som udelukkende kører masser af grafikkort og deres gpu’er.

I denne artikel dykker vi ned i de moderne gpu’ers verden. Vi undersøger, hvordan deres fleksible og superstærke nye udformninger med lethed kan udkonkurrere standardprocessorer og køre nye applikationer fra renderingsfarme og raytracing til kryptominedrift og deep-learning-applikationer.

Det er intet under, at Nvidia har set sin serverdivisions omsætning blive tidoblet på ganske få år – fra omkring 70 millioner dollars i 2016 til 700 millioner i dag. Det er stadig mindre end halvdelen af firmaets gaming-omsætning, men stigningen er et vidnesbyrd om, hvor vigtigt dette område er blevet for Nvidia, og hvor stor efterspørgslen er.

Bag al denne hardware er de softwareteknologier, der gør det muligt for udviklerne at udnytte gpu’ens muligheder på en fleksibel måde. Det betyder, at man kan bruge dem som alsidige processorer, der er kodet med højniveau-sprog, i stedet for specialiseret lavniveau-hardware, der kræver assembly-sprog for at kunne fungere.

På de følgende sider begiver vi os ud i alt dette – hvordan hardware arbejder så fantastisk hurtigt, hvordan softwaren sideløbende er blevet udviklet, og hvordan det hele bliver brugt på forbløffende nye måder.

Det er en smal sag for GPGPU’er at generere fraktaler.

Lad os begynde med hardwaren. Hvad har forvandlet fortidens specialiserede grafikkort med fikserede pipelines og fikserede funktioner til begrebet GPGPU (general-purpose graphics processing unit) og de monstercomputere, vi har i dag? Det enkle svar er shaders. Men det er naturligvis ikke det eneste svar. Samtidig med udviklingen af shaderhardware er procesteknologi og dermed grafikkortarkitekturens kompleksitet blevet ved med at stige eksponentielt. Det har også hjulpet, at der har været en stor efterspørgsel på den nye teknologi, også på nye områder.

Groft sagt havde en GeForce 256 (1999) 17 millioner transistorer på en 220 nm-proces, og en GeForce 2 (2000) havde 25 millioner transistorer på en 180 nm-proces; begge var DirectX 7.0-enheder uden shaders. DirectX 8.0 GeForce 3 (2001) fordoblede dette transistorantal til 57 millioner, til trods for at den i nogle situationer var langsommere end en GeForce 2 Ultra. Vi springer over GeForce 4, fordi den faktisk reducerede antallet af transistorer, og det ødelægger vores fortælling. DirectX 9.0 GeForce FX (2003, altså historisk set GeForce 5) skruede antallet af transistorer gevaldigt op til 135 millioner, og denne udvikling fortsætter i nutidens kort med milliarder af transistorer. Moores lov: Ikke overraskende, vel?

Raytracing trænger til lidt GPGPU-acceleration, og Blender er tilgængelig for alle.

Hvad laver alle disse transistorer? Du er sikkert klar over, at en shader i grunden er et meget lille og begrænset program, der kan bearbejde bestemte former for data, som er lagret af grafikkortet. Det er ikke vores ærinde her at tale om, hvordan en grafikpipeline virker, eller om grafikkortarkitektur, og det lader vi derfor stort set ligge. Men hvis man vil forstå en GPGPU’s funktioner og begrænsninger, er det nyttigt at vide lidt om shaders.

DirectX 8.0 (2000) introducerede forbrugerne for shaderteknologi – tænk blot på GeForce 3 og ATI Radeon 8500. Pixel- og vertexshaders blev indført som separate enheder, og de var superbegrænsede. Så kom v1.1-pixelshaderen, der var begrænset til en programlængde på 12 instruktioner og med kun 13 adresser og 8 farveoperationer at vælge imellem.

Vertexshaderen havde ingen branching og en programlængde på maksimalt 128 instruktioner. Da vi nåede frem til DirectX 9.0c (2005, Radeon X1x00 og GeForce 6) tillod specifikationen 65.536 eksekverede instruktioner, dynamic branch control og meget mere med Shader Model 3.0.

Kedelig, repetitiv matematik er en GPGPU’s levebrød.

Selv på dette niveau kunne man stadig betragte gpu’en som en fikseret pipeline; de smarte aspekter begyndte at dukke op i disse enkeltstående pixel- og vertexshaders, men man kunne stadig kun bruge dem til én opgave. Ikke desto mindre var potentialet til at få øje på. Prøv blot at tænke på det oprindelige ARM-instruktionssæt.

Det brugte en Reduced Instruction Set Computer-arkitektur, og det havde omkring 22 maskinkode-instruktioner (plus otte pseudooperationer), hvilket var nok til at køre en komplet desktopcomputer. GPGPU’s potentiale ligger i den enorme parallelisering, eksekveringshastighederne og den hurtige hukommelse – til trods for at den er begrænset til blot 12 instruktioner.

Hvad er en shader?

En shader er et lille program, der bliver kørt i gpu’ens pipeline, og som manipulerer enten individuelle pixel eller geometrien i verden på en eller anden måde. Udtrykket stammer fra den første anvendelse af shadere, der bestod i shading-algoritmer, for eksempel Phong-shaderen, der producerede pæne billeder.

Der er i grunden to forskellige former for shadere: pixel-shaders (eller “fragmenter” i OpenGL/Vulkan-jargonen) og vertex-shaders. Pixel-shaders fungerer ved enden af pipelinen, og deres output er en individuel pixels RGB- og Alpha-værdi.

Det, vi kalder vertex-shaders, manipulerer toppunkter i modeller (tre toppunkter udgør en trekant) til belysning og warping. Andre shaders – geometri, tessellation (fikseret funktion), hull, domain – drejer sig alle om at manipulere geometri i denne verden. Det er vigtigt at huske, at shadere er i stand til at bearbejde basale input og output tilbage til delt hukommelse, også kaldet Stream Output. I forbindelse med grafik gør Stream Output det muligt for gpu’en at oprette og animere partikelsystemer uden indblanding fra cpu’en.

Med en GPGPU bliver shaderne de programmerbare processorer i gpu’en. Tekstur-
enheder er et read-only-hukommelsesinterface, og output-framebufferen er write-only-hukommelsesinterfacet. En shaders basale operationer og det begrænsede input betyder, at en GPGPU brillerer, når man har et stort datasæt, som kræver gentagne beregninger med minimal afhængighed mellem dataelementer.

Med DirectX 10 (2007) er unified shaders blevet virkelighed. Teknologien havde udviklet sig nok til, at det var muligt at konstruere en enkel og tilstrækkeligt fleksibel computerarkitektur, som kunne håndtere pixel-, vertex- og geometrishading. For eksempel havde GeForce 8800 GTX, der blev lanceret i slutningen af 2006, næsten 700 millioner transistorer og understøttede DirectX 10.

På dette stade begyndte forskning i brugen af GPGPU-funktioner at levere praktiske løsninger. De første forsøg på at udnytte en gpu’s matrixmuligheder begyndte i 2001 med den første hardwareimplementering af de shaders, der dengang var til rådighed. Omkring 2005 var den første praktiske brug, der kørte hurtigere på en gpu end på en cpu, vidt udbredt. Det var en matrixoperation ved navn LU-faktorisering.

DirectX 11 blev lanceret som en del af Windows 7 i 2009, men der fandtes tekniske prøveversioner fra midten af 2008. Set fra vores standpunkt var det mest interessante aspekt computershaders, en ny specifikation, der var beregnet til ikkegrafiske applikationer, der skulle tilgå og udnytte gpu’ens ressourcer.

PhysX begyndte som en selvstændig teknologi, men GPGPU-funktionerne opslugte den.

Da man først fik shaders i hardware, var de så enkle, at udviklerne var villige til at håndskrive rutiner i assemblykode til dem. Det er dog langtfra ideelt, og i takt med at hardwareshadernes kompleksitet steg, skete det samme for softwareabstraktion, hvilket dækker over, at vi fik brug for sprogsupport på højt niveau.

Den første gæst ved API-festen var Nvidia med det raffinerede CUDA, der kom på markedet i juni 2007. Det er muligt, at dit eneste møde med CUDA finder sted i forbindelse med den anden Nvidia-teknologi, nemlig PhysX – kan du huske dengang, man kunne købe et separat tilføjelseskort til at skrue op for spiltempoet? PhysX begyndte som en selvstændig teknologi, men GPGPU-funktionerne opslugte den. Det er blot ét eksempel på en opgave, der er blevet GPGPU-accelereret.

CUDA begyndte primært med en kvik fyr ved navn Ian Buck, der blev ansat af Nvidia som direktør for firmaets GPGPU-division. Han havde på Stanford University udviklet et ph.d.-projekt, der hed BrookGPU, og det definerede et sprog til programmering af gpu’er. Det blev ejendommeligt nok grundlaget for OpenCL.

Hos Nvidia greb han chancen for at genoptage Brook og håndtere dets begrænsninger. Den vigtigste af dem var begrænsede hukommelsesadgang-mønstre. Nvidia C til CUDA-extensions eliminerede disse begrænsninger og leverede en enorm mængde threads, der kunne tilgå gpu-hukommelsen på den måde, som koderen ønskede, med en fuld implementering af C’s semantik. CUDA leverer et komplet udviklingssæt til programmering af Nvidias CUDA-kerner, herunder en compiler, debugger og biblioteker. Det understøtter C, Fortran til videnskabelige projekter, Java og Python. Det tilbyder også API’er til andre GPGPU-miljøer såsom OpenCL og Microsofts DirectCompute.

Sådan ser der ud inden i en moderne dyb læring-supercomputer-node. Bemærk Tesla V100’erne!

Nvidia var virkelig et skridt foran på markedet, og det var branchens foretrukne teknologi, når det gjaldt GPGPU-computerkraft. Nvidia var det første firma, der gik på markedet med sin egen højtflyvende implementering af en parallel computerplatform, og det gav Nvidia et forspring i forhold til alle andre. Det er en strategi, som Nvidia er ekspert i.

Heroverfor har vi OpenCL (Open Computing Language). Det er den åbne branchestandard for parallelt computerarbejde, der blev defineret af Apple – ejendommeligt nok meddelte Apple ved sin udviklerkonference i år, at man vil droppe support for OpenGL og OpenCL på alle Apples operativsystemer – og det bliver understøttet af alle (nu blot undtagen Apple), herunder Nvidia. Det er navnlig interessant for Alt om DATAs læsere, at dette er AMD’s valg af platform til sine stream-processorer.

Det kan man kalde super

I en lille fabrikshal bor computerkræfter på 3 exaops. Utroligt.

USA har genvundet førstepladsen for verdens hurtigste supercomputer. Det var ellers en titel, som Kina har forsvaret siden 2012 med Sunway TaihuLight og dens 10 millioner RISC-kerner og 93-teraflop. I hjertet af de 4600 servere, der driver Oak Ridge Summit-systemet, sidder to IBM Power9-processorer og seks Nvidia Tesla V100-gpu’er. Det er denne kombination, der sender beregningskapaciteten op på svimlende 200 petaflops – det er over 20 gange mere end hos Sunway.

Det, Summit repræsenter, er en kursændring blandt højtydende computere i retning af AI-baserede beregninger. AI bruger ofte enorme træningsmodeller og datasæt, der kræver gentagne beregninger ved høj hastighed. Summit repræsenterer med sin højeste halvpræcisions-hastighed på 3 milliarder operationer i sekundet 3 exaops AI. Hvis hvert menneske på Jorden foretog én beregning i sekundet, ville det tage 15 år at klare det, som Summit kan levere på ét sekund.

Gpu’er er idelle til disse moderne belastninger – for eksempel træningsmodeller til visuel genkendelse, der har til opgave at genkende en hund. Bearbejdelse af billeddata er perfekt til gpu-systemer, der er beregnet til at lagre teksturer ved utrolige hastigheder. Og en fin bivirkning af flytningen af belastning er en reduktion i det samlede antal servere, der kræves til en højtydende computerinstallation.

Det er sandsynligvis denne retningsændring i højtydende datacentre, som ligger bag den annoncerede nye gpu fra Intel, der forventes at blive lanceret i 2020, plus Intel Nervana Neural Network (NNP) til dyb læring, der kommer i 2019. Intel har i øjeblikket sine Xeon Phi-kort, men de er mange gange langsommere end Nvidia Tesla.

OpenCL blev lanceret lidt over to år efter CUDA i august 2009. Det kom altså ret sent, og dets mål var af lave programmer, som kunne køre på alle enheder, herunder standard-cpu’er, gpu’er, dsp’er, fgpa’er og andet. Det bygger på en implementering af C/C++, og der findes API’er til andre sprog, herunder Python, Java og .Net. Denne fleksibilitet betyder, at man endda kan få OpenCL til visse Android 7.1-enheder, og udviklerne kan afbalancere belastninger over flere gpu- og cpu-threads.

Det kan ikke undre, at det sent ankomne OpenCL med de mere åbne designmål havde indflydelse på dets tidligere ydelse i forhold til CUDA. En undersøgelse fra Delfts universitet fra 2011 har vist, at OpenCL led under en 30 procent lavere ydelse i forhold til CUDA-implementeringer, idet manuel justering dog kan reducere forskellen noget. Andre undersøgelser fra den samme periode sætter forskellen så højt som 67 procent.

Der er imidlertid sket fremskridt, og det ser ud til, at det er lykkedes nyere implementeringer, der kører på AMD-kort, at fjerne denne forskel i ydelse. En rapport fra 2017 (www.blendernation.com/2017/04/12/blender-cycles-opencl-now-par-cuda) for Blender 2.79 viste, at OpenCL er på linje med CUDAs ydelse, men CUDA er stadig det hurtigste valg til Nvidia-hardware.

TAGS
GPGPU
gpu
grafik

DEL DENNE
Share

Seneste Tech test
Seneste konkurrencer

Mest populære
Populære
Nyeste
Tags

Find os på de sociale medier

Modtag dagligt IT-nyhedsbrev

Få gratis tech-nyheder i din mail-indbakke alle hverdage. Læs mere om IT-UPDATE her

Find os på FaceBook

Alt om DATA

Lautrupsgade 7,
DK-2100 København Ø
Telefon: 33 91 28 33
redaktion@altomdata.dk

Datatid TechLife

Lautrupsgade 7,
DK-2100 København Ø
Telefon: 33 91 28 33
redaktion@datatid.dk

Audio Media A/S

CVR nr. 16315648,
Lautrupsgade 7,
DK-2100 København Ø
Telefon: 33 91 28 33
info@audio.dk
Annoncesalg / Prislister:
Lars Bo Jensen: lbj@audio.dk Telefon: 40 80 44 53
Annoncer: Medieinformation


Alt om DATA, Datatid TechLife  © 2019
Privatlivspolitik og cookie information - Audio Media A/S