Under de senaste åren har SoC GPU-utrymmet tagit en intressant väg, och en som jag visserligen inte förväntade mig. I början av detta decennium var spelplanen för SoC-klass GPU:er ganska varierande, med alla från NVIDIA till Broadcom (och allt däremellan) som deltog i det. Konsolidering i GPU-utrymmet skulle vara oundvikligt – något vi redan har sett när SoC-leverantörer hoppar av – men jag är förvånad över hur snabbt det har hänt. På bara sex år har antalet GPU-leverantörer med stor närvaro i avancerade Android-telefoner minskat till endast två: den vertikalt integrerade Qualcomm och den IP-licensierade ARM.
Att ARM har lyckats säkra det mesta av den licensierade GPU-marknaden åt sig själva är ett bevis på både deras ingenjörskonst och deras IP-licensiering. ARM:s väg in på denna marknad har varit otraditionell, efter att ha förvärvat en väsentligen okänd GPU-leverantör för ett decennium sedan, och odlat den till den 800lb-gorilla den nu har blivit. ARM:s expertis inom IP-licensiering, i kombination med en något ovanlig GPU-arkitektur, har visat sig vara en kraftfull kombination för företaget eftersom de har säkrat ett antal betydande vinster från high end till low end.
Mycket av denna tillväxt byggdes på baksidan av företagets GPU-arkitektur under de senaste åren, Midgard. Midgard, som ursprungligen lanserades 2012, har varit hörnstenen i ARMs design i Mali 600-, 700- och 800-serien. Som ARM:s första enhetliga shader-design för GPU:er har Midgard utökats under åren för att stödja nyare funktioner som geometriska tessellation och 10bpc färg, tillsammans med nyare API:er som OpenGL ES 3.1/3.2 och Vulkan.
Men när Midgard närmar sig sin fjärde födelsedag och SoC GPU-landskapet utvecklas, kommer Midgards tid på toppen snart att gå mot sitt slut. Mitt i bakgrunden av Computex 2016 och tillsammans med deras nya Cortex-A73 CPU, tillkännager ARM sin nästa generations GPU-arkitektur, Bifrost. En betydande uppdatering av ARMs GPU-arkitektur, Bifrost kommer först att distribueras i ARMs Mali-G71 GPU.
Sammanfattning: Mali & VLIW
En av de intressanta aspekterna av SoC GPU-utveckling genom åren är att det har varit ett mycket distinkt eko av större diskret GPU-utveckling. Många innovationer och förändringar som först dyker upp med dGPU:er kommer att dyka upp i SoC GPU:er några år senare, eftersom nyare tillverkningsprocesser tillåter dessa utvecklingar att passa inom de extrema utrymmes- och effektkraven för en SoC-klass GPU. Samtidigt följer mobilspel/grafikutveckling en liknande väg, där mobilapplikationsutvecklare plockar upp renderingstekniker som först användes någon annanstans.
ARM:s arkitektoniska utveckling har i sin tur varit ett bra exempel på denna process. Den icke-enhetliga Utgard-arkitekturen gav vika för den enhetliga Midgard-arkitekturen 2012, cirka 6 år efter att dGPU:er först gjorde övergången. Och som vi lärde oss när vi undersökte Midgard-arkitekturen på djupet, var Midgard en arkitektur väl lämpad för tidens renderingsparadigm.
Midgards shader-kärna, kort sagt, var en instruktionsnivå-parallellismcentrerad design, som använde ett instruktionsformat för mycket långa instruktioner (VLIW). För att uppnå maximalt utnyttjande av Midgards shader-kärnor behövde du kunna extrahera en betydande mängd ILP – 4 samtidiga instruktioner – för att fylla alla luckor i en shader-kärna. Den här typen av design är väl anpassad till grundläggande grafiska arbetsbelastningar, eftersom RGBA med fyra färger är en naturlig passform för de fyra banorna i ARMs VLIW-4-design. Dessutom är VLIW-designer traditionellt mycket utrymmeseffektiva, eftersom det finns relativt lite overheadlogik, vilket alltid är en välsignelse för de snäva begränsningarna i SoC-utrymmet.
Men för att återgå till det vi sa tidigare om att SoC GPU:er är ett eko av diskreta GPU:er, som vi har sett där, har VLIW en begränsad hållbarhetstid. Nyare renderingsparadigm fungerar ofta med bara 1 eller 2 komponenter samtidigt, vilket lämnar öppna banor som måste fyllas för att uppnå full GPU-användning. En bra shader-kompilator kan hjälpa till här, men det blir ett eskalerande teknikkrig med tiden, eftersom att få bra prestanda blir allt mer kompilatorcentrerad, och att skriva en kompilator som kan extrahera nödvändig ILP är en utmaning i sig. Vad historien har visat oss – och vad som kommer att hända igen på mobilmarknaden – är att renderingsarbetsbelastningar kommer att fortsätta att flyttas bort från en stil som är lämplig för VLIW.
