Djupdykning i Asynchronous Compute

@Yoshman: Tror att du målar fan på väggen, det är ju bara att ha två eller tre grenar, en till AMD en till Nvidia och en som fungerar på bägge.
Det är ju inte som att hela DX12 implementationen blir olika, det ger ju bara vissa fördelar i den kompilerade koden, jämför detta med kompileringsflaggor och bibliotek för olika CPU:r, skall vi ta bort detta också?

edit Jo just det, AoS kör på två grenar redan i dag.

Hittade detta i artikeln.

http://www.sweclockers.com/artikel/22436-djupdykning-i-asynch...
3-5 ms låter kanske inte mycket, men med en fps på 60, har varje bildruta mindre än 17 ms på sig att renderas, då pratar vi om en sänkning med 20-30% av renderingstiden, vilket skulle motsvara 25-40% högre prestanda.

Nu kommer det nog inte att ge fullt så mycket i de flesta fall, men vinsten är helt klar betydande.

I fallet 1) gissar jag att man inte ser tillräckligt stort värde i att gå utanför det HLSL/SPIR-V ger. I fallet 2) däremot borde både AMD och Nvidia ha egenintresse i att ge så stora fördelar till sin teknik att de lägger signifikanta resurser här. Inte alls säker att konsolerna väger upp det faktum att Nvidia har långt mer ingenjörer som jobbar med programvara jämfört med de som jobbar med kretsdesign.

Många verkar gilla att spy galla på Gameworks. Tittar man lite objektivt på det så är faktiskt renderingskvalitén kontra kostnaden i saker som FXAA, HBAO+, Waveworks m.fl. faktiskt minst lika bra som andra försök, det oavsett om man kör det på GCN, Kepler eller Pascal. En sådan sak som AO (ambient occlusion) är dyrt, så självklart kostar HBAO+ en del att slå på. Det kostar däremot ungefär lika mycket på alla arkitekturer och idag är faktisk alla Gameworks funktioner byggd ovanpå standard DX med HLSL så det fungera på alla GPUer.

Går garanterat att pressa ut lite mer ur kretsarna om man skippar HLSL, det kommer inte vara någon gigantisk mängd men säg att det är tillräckligt för att precis hamna före konkurrentens GPU i ett par titlar. PR värdet är då stort, värdet för användarna är mer tvivelaktigt och vi kan då se fram emot ett Gameworks som kanske bara fungerar på Maxwell och Pascal (dessa har väldigt snarlika funktioner, Kepler skiljer sig rätt mycket).

Som jag förstått det lilla jobbet att stödja både DX11 och OpenGL själva anropen mot de olika APIerna. Detta är rätt lätt att abstrahera. Den dyra delen är att konvertera HLSL till motsvarande GLSL.

Och det är absolut inte som att använda olika kompileringsflaggor, flaggor förändrar inte portabiliteten av källkoden medan användande av instricts i de flesta fall betyder att det överhuvudtaget inte går att kompilera koden för andra CPU-arkitekturer och potentiellt inte heller för vissa modeller av den en specifik arkitektur. Om jag t.ex. använder compiler instricts för AVX2 så kan inte programmet kompileras för något annat än Haswell och senare. Fungerar inte på någon annan CPU-arkitektur och inte heller på någon av AMDs nuvarande modeller eller Intel-modeller innan Haswell.

Säg att det blir populärt att använda "shader instricts functions", alla större spelmotorer får massor med optimeringar för AMDs och Nvidias nuvarande GPUer. Hur stor är nu inte tröskel för dessa företag att göra en förändring av ISA likt den AMD gjorde mellan VLIW4 och GCN eller den Nvidia gjorde mellan Tesla och Fermi?

Frågan är om vi inte redan ser en minskad vilja att ändra i ISA från båda lägren. GCN4 är identisk på ISA-nivå med GCN1.2. Skillnaden mellan GCN1.0 och GCN1.2 är inte speciellt stor, de är dock inte helt överlappande då man både tagit bort och lagt några enstaka saker mellan versionerna.

Skillnaden mellan Fermi, Kepler och Maxwell är rätt stor även om de i grunden använder samma ISA-format (skillnaderna här är betydligt större än mellan GCN1.0 och GCN4). Pascal verkar av allt att döma vara en strikt supermängd av Maxwell, det finns en del nya funktioner men allt som fungera på Maxwell ska även fungera på Pascal.

Huvudfrågan borde ändå vara: "marknaden" har efterfrågat ett standardiserat lågnivå API, vi har fått två sådana för PC i form av DX12 och Vulkan. Varför blanda in saker utanför standarden redan innan dessa teknik blivit varm i kläderna? Inte ens Apple som har total kontroll på sin plattform har blandat in något likt "shader instricts functions" i Metal (nog klokt då man kör Intel/AMD i macOS och PowerVR på iOS).

Så det är inte två grenar, det är minst tre. En för GCN (potentiellt uppdelad i GCN1.0 och GCN4 då det är de "stora" varianter då konsolerna kör med detta), en för Maxwell/Pascal och en generell för "resten". Ska alla ha en egen så ska även Intel skapa en egen gren, de har trots allt runt 70 % av GPU-marknaden på PC även om det kanske inte är förstahandsvalet för gamers.

Jag var ironisk och listade en del av Nvidias "damage controll", efter det uppdagats att Maxwell inte klarade "Async Shaders".

Fanns massor av typer på forumen som argumenterade sig blåa.

1. Maxwell klarar visst Async Shaders, det kommer snart stöd för detta via drivarna.

2. Dessutom ger inte Async Shaders någon prestandavinst.

3. Om det nu skulle ge någon prestandavinst ligger det långt i framtiden och då har Pascal släppts, då kan du byta ut ditt Maxwell mot ett Pascal.

4. Så du kan lugnt köpa ett Nvidia Maxwell, det är minst lika framtidssäkert som ett AMD GCN-kort.

--=====================================================================

Jag tror vi kan se lyft på 20-40% för GCN gentemot Maxwell, i de titlar som utvecklats för DX12 och Vulkan från början, alltså inte något DX11 med lite DX12 spackel på.

Ett 390x kommer kanske slåss mot ett GTX980Ti, det gör det redan i Doom (verkar varit en bugg i drivarna, senare resultat ger GTX980 Ti ett övertag på ca 15%).

Fördelen med högnivåspråk är att de kan kompileras till bytecode som passar olika platformar.
Fördelen med lågnivå är att man garanterat kan pressa ut varenda uns prestanda som finns att pressa ut med anpassad.

Att skapa möjligheten för att komma åt lågnivå betyder inte att möjligheten för högnivå försvinner eftersom den i slutändan kompileras till lågnivå.
Det kan fortfarande finnas högnivåspråk som genererar färdig bytecode för shaders för båda GPUerna. Det finns det t.ex idag. GLSL och HLSL.

Nvidia lär klarar sig från eventuella stämningar kring "async shaders" för Maxwell har absolut stöd för det på HW-nivå. Problemet med Maxwell tas ju bl.a. upp i denna artikel, man måste statiskt dela upp SM (StreamMultiprocessors, ett byggblock som i Maxwell och Pascal består av 128 CUDA-"kärnor") mellan de som hantera grafik och de som hanterar beräkningar. Gör man inte denna uppdelning perfekt så bestäms prestanda av den del som blir klar sist.

Möjligen kan man nu bli stämd då det verkar som Maxwell inte längre använder beräkningskön i HW utan man sammanfogar grafikkön (det DX12 kallar DIRECT queue) med beräkningskön (det DX12 kallar COMPUTE queue) till en HW-kö och slipper på så sätt dela upp SMs (DIRECT kön kan göra allt som COMPUTE kön kan så inget problem att posta jobb från den senare till en HW-kö som är kapabel att hantera den förra).

Pascal har alltså i grunden exakt samma stöd men med tillägget att kretsen kan dynamiskt konfigurera om alla SMs som jobbade på den del som blev klar först och flytta de till den andra uppgiften. Man kan nu få full beläggning på alla SMs och med rätt kombination av grafikjobb och beräkningsjobb (de ska stressa olika delar av GPUn för att ge en vinst) får man något högre total prestanda.

