GPGPU Architektúra esettanulmány
GeForce 7800 (2006)
GeForce 7800 Rengeteg erőforrást fordítottak arra, hogy a throughput-ot maximalizálják Azaz a különböző típusú feldolgozóegységek (vertex és fragment árnyalók) mindig dolgozzanak Ez pedig sok bottleneck-et hozott magával Ezért az NVIDIA (is) egységesítette az architektúrát
GeForce 8800 (2008 - Tesla)
GeForce 8800 processing element
GeForce 8800 shader core
GeForce 8800 Processing element Shader core egyetlen feldolgozó egység 128 van belőle 16 processing element egysége egy shader core kap meg egy feladatot ( <X> fragment shader futtatása ) Egyúttal megjelent a CUDA is
Fermi
NVIDIA GF100 - Fermi (2009) Az NVIDIA 2009-ben debütáló architektúrája Az előző generáció (GeForce 8) vezette be az egységesített architektúrát azaz innentől kezdve az NVIDIA GPU-knál is egységesített stream processzorok voltak előtte dedikált processzorok a különböző feladatokra (vertex és fragment programok futtatására) A Fermi már DirectX11 kompatibilis volt új kihívás például a tessellation shaderek támogatása (ez több, mint szteroid-kezelt geometry shader: utóbbinak sosem volt célja a nagymértékű geometriai generálása) A Fermi-nél a hangsúly a grafikus alkalmazások gyorsításán volt
Fermi architektúra Főbb építőelemei: GPC (Graphics Processing Cluster): grafikus feldolgozóegységek skálázható méretű tömbje SM (Streaming Multiprocessor): valahány streamprocesszor ( GPU mag, most: CUDA mag) csoportja. CUDA mag: konkrét végrehajtó egység. Minden SM-ben 32 van. Egységesített feldolgozóegység - ugyanúgy képes vertex, geometry, fragment és compute kernelek ( shaderek ) futtatására Konkrétan a GF100-nál (a GeForce 480-ban) 4 darab GPC mindegyikben 4 SM (azaz összesen 16 SM) 6 memóriavezérlő A CPU-hoz PCIe-n keresztül csatlakozott
CUDA mag FP: IEEE 754-2008, FMA INT: bool, shift, move,...
FMA
SM
SM 32 CUDA mag egysége 4 special function unit: transzcendens függvények kiértékelésére, grafikus szerelőszalag interpolációs lépéseit is ők végzik, egy órajel alatt egy szál egy utasítását hajtják végre => egy warp feldolgozása 8 órajel Két warpot tud egyszerre párhuzamosan feldolgozni (2x32 szál) A dual warp scheduler kiválaszt kettő warp-ot és mindkettőből 1 utasítást elküld (ha lehet - Fermin-n double-t pl. nem lehetett) 16 magnak, vagy 16 L/S egységnek, vagy 4 SFU-nak
SM Két végrehajtási blokkra (execution block) van osztva, 16-16 maggal Minden órajelben 32 utasítást adunk ki a végrehajtási blokkoknak (1 vagy 2 warpból) 2 órajel kell egy warp 32 utasításának lefuttatásához (L/S-nél is) 8 órajel alatt értékelődik ki 32 SFU utasítás
SM ütemezés
SM Minden SM-ben 4 textúrázó egység (TU) van Cache a textúrázónak Minden SM-hez L1 cache Igazából: minden SM-hez tartozik 64KB mem Ez kétféleképpen is beállítható: egy TU órajelenként 4 textúra mintát tud fetch-cselni ezeket szűrve is át tudja adni 16KB L1 + 48KB shared 48KB L1 + 16KB shared Renderingnél 16KB L1-es konfig megy
L2 cache 768KB, ami közös az összes SM-mel Írható, olvasható, koherens memória
Fermi működés Host interface: a CPU parancsokat olvassa GigaThread: a kért adatokat betölti a rendszermemóriából a framebufferhez a futtatandó szállakat blokkokra osztja és hozzárendeli SM-ekhez ezeket a szálakat aztán az SM-ek belső ütemezői osztják el SM: a hozzá rendelt szállakat 32-es csoportokban (warp-okban) futtatja a CUDA magjain
PolyMorph Engine Lényegében a grafikus szerelőszalag primitív feldolgozásának lépéseit vezérli 5 lépéses pipeline Az eredményül előálló primitíveket a raszterizáló engine-nek adja át
Raster Engine 4 Raster Engine működik párhuzamosan (GPC-nként 1 darab) 3 lépéses pipeline Az Edge Setup a háromszögek oldalainak egyenleteit határozza meg (és ezek végzik a backface culling-ot is) Órajelenként 8 pixelt ad ki minden Raster Engine A Z-cull nem pixel szinten, hanem tile alapon működik. Ha a tile minden pixele elbukja a Z-tesztet, akkor eldobja az egész tile-t.
Kepler
Kepler (2012) A Fermi utódja (GeForce 680) Teljesítménynövelés (főleg dupla pontosságnál) A fogyasztás is szempont már (új varázsszó: performance per watt )
Kepler felépítés 4 GPC 8 új SMX (újgenerációs SM) 4 memóriavezérlő
SMX 192 egyszeres pontosságú CUDA mag, FMA-val 32 SFU A magok GPU órajelen futnak Az SMX most már egyidőben 4 warp-ot tud ütemezni és végrehajtani Maga az ütemező is változott Egy szál most már akár 255 regisztert is elér
Memória A Fermihez hasonlóan konfigurálható 64KB-s memória per SMX +48KB-s read-only cache 1536KB L2 cache (amit minden SMX lát)
Maxwell
Maxwell (2014) Még jobb teljesítmény/fogyasztás arány volt a cél (performance per watt) Két generáció (GeForce 750, 8xx, illetve GeForce 9xx) Felépítés: 4 darab GPC 16 darab Maxwell SM (SMM) - 4 darab GPC-nként 4 memóriavezérlő Érdekes változtatások: memória sín: 192 bitről 128-ra SMM-ben CUDA magok száma: 192-ről 128-ra további egyszerűsítések
SMM 128 CUDA mag 1 PolyMorph Engine 8 textúrázó egység Felépítés: 32-es egységekben Minden 32-es egység dedikált ütemező erőforrással és utasításpufferrel rendelkezik egyszerűsítések, hogy kevesebb vezérlés kelljen Memória kiosztás revamp: L1 cache megosztva a textúra cache-sel 96KB dedikált osztott memória Az L2 cache 2048 KB
SMM 4 darab warp scheduler: Minden warp scheduler két utasítást tud egyszerre futtatni órajelenként adott 32 CUDA maggal dolgozik (korábban: közös kezelésben voltak a magok, kellett plusz hozzárendelés a warp schedulerek és a magok között) 8 L/S egység 8 SFU egység
Pascal
Pascal (2016) Számítási teljesítmény növelése (deep learning) 5.3 TFLOPS FP64-re (~double), 10.6 TFLOPS FP32-re (~float), 21.2 TFLOPS FP16-ra (~half) NVLink nagysebességű és sávszélességű összeköttetésekhez Módosított memória-architektúra
Pascal Az NVLink-et GPU-GPU adatátivelhez használják: 160 GByte/sec-es kétirányú sávszélességet ad
High Bandwidth Memory (HBM) A munkaállomásokba szánt Tesla P100-ban A HBM stack-elt memóriaelrendezés Lényegében több rétegnyi memórialapkát helyeznek egymásra, esetleg a legalsó szinten egy memóriavezérlővel irányítva egy-egy ilyen tornyot A HBM2-ben akár 8 réteg is lehet Akár ECC memória (!) Még az AMD kezdte el fejleszteni a HBM1-et 2008-ban
GDDR5X Memory A GeForce GTX 1080-ban
Memóriatömörítés A GPU-n az adatokat veszteségmentes tömörített formában tárolja a hw A textúráknál egy fontos séma a delta color compression (DCC): A DCC-ben a pixeleket blokkokban kezelik Minden blokkhoz tartozik egy referenciaszín A blokkbéli pixelek színét pedig az ettől a referenciaszíntől vett eltéréssel kódolják Pascal-ban új módok is vannak ehhez
Load balancing Bizonyos feladatok nem tudják lefoglalni a teljes GPU-t Ekkor akár kettő vagy több ilyen munka is futhatna a GPU-n (például a fizikai számítások a rendering-gel) A Maxwell előre felosztotta a fizikai hardvert egy részhalmazra ami grafikát, egy másikat pedig amit általános számításokat futtatott A Pascal-ban behozták ennek a dinamikus változatát
Simultaneous Multi-Projection Engine
Simultaneous Multi-Projection Engine
Pascal Egyetlen, közös virtuális memóriatér a CPU-nak és a GPU-nak (legalábbis 512 TB-ig) Compute preemption most már gépi műveletek szintjén működnek, nem Kepler/Maxwell szintű threadblock-okban
Pascal Egy teljes Pascal-ban 1 GPC-ben: 10 SM 1 SM-ben: 6 GPC 60 Pascal SM 30 TPC (mindegyik Texture Processing clusterben kettő SM) 8 darab 512 bites memóriavezérlő 64 CUDA mag 4 textúrázó egység Azaz összesen 3840 egyszeres pontosságú CUDA mag és 240 textúrázóegység
Források Fermi whitepaper: http://www.nvidia.com/content/pdf/fermi_white_papers/p.glaskowsky_nvidia's_fermi-the_first_complete_gpu_a rchitecture.pdf http://www.nvidia.com/content/pdf/fermi_white_papers/nvidia_fermi_compute_architecture_whitepaper.pdf Kepler whitepaper: https://www.nvidia.com/content/pdf/kepler/nvidia-kepler-gk110-architecture-whitepaper.pdf Maxwell whitepaper: http://international.download.nvidia.com/geforce-com/international/pdfs/geforce-gtx-750-ti-whitepaper.pdf http://international.download.nvidia.com/geforce-com/international/pdfs/geforce_gtx_980_whitepaper_fin AL.PDF Pascal whitepaper: http://international.download.nvidia.com/geforce-com/international/pdfs/geforce_gtx_1080_whitepaper_fin AL.pdf https://images.nvidia.com/content/pdf/tesla/whitepaper/pascal-architecture-whitepaper.pdf