Az AMD két napja mutatta be a Radeon Vega Frontier Edition VGA-t, amelyről beszámoltunk, de sajnos ez több kérdést eredményezett, mint amennyit megválaszolt. Mára azonban sok extra adat kiderült, így nagyjából azt is tudni, hogy mi értelme ennek a Frontier dolognak. Az egészet az szülte meg, hogy az NVIDIA is rendelkezik egy amolyan prémium modellel a termékskálán belül, amely igazából se nem normál, se nem professzionális versenyző. Egyszerűen csak megpróbálja mindkét piac igényeit lefedni, és persze teszi ezt drágán, de eléggé sikeresnek mondható. Sokan kitalálhatták már, hogy a Titan VGA-król van szó, amelyek közül most a Titan Xp a leggyorsabb.
AMD Radeon Vega Frontier Edition [+]
Ezek a VGA-k természetesen a játékosoknak nem érik meg, mert ahhoz képest drágák, amit kínálnak, de megvan az a piaci rés, amit meg lehet velük célozni. A Radeon Vega Frontier Edition is ide érkezik, konkrétan a Titan Xp ellen. Ráadásul az AMD egy helyett két modellt is bedob, az egyiket lég-, míg a másikat vízhűtéssel. Mindkét verzió ugyanazt tudja, és a hírek szerint ugyanannyiba fognak kerülni, ez csupán egy választási lehetőség a potenciális vásárlóknak.
A specifikációk tekintetében az AMD igen kerekített adatokat adott meg, de mára kiderült, hogy a tesztkártya 1600 MHz-es órajelen üzemel, 64 multiprocesszor található benne, ami 4096 shader feldolgozót és 256 textúrázócsatornát jelent, illetve a blending egységek száma 64 lesz. A vállalat azért kerekített, mert még nem biztos, hogy a végleges PowerTune órajel 1600 MHz lesz, tehát inkább megközelítőleges számokkal operáltak. Feltételezve azonban azt, hogy 1600 MHz marad a végleges paraméter, kiszámolható a 13,1 TFLOPS-os szimpla pontosság melletti számítási teljesítmény, ami kevert pontosság mellett 26,2 TFLOPS lesz. A dupla pontosság tekintetében a shader tömbökön belül egy-egy olyan NCU lesz, amely támogatja ezt a módot, vagyis összesen négy, így az FP64-es tempó 819,2 GFLOPS. A 16 GB-nyi HBM2-es memória effektíve 1875 MHz-en fog működni, ami 480 GB/s-os memória-sávszélességet kínál.
Érkezett pár új mérés is a korábbi DeepBench adatok mellé. A SPECViewperf 12.1 teszten belül a catia-04 viewset (Catia), creo-01 viewset (PTC Creo) és az sw-03 viewset (Solidworks) alatt a Radeon Vega Frontier Edition rendre 135,75, 83,94 és 114,88 pontot ért el. Ezzel szemben a Titan Xp ugyanezekben a tesztekben rendre 107,29, 65,2 és 67,75 pontot szerez. A Radeon Vega Frontier Edition előnye tehát a közvetlen konkurensével szemben, professzionális szinten eléggé tetemes lehet, különösen a Solidworks esetében.
Az architektúráról is kiderült pár extra adat. Az AMD sokat beszélt az olyan újításokról, mint a HBCC, a primitive shader, a packed math, illetve az új raszterizáló (draw stream binning rasterizer), de nem derült ki, hogy ezek igényelnek-e direkt támogatást, vagy automatikusan működnek. Nos, a rendezvényről származó adatok alapján az új raszterizáló teljesen automatikus, gyakorlatilag minden ma elérhető és jövőben érkező alkalmazásban működni fog, de ez nem okozhat túl nagy meglepetést. A primitive shader már más lapra tartozik, mivel ehhez az alkalmazásba direkt támogatást kell építeni, ugyanakkor készül a DirectX 12 és a Vulkan API-hoz is olyan kiterjesztés, ami ezt lehetővé teszi. A primitive shader egyébként egy nagyon extra dolog, aminek ugyan az AMD partnerei részéről lesz támogatása, de leginkább arra jó, hogy a fejlesztők egyedi futószalagokat állítsanak össze. Ilyet nem sokan fognak csinálni, viszont egyértelműen a szabványosítás a cél, tehát hosszabb távon ez egy jelentős lépés lesz a piac számára.
A packed math is alkalmazás oldali támogatást igényel, viszont ehhez már most lehet igazodni, ugyanis az OpenGL és a Vulkan API esetében elérhető a GL_AMD_gpu_shader_half_float és a VK_AMD_gpu_shader_half_float, míg a DirectX 12-vel az AMD külön GPUOpen shader headert kínál. Ezek előnyeit egyébként nem csak a Vega (GCN5), hanem a Polaris generáció (GCN4), illetve a GCN3 architektúrára épülő Tonga és Fiji GPU-k, valamint a Carrizo és a Bristol Ridge APU-k IGP-je is tudja kamatoztatni. A packed math iránt eléggé érdeklődnek a fejlesztők, elvégre egyszerűen implementálható, és a GCN3-as, illetve GCN4-es GPU-kon 10-20% közötti gyorsulást hoz az adott shaderre, míg a GCN5-ös Vega generáción, még a GCN3/GCN4 opciókhoz képest is a kétszeresére gyorsítja a feldolgozási tempót. Ezen a ponton a Vega 10-es GPU minden korábbi megoldáshoz képest sok előnyt szerezhet. Gyakorlatilag amelyik játék használ majd a packed math optimalizálást, ott igazából megközelíteni is nehéz lesz a hardvert.
A HBCC-ről is nagyon sokat lehetett már hallani, de a legnagyobb kérdés, hogy milyen programokon fog működni. A legacy besorolású API-kkal (például DirectX 11 vagy korábbi) nem lesz gond, ezek eléggé egyszerűen működnek, és nagyrészt a meghajtó reszortja a memória menedzselése, tehát a HBCC ezekre nagyon egyszerűen aktiválható. A problémát a DirectX 12 és a Vulkan, azaz az explicit API-k jelenthetik. Alapvetően ezekkel sem lehet probléma addig, amíg a program nem használ valami nagyon egzotikus allokációs stratégiát. Technikailag ugyan kell rá a meghajtóba egy profil, de a működés tulajdonképpen biztosítható. Ugyanakkor a jövő szempontjából a HBCC az explicit API-k oldaláról direkt igényelhető lesz, vagyis a fejlesztőnek elég lesz majd kérni a programban a rendszer aktiválását, és a meghajtó az adott DirectX 12 vagy Vulkan API-t használó applikációt így fogja működtetni. Ennek a terjedésében azért bízhat nagyon a cég, mert a HBCC-s módot igényelni egy fejlesztőnek nagyságrendekkel egyszerűbb lesz, mint külön kiértékelni a program működését a Vega architektúrán, majd a felmerült problémákat manuálisan javítani. Utóbbi ugyanis jelentősen több időt és humánerőforrást vesz majd igénybe, mint szimplán a hardverre bízni az egész memóriamenedzsment működtetését. Általánosan elmondható, hogy a fejlesztők a legoptimálisabb, illetve sokszor inkább a legolcsóbb utat keresik az egyes GPU-architektúrák támogatása szempontjából és az jelen esetben egyértelműen a HBCC aktiválása, amivel megúszható a hardver manuális profilozása és optimalizálása.
A HBCC-t az AMD azért is szeretné a legnagyobb erőbedobással tolni, mert sajnos az elmúlt időszakból kiderült, hogy a fejlesztők nincsenek mindig a helyzet magaslatán, amikor a DirectX 12 és a Vulkan API-khoz program oldali memóriamenedzsmentet írnak a videomemória kezelésére. Annak ellenére, hogy ezt a modellt tulajdonképpen a programozók kérték, talán nem számoltak azzal, hogy ennyire nehéz lesz rá optimalizálni, így az egyes explicit API-t használó programok sokszor nagyon nem optimálisan bánnak a VGA-kon rendelkezésre álló fedélzeti tárral. Pedig az allokációk törlése ezúttal már olcsónak mondható az alacsony többletterhelésnek hála, de más problémák miatt komplex hibák ütik fel a fejüket, és a HBCC-vel az AMD ezektől teljesen meg tudna szabadulni, hiszen a nem túl optimális programkód helyett a hardver működtetné a memóriamenedzsmentet. Ez egyébként a fejlesztőknek sem rossz, mert a Vega GPU-kon való teszteléssel kaphatnának egy átfogó képet arról, hogy mennyit lehet még nyerni a manuális memóriamenedzsmentjük optimalizálásával, ami segíthetne meghozni bizonyos kritikus döntéseket a fejlesztés közben.
Végül arról is lehetett hallani, hogy a Vega architektúra tartalmaz még más újításokat is, amelyekről az AMD még nem beszél, de egy részük ezeknek is automatikusan működni fog, míg a másik részükhöz program oldali támogatást kell. A még titkolt újításokról azonban már csak a megjelenéskor lehet beszámolni.