Effekten man specifikt får från att parallellt köra grafik och beräkningar är mycket riktigt över 30 % på konsoler, Uncharted 4 ska ligga upp mot 35 % vinst. På PC kommer vi aldrig se lika stor vinst som på dagens konsoler då den stora vinsten på konsol är att CPU-delen (inte GPU-delen) tenderar att vara flaskhals och man använder "async compute" för att avlasta CPU-delen. Gjorde man exakt samma sak på PC skulle prestanda bli lägre då man där i praktiken alltid har GPU-delen som flaskhals. Finns lite saker som kan öka effektiviteten på GPUn, är detta som ger runt 5-10 % ökning i Ashes of the Singularity (och det är fortfarande den speltitel som ser högst boost av "async compute").

Time Spy som i någon mening är en show-off benchmark för DX12 där AMD, Nvidia och Intel fått vara med och bestämma utformningen är den applikation på PC med överlägset störst boost specifikt från "async compute". Är runt 15 % på 390/390X/Fury/Fury X, runt 10 % för 480/380/380X, ca 5 % för Pascal och mindre än 5 % för GCN1.0 samt 0 % för Intel och Maxwell.

Att det pratas så mycket om "async compute" är nog en kombination av att det ger så mycket på konsoler, det är något som är relativt enkelt att stoppa in i existerande spel och det var något AMD kunde använda som slagträ mot Nvidia. Men faktum är att i de titlar det går att slå av/på "async compute" kan man kart och tydligt se att majoriteten av den boost man ser på AMDs GPUer kommer inte från "async compute" utan kommer från andra fördelar med DX12/Vulkan. Här har jag svårt att se hur vissa får det till Nvidia skulle ha problem med DX12/Vulkan, hur är det ett problem att man har så optimerade DX11/OpenGL drivare att man redan där har extremt hög nyttjande grad på GPUn? Kapaciteten på kretsen ökar ju inte bara för man byter API. Att AMD vunnit mer så här långt är ju inte förvånande när man tar i beaktande att t.ex. 390 har runt 50 % högre kapacitet på flera punkter jämför med 970, dessa två kort borde inte presterar så nära varandra som de historisk gjort.

Det stora värdet med DX12/Vulkan ligger i dess design som möjliggör mycket bättre användning av fler CPU-kärnor och lägre CPU-overhead. Detta förra är dock en nyhet som kräver att spelen designas från scratch mot detta API, är långt ifrån en snabbfix för existerande motorer. AMD ser redan idag en vinst här då man inte haft samma resurser att plöja ner i att optimera den gigantiska mängd kod som finns i dagens DX11 drivare. Men även för Vulkan och DX12 verkar Nvidia kommit förbi i effektivitet då t.ex. 1060 tenderar att utöka sin ledning (eller i fallet Doom/Vulkan, gå förbi) om man byter ut den överklockade 6700K/E-serie CPU som de flesta webbplatser testar med mot en långsammare CPU.

Säger inte emot på den punkten, men peka gärna på ett konkret exempel där det i slutändan visat sig vara en god idé att frångå standarder för att vinna några 10-tals procent i prestanda. Är inte alls säker att AMD kommer dra det längsta strået heller, man har inte i närheten lika mycket folk som jobbar med programvara som Nvidia (eller Intel). Faktum är att AMD rätt många gånger skapat intressanta HW-lösningar som aldrig blivit något för man inte har resurser nog att hantera programvaran som behövs.

Både Nvidia och Intel lägger rejäla resurser på att skapa programvara som de sedan "ger" bort (citationstecken då det i vissa fall inte handlar om öppen källkod men man tar inte betalt specifikt för programvaran). De har råd med det då ökningen i HW-försäljning tack vare programvaran väger med råge upp FoU kostnaden. AMD har gjort sig av med nästan all personal som kan ta den bollen, man får helt förlita sig till att jobbet sker ändå tack vare konsolerna.

Om man distribuerar koden som bytekod finns möjlighet att i efterhand optimera den genererade koden via drivers, en möjlighet som inte finns i en BLOB. En sak som både moderna JVMer och Nvidias DX11 drivare utnyttjar är JIT (just in time compilation). Där använder man indata kring t.ex. hur villkorade hopp har utfallit i praktiken och använder den informationen för att generera om maskinkoden. Detta nämndes som fördel för Java redan när det var i sin linda, tog ungefär 20 år av utveckling men idag finns flera fall där JIT:ad Java-kod är snabbare än motsvarande skrivet i C/C++ och sedan kompilerat.

Och visst kan man skriva snabbare saker i assembler, men idag är kompilatorer och JITs så bra och kretsarna så komplicerade så även de mest erfarna programmerarna skriver i genomsnitt sämre kod än kompileratorer/JIT. Genomsnittsprogrammeraren skulle aldrig lyckas skriva något i assembler som är än kod skapad av en modern kompilator.

DX12 - HLSL är ju en proprietär lösning, medans Vulkan - SPIR-V är en öppen lösning.
Vad är nyttan med att göra AMDs "Shader Intrinsic Functions" öppen? när dessa funktioner endast fungerar på AMDs hårdvara?

Som det står i GPUopen om detta så är just "Shader Intrinsic Functions" ett tillval "Extensions" till just SPIR-V och HLSL, detta kan användas ifall utvecklarna vill, för att få tillgång till den extra prestandan som finns. Så tror inte det är nåt fel på SPIR-V eller HLSL i sig.

Kan läsas om detta här: http://gpuopen.com/gcn-shader-extensions-for-direct3d-and-vul...

Eftersom jag inte utvecklat spel för konsoller, så vet jag inte vilka verktyg man har idag för XB1 / PS4. Det borde dock finnas en hel del erfarenhet som går att överföra till PC-sidan. Att ha en spelmotor som presterar 10% bättre än alla andra är helt klart ett försäljningsargument för de som licensierar ut sådana.

Nu pratar du så klart om större program. Jag hade inte velat skriva SAP eller AX i asm, men en shader är inte alls i samma storlek. På den gamla goda tiden så använde man sätt som xor ax,ax för att tömma ett register och spara klockcykler. Det är ett svagt exempel, eftersom det skulle kunna stoppas in i en kompilator också.

JIT är på många sätt bra, men dåligt på många. Android har ju kännt av detta. Det finns inget som säger att det inte skulle kunna finnas en AOT-kompilering av shadern vid start av applikationen. Det bästa hade varit en värld där man har möjlighet att köra olika paths, med inline-asm för specifik hårdvara.

Just när det gäller spel är prestanda superviktigt, så alla möjligheter för optimering bör då vara tillgängliga. Om det är någon som vill fördjupa sig och bli grym, låt dem bli det då.

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Huruvida något är en standard eller ej är helt ortogonalt mot huruvida det är öppet eller ej. Du använder t.ex. en icke fri standard i form av IEEE 802.3 för att läsa detta.

Det där verkar ju vara något som främst är tänkt att erbjuda en referensimplementation av en GLSL kompilator. Viktigt för OpenGL då man där distribuerar källkoden till shaders i stället för bytekod och en väldigt stor felkälla i OpenGL program har varit allt för stora skillnader mellan olika shaderkompilatorer.

Sedan verkar man också ha en beta-implementation av att generera SPIR-V (i OpenGL är normal output maskinkod för underliggande GPU ISA). Det kopplat med att man också har en HLSL front-end gör det möjligt att kompilera både GLSL och HLSL till SPIR-V. Kan vara användbart för Vulkan men det löser inte problemet att kunna använda sådan som är skrivet i HLSL i OpenGL-program då dessa program vill ha GLSL som indata.

Vad som skulle behövas är en s.k. "transpiler" som kan översätta direkt från HLSL till GLSL. Lär vara rätt hopplöst att göra en sådan som fungerar tillfredsställande.

Finns däremot långt mer hopp om att kunna göra bra verktyg som tar HLSL som indata och ger bra SPIR-V ut. I det fallet blir det ju enkelt att stödja både DX och Vulkan med samma källkod. Som jag förstått det är HLSL och SPIR-V väldigt lika i vad de kan göra och hur de uttrycker det, men har inte kollat på detaljerna.

Jag lovar dig, bryr mig väldigt om mitt hantverk. Fast det är CPU-relaterat, är rent formellt glad amatör vad det gäller GPUer.

Med AOT tappar man möjlighet till hotspot-optimeringar baserad på statisk från aktuell körning, så AOT kan aldrig bli snabbare än fallet där man direkt kompilerar från källkod till maskinkod. AOT, i dess tekniskt korrekta form, kräver också fortfarande bytekod vilket man inte har med de som använder "shader instricts functions".

Fördelen med AOT och på Android är att uppstartstiden blir mycket lägre. Också så att om man kör koden få gånger, är ju rätt vanligt att man kanske kör något bara en eller någon enstaka gång per invokering i en miljö som Android, så ger AOT mycket bättre energieffektivitet jämfört med JIT. För GPUer är energikostnaden för några extra CPU-cykler för JIT irrelevant och det normala är att shaders körs ju miljontals gånger.

Jämför man AOT med traditionell kompilering från källkod till binärkod har AOT ett par fördelar, framförallt på GPUer där det finns lite skillnader i ISA mellan olika modeller. Binärkod specificerar up-front exakt vilka instruktioner som kan användas. Med kompilering till byte-kod följt av AOT så sker AOT på den specifika plattformen i ett läge där man vet exakt vilken CPU/GPU man kör på och man kan därför lägga ut instruktioner som är specifik för just den CPU/GPU-modellen. D.v.s. om bara bytekoden har möjlighet att uttrycka det man vill uttrycka så kan man på t.ex. ett system med GCN1.2 lägga ut precis de instruktioner som man nu tydligen explicit måste lägga ut via instricts.

Sedan är inte instricts samma sak som att skriva assembler, lovar dig att exakt noll spelprogrammerare skulle ha tid, ork eller kunnande att skriva bättre GPU-assembler än dagens kompilatorer. Dessa kretsar är än värre än moderna CPUer att hantera på den nivån. Vad det handlar om är att den genererade bytekoden inte kan uttrycka vad man vill göra på ett sätt så översättningen till maskinkod faktiskt kan använda "rätt" instruktion, med instricts kan man då tvinga in sådana instruktioner där det är vettigt.

Är ju samma problem med språk som C, C++ och Java. Går inte att uttrycka saker som matrisoperationer på ett sätt där kompilatorn kan bevisa att SIMD-instruktioner är "safe", vill då använda sådana instruktioner får man lägga ut dem manuellt eller köra med ett språk som kan uttrycka detta eller använda någon teknik/tillägg i dessa språk som gör det möjligt (se nedan).

Spännande att se att ungefär samma grupp som skrikit sig hesa kring hur dåligt Gameworks är då det är proprietärt (vilket är sant, men tekniken är helt byggd på standard DX11/HLSL så det fungerar på alla GPUer) helt plötsligt inte ser det minsta problem med en teknik som "shader instricts functions" där huvudsyftet är att kunna använda finesser som är specifik till en viss GPU-familj eller till och med en viss GPU-version...

Framförallt när det finns rätt mycket erfarenhet av vad "instricts" i praktiken resulterar i på Linux, finns en del saker som teoretisk borde fungerar hur bra som helst på andra CPUer än x86 men där man använt SSE/AVX instricts. Rätt ofta visar det sig att även om det är tekniskt möjligt att göra samma sak med NEON på ARM eller AltiVec på PPC så är skillnaden i detaljer så pass stora att det inte händer. Numera finns det allt mer generella metoder, som OpenCL för CPU och vektor stöd i tekniker som Cilk+, där man kan uttrycka vad man vill göra på en lite mer abstrakt nivå som då gör det möjligt för en kompilator att generera lämpliga instruktioner för underliggande SIMD-stöd.

De hade uppenbarligen slagit på stödet tidigare under året, resultatet blev ju att t.ex. Ashes of the Singularity blev något långsammare då drivaren inte lyckades dela upp SMs på optimalt sätt.

Lågnivåprofilering av Time Spy visar att man använder både grafikkön och beräkningskön i DX12 på Maxwell (man gör det på alla GPUer, även Intel). Men det ser ut som att drivaren sedan internt serialiserar jobben från de båda köerna till en HW-kö, så man har uppenbarligen tagit bort HW-stödet.

Notera att detta är helt och fullt är möjligt att göra utan att bryta mot något krav i DX12. Asynkront betyder inte vad väldigt många verkar tro det betyder, denna artikel var exemplarisk i att explicit använda ordet "parallell".

DX12 kräver att jobb som postas på DIRECT måste förutsättas vara asynkrona med jobb som postas på COMPUTE kön. Det är en implementationsdetalj huruvida man väljer att utnyttja det faktum att jobben från olika köer är oberoende i tid (asynkrona) genom att köra dem parallellt. Så trots att Skylake helt saknar möjlighet att köra grafik och beräkningar parallellt är det fortfarande den krets som stödjer mest utan DX12, följt utav Pascal och Maxwell (är endast dessa som stödjer feature level 12.1, Skylake har i något fall högre "tier" nivå men det ändrar inte vad man kan göra men däremot hur stora dataset man kan jobba på utan att dela upp jobbet).

Så i korthet stödjer alla GPUer som har en DX12 drivare "async compute" om man förstår vad "async" syftar på. I Maxwell försökte man även utnyttja det till att köra saker parallellt, men Maxwells design hade bara tagit CUDA-applikationer i beaktande så är endast rena beräkningsjobb där man i praktiken får någon vinst.

Fördelen att göra så på Maxwell (och Intel) är att spelutvecklarna slipper göra två olika backends, man behöver bara tänka på att dela upp sakerna så de GPUer där det är vettig att köra saker parallellt kan göra det. Är då teoretiskt möjligt att ändra om saker i praktiken körs seriellt eller parallellt per speltitel via drivers.

Edit: länken du lade till är både rätt och fel.

Den är fel då kravet för en fullständig DX12 implementation är att man stödjer APIet samt minst feature level 11.0.

Den är i någon mening rätt då Maxwell vid det tillfället var den enda kretsen med stöd för feature level 12.1 vilket var (och är) den högsta funktionella nivå som definierats. Men allt över 11.0 är frivilligt!

Från länken

"but Maxwell sounds like it’ll be the first GPU to have all of the necessary hardware blocks to fully support all of DX12’s new features."

Numera stödjer även Skylake detta men Maxwell var först. Polaris 10 stödjer upp till 12.0 (samma som GCN1.2 då de är ISA-identiska). Föga oväntat finns det några nya saker i Gameworks som kräver 12.1, men är ju inte värre en att dessa inte går att slå på om man har en GPU som saknar 12.1 stöd.

Och faktum är att kretsen kan köra beräkningar och grafik parallellt, men det i praktiken ha visat sig vara bättre att köra dem i serie. Man ser också både på Pascal och GCN att vinsten att använda "async shaders" minskar ju färre kärnor man har och ju mer effektiv GPU- arkitekturen är (480 får mindre t.ex. boost än 380X).

Så visst hade det varit att föredra om redan Maxwell haft "dynamic allocation", men tittar man på Pascal så är det främst 1080 och Titan X som p.g.a. sina relativt stora antal CUDA-kärnor har lite problem att fullt ut nyttja alla resurser utan "async shaders".

Även för GCN så har ju 280X och nedåt i flera lägen visat noll eller till och med negativ effekt från "async shaders", det är inget att skrika om utan endast en naturligt konsekvens av varför tekniken överhuvudtaget kan ge ett positivt tillskott på PC (där man inte använder tekniken för GPGPU som på konsolerna).

Angående feature-level: hävdar inte att det har en relevant betydelse, Skylake dominerar ju och det har inte precis gjort den kretsen till "gamers choice". Säger bara att från båda sidor kastades det skit om att "den andra sidan stödjer minsann inte DX12 fullt ut". Båda sidor pratade i detta fall om något de uppenbarligen inte begrep. Att AMD och Nvidias PR-avdelningar försökte spinna det i fördel för sig själv borde de flesta klara av att genomskåda på teknikforumen kan man tycka.

Är väl medveten om att detta inte är en standard.

Därför dom gjort det till ett tillval "Extension", som är tillgänglig för utvecklarna, som kan använda detta om dom vill, för att få ut den extra prestanda som finns.

Om vi tar DOOM t.ex. så kan man använda openGL eller Vulkan, här är ju alla funktioner tillgängliga för alla GPUer, detta spel fungerar då på alla kort.
Vad är då problemet med att det finns "Shader Intrinsic Functions" för AMDs kort, för att ge lite extra prestanda?

Så länge det finns olika val, som gör att spelet fungerar på alla GPuer, så ser jag inget problem med det hela.

Om detta nu skulle vara ett så stort problem som du målar upp det till att vara, så får dom väll göra en meny där man kan aktivera/avaktivera denna funktion.