Id Software förklarar valet av OpenGL/Vulkan

Permalänk
Datavetare
Skrivet av Oaktree:

Kan ju inte endast vara dynamic load balancing some ger dess prestanda boost, isåfall ihop med preemption. Maxwell har ju bra mycket sämmre stöd för async compute till och med jämfört med gcn 1.0.

"Even with all of these additions, Pascal still won’t quite match GCN. GCN is able to run async compute at the SM/CU level, meaning each SM/CU can work on both graphics and compute at the same time, allowing even better efficiency."

Läs mer här: http://www.eteknix.com/pascal-gtx-1080-async-compute-explored...

Här är en article som jämför preemption på nvida, amd, intel. sägs här att amd har riktigt bra stöd för preemption.

Länk: http://www.dsogaming.com/news/oculus-employees-preemption-for...

Visst kan man länka till artiklar där folk gissar hej vilt. Men varför inte läsa vad AMD själva skriver, de borde väl ändå veta eller hur?

Nyheter i tredje generationens GCN (GCN1.2)

Citat:

Important differences between Generation 2 and 3 GPUs
...

  • Compute kernel context switching.

  • Compute kernels now can be context-switched on and off the GPU.

Hur mycket mer bevis vill behövs innan det med all önskvärd tydlighet framgår att alla som hävdar att Time Spy inte använder "async shaders" inte begriper vad tekniken innebär?

Notera att alla GPUer har möjlighet att byta uppgift mellan draw-calls, det som GCN1.2/4 samt Pascal har är preemption med betydligt bättre granulatet (är per pixel för grafik och per instruktion för compute i Pascal) och framförallt preemption med en väldefinierad latens (vilket är ett krav för att VR ska fungera väl).

Skrivet av sesese:

att AMD Fury ägare se +12% i prestandard i drivrutiner är grymt. Någon som har ett Nvidia kort som kan berätta om att samma sak hänt dom? Ok visst de som äger AMD 7000 serien har sett prestandaden öka med 50-100% via drivrutiner med det kortet är och för bli legendarisk som någon skrev. Den extrema ökningen kommer vi nog aldrig mer se för ett grafikkort.

den som byter kort varje år=köp Nvidia
Den som har grafikkortet mer än ett år AMD alla dagar. För du vet att du köpt något som är framtidsäkert. 7000 serien kom 2012 har bra stöd för vulkan/DX12. Nvidia 900 serien kom förra året stöd för vulkan/DX12?? se diagram för vulkan -% när AMD får upp till nästan +13%
Samma visa år efter år.

Nu kommer Nvida fan skrika AMD har inget som är snabbt nog! Då är det idag imorgon har AMD vandrat för bi än engång. Känns som det kommer att hända flera gånger till då man i AMD korten har mer prestandard än vad Nvidia korten har. Alla som köper 1060 och ska ha korten mer än ett år kommer att ångra sig varför de inte valde AMD 480.

http://www.pcper.com/files/imagecache/article_max_width/review/2016-07-19/3dmark-2016-timespy-3.png

Fury får inte 12 % bättre prestanda i Time Spy "från drivers". Anledningen att Fury får större boost än säg RX 480 och GTX 1080 är för att de andra två redan utan att använda "async shaders" har relativt hög nyttjandegrad av sin shader-array.

"Async shaders" är absolut en bra teknik, men ju mer logik en krets har för att minimera "execution bubbles" desto mindre effekt kommer man se från att använda "async shaders". Precis samma sak som med SMT där kretsar med väldigt mycket logik för att maximera enkeltrådprestanda rent praktiskt inte kan få samma boost från SMT jämfört med kretsar som "stallar" rätt ofta. Ursprungliga Atom (Bonnell/Saltwell) fick ofta 50 % boost av Hyperthreading medan "Core" serien typiskt ser 20-30 %, tror inte någon hävdar att Atom är bättre än Core-serien p.g.a. detta.

Visa signatur

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

Permalänk
Skrivet av kira9204:

Skitsnack, anledningen till att AMD skalar så otroligt mycket bättre med Vulcan gentemot nVidia är för att AMDs OpenGL implementation varit kass med många bottlenecks.
nVidia står helhjärtat bakom Vulcan och lanserade t.om support för det före AMD.

Ehh???
AMDs vulkanimplementation är väl bra för att det är en bra vulkanimplementation? Den relativa skillnaden blir större pga mindre bra OGL tidigare men har ingen inverkan på den absoluta prestandan.

Permalänk
Skrivet av GilbertG:

Gameworks funkar ju så att det sabbar för alla, men väsentligt mycket mer för AMD. Men Vulkan kan man lägga till extrafunktioner som fungerar på vissa chip/arkitekturer utan att det sabbar för resten.

Titta på senaste Hitman. En AMD-titel som briljerar på AMD-kort, men fungerar fortfarande bra på NVidia.

Jag har svårt att se hur ett sånt tillägg skulle vara implementeras! De enda tillägg jag sett hittills är till för utveckling, dvs kontroll av att data är korrekt och att API:et får rätt argument.

Permalänk
Skrivet av Yoshman:

Nackdelen med "low-level" APIer är att mycket av detaljerna som tidigare endast berörde de som skrev drivare nu hamnar i knät hos spelutvecklarna.

Bara initialt, lär bli så att bara spelmotortillverkare grottar på lågnivå.

Skrivet av Yoshman:

AMD har en riktigt bra presentation kring vilka problem utvecklar stött på så här långt när de jobbar med Vulkan. Det problem du ser är ett fall av detta

Detta är inte specifikt till Vulkan, nästan allt som står i den presentationen gäller även för DX12.

Medhåll, riktigt bra presentation.

Permalänk
Skrivet av Orisons:

@FBGKimpan: Kan dom inte bara köra Open gl då? Är nvidia sämre på Open gl än AMD?

Klart det går om man gillar retroAPI:er. Och Nej, nvidia är i mitt tycke klart bättre på OGL.

Men nu försöker vi vara framåtblickande.

Permalänk
Skrivet av Oaktree:

Är det detta du menar så verkar det som 3Dmark Time Spy endast stödjer pre-emption alltså att arbeten prioriteras och växlar mellan olika job alltså inte riktig multi-thread, detta stödjs på både amd och nvidia. Men amd stödjer Asynchronous Shaders vilket betyder att flera arbeten kan köras samtidig t.ex. compute och shaders "asynchronous" vilket är som multi-threaded på CPUs.
Länk: http://www.overclock-and-game.com/news/pc-gaming/50-analyzing...

Om Dx11 är 50% snabbare än vulkan i Talos Pricipel så är det nog en dålig implementerin av Vulkan, då DX11s Multi-threded är liknande DX12 och vulkans "pre-emption" att olika jobb prioriteras och växlar mellan olika jobb, medan Asynchronous Shaders kan jämföras med riktig multi-threded, alltså köra flera arbeten samtidigt.
Läs mer här: http://wccftech.com/async-shaders-give-amd-big-advantage-dx12...

Detta stämmer till viss del Amd hade sämmre implentation av OpenGL drivers men det är inte endast detta som gör att amd ligger såpass mycket före i Vulkan då Nvidia korten saknar "Asynchronous Shaders" läs ovan svar för mer info.

Amd:s kort har stöd för "Asynchronous Shaders" vilket nvidia korten saknar, detta ger Amd:s kort kompabilitetan att köra flera jobb samtidigt "Multi-threded", läs ovan svar för mer info.

Min hypotes är att nvidia inte "offrar" ngn kiselyta på en scheduler. AMD har Asynchronous Compute Engine och ARM verkar ha Inter Core Task Manager. De verkar dessutom ha scheduling på instruktionsbuntsnivå (Terminologin är visst clause). ImgTec verkar ha Course Grain Scheduler i sina diagram.

Men som sagt, det är enbart en hypotes.

Permalänk
Datavetare
Skrivet av GilbertG:

Gameworks funkar ju så att det sabbar för alla, men väsentligt mycket mer för AMD. Men Vulkan kan man lägga till extrafunktioner som fungerar på vissa chip/arkitekturer utan att det sabbar för resten.

Titta på senaste Hitman. En AMD-titel som briljerar på AMD-kort, men fungerar fortfarande bra på NVidia.

Så vitt jag vet kan man i var enda titel som använder sig av Gamework slå av/på varje enskild finess som implementeras m.h.a. Gameworks. Du som användare är alltså helt i kontroll över att göra valet om du anser att kostnaden för att slå på en viss finess uppvägs av förbättringen i upplevelse. Då Gameworks är implementerat uteslutande ovanpå standardfunktioner i DX11/12 så fungerar också alla finesser på alla kort som korrekt implementerar dessa APIer.

Med AMDs "shader intrinsics" går man utför vad som är möjligt med HLSL och SPIR-V (standarderna för att beskriva shaders i DX resp. Vulkan) och får något som är bundet till GPUer som implementerar det man valt att använda. Specifikt i Doom (som är första titel att använda detta) avgörs valet huruvida jag kan använda funktionen som implementeras med tekniken helt av om min GPU stödjer "rätt sker" eller ej. Om den inte gör det kan man överhuvudtaget inte använda finessen om det inte finns en "fallback path", vilket för Doom saknas för tillfället (men gissar att det är vad man jobbar på för Pascal då det enligt rykten ska komma "async shaders" under Vulkan även där).

Personligen har jag full förståelse för varför AMD pushar "shader intrinsics", men svårt att få ihop logiken i ditt påstående.

Hitman använder inte "shader intrinsics" (det finns för tillfället inte för DX12). AMDs kort presterar bättre än motsvarande Nvidia både i DX11 och DX12, så denna titel använder rent generellt saker som passar bättre för GCN. Witcher 3 använder ju Gameworks och presterar "trots" det ändå riktigt bra på kort från båda lägren.

Visa signatur

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

Permalänk
Datavetare
Skrivet av CamelCase:

Bara initialt, lär bli så att bara spelmotortillverkare grottar på lågnivå.

Inte bara initialt. Tänk om/när AMD och Nvidia släpper sin nästa generation kretsar som skiljer sig på fundamentala punkter från dagens. Med DX11/OpenGL kan man via drivers, till viss del, kompensera för skillnader i beteende m.h.a. drivers då funktionerna som exporteras via DX11/OpenGL är ganska abstrakta.

Dessa abstraktioner kostar naturligtvis något och i flera fall måste DX11/OpenGL drivare gissa vad programmeraren kommer göra och m.h.a. heuristik försöka göra "något optimalt". Att få till detta på ett bra sätt kräver väldigt mycket resurser och är en stor anledning till alla drivarsläpp med "spelspecifika optimeringar". Det är ändå optimeringar som typiskt händer då det ligger i AMDs/Nvidias intresse att spel presterar bra på deras kretsar.

Hela poängen med DX12/Vulkan är att allt detta gissande ska tas bort då det möjliggör en rad nya optimeringar. Men dessa är inte på något sätt automatiska och mellan kretsar som skiljer sig på fundamentala punkter kan det vara olika saker som är optimalt. Det ligger nu på spelutvecklarna att optimera för alla relevanta kretsar, frågan kvarstår hur mycket det kommer resultera i att endast de senaste kommer få bra stöd medan mindre populära modeller och äldre modeller totalt ignoreras.

Tror i.o.f.s. övergången till DX12/Vulkan bl.a. kommer medföra att både AMD och Nvidia aktar sig för att ändra speciellt mycket i sina kretsar. AMD har redan gjort referenser till att GCN är lite som x86, det kommer endast bli små inkrementella förändringar och där majoriteten av designen står fast.

Och självklart är DX12/Vulkan rätt för framtiden, det är en mycket bättre modell för att programmera dagens GPUer än DX11/OpenGL. Framförallt OpenGL designades för en helt annan typ av GPUer än vad vi har idag.

Visa signatur

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

Permalänk
Medlem
Skrivet av Yoshman:

Visst kan man länka till artiklar där folk gissar hej vilt. Men varför inte läsa vad AMD själva skriver, de borde väl ändå veta eller hur?

Nyheter i tredje generationens GCN (GCN1.2)

Hur mycket mer bevis vill behövs innan det med all önskvärd tydlighet framgår att alla som hävdar att Time Spy inte använder "async shaders" inte begriper vad tekniken innebär?

Notera att alla GPUer har möjlighet att byta uppgift mellan draw-calls, det som GCN1.2/4 samt Pascal har är preemption med betydligt bättre granulatet (är per pixel för grafik och per instruktion för compute i Pascal) och framförallt preemption med en väldefinierad latens (vilket är ett krav för att VR ska fungera väl).

Fury får inte 12 % bättre prestanda i Time Spy "från drivers". Anledningen att Fury får större boost än säg RX 480 och GTX 1080 är för att de andra två redan utan att använda "async shaders" har relativt hög nyttjandegrad av sin shader-array.

"Async shaders" är absolut en bra teknik, men ju mer logik en krets har för att minimera "execution bubbles" desto mindre effekt kommer man se från att använda "async shaders". Precis samma sak som med SMT där kretsar med väldigt mycket logik för att maximera enkeltrådprestanda rent praktiskt inte kan få samma boost från SMT jämfört med kretsar som "stallar" rätt ofta. Ursprungliga Atom (Bonnell/Saltwell) fick ofta 50 % boost av Hyperthreading medan "Core" serien typiskt ser 20-30 %, tror inte någon hävdar att Atom är bättre än Core-serien p.g.a. detta.

Så att Fury får 12-13% mer prestandard betyder inte att kortet blir snabbare mot Nvidia korten eller hur menar du nu?? Som jag ser det så visar det än en gång att Nvidia stannar men AMD korten bara levererar år efter år.

För det är inte så att Nvidia lämmar sin gamla serie när den nya kommer. Då i princip inga "gamla 900,700,600" nvidia kort får någon fördel av nya drivrutiner är det märkligt.

Visa signatur

Ryzen 5800X ROG STRIX X570-f GAMING FlareX DDR43600 cl 14-14-14-34 EVGA FTW3 Ultra RTX 3090

Permalänk
Datavetare
Skrivet av sesese:

Så att Fury får 12-13% mer prestandard betyder inte att kortet blir snabbare mot Nvidia korten eller hur menar du nu?? Som jag ser det så visar det än en gång att Nvidia stannar men AMD korten bara levererar år efter år.

För det är inte så att Nvidia lämmar sin gamla serie när den nya kommer. Då i princip inga "gamla 900,700,600" nvidia kort får någon fördel av nya drivrutiner är det märkligt.

Det vad inte vad jag skrev, påpekade bara att de 12-13 % kommer inte från drivers utan från att "async shaders" kan användas för att minska tiden shaders är "idle". Då Fury har mindre kretsyta dedikerad till att minska "pipeline bubbles" jämfört med RX 480 och GTX 1080 kan Fury potentiellt få en större boost av "async shaders". Det var enda poängen.

Visa signatur

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

Permalänk
Skrivet av Yoshman:

Så vitt jag vet kan man i var enda titel som använder sig av Gamework slå av/på varje enskild finess som implementeras m.h.a. Gameworks. Du som användare är alltså helt i kontroll över att göra valet om du anser att kostnaden för att slå på en viss finess uppvägs av förbättringen i upplevelse. Då Gameworks är implementerat uteslutande ovanpå standardfunktioner i DX11/12 så fungerar också alla finesser på alla kort som korrekt implementerar dessa APIer.

Med AMDs "shader intrinsics" går man utför vad som är möjligt med HLSL och SPIR-V (standarderna för att beskriva shaders i DX resp. Vulkan) och får något som är bundet till GPUer som implementerar det man valt att använda. Specifikt i Doom (som är första titel att använda detta) avgörs valet huruvida jag kan använda funktionen som implementeras med tekniken helt av om min GPU stödjer "rätt sker" eller ej. Om den inte gör det kan man överhuvudtaget inte använda finessen om det inte finns en "fallback path", vilket för Doom saknas för tillfället (men gissar att det är vad man jobbar på för Pascal då det enligt rykten ska komma "async shaders" under Vulkan även där).

Personligen har jag full förståelse för varför AMD pushar "shader intrinsics", men svårt att få ihop logiken i ditt påstående.

Hitman använder inte "shader intrinsics" (det finns för tillfället inte för DX12). AMDs kort presterar bättre än motsvarande Nvidia både i DX11 och DX12, så denna titel använder rent generellt saker som passar bättre för GCN. Witcher 3 använder ju Gameworks och presterar "trots" det ändå riktigt bra på kort från båda lägren.

"shader intrinsics" verkar juh mest vara behändiga builtins. Flera av dem verkar dessutom vara halvvägs i standardiseringsarbetet av suffixen att döma. Så jag ser ingen gamechanger här.

Permalänk
Datavetare
Skrivet av CamelCase:

"shader intrinsics" verkar juh mest vara behändiga builtins. Flera av dem verkar dessutom vara halvvägs i standardiseringsarbetet av suffixen att döma. Så jag ser ingen gamechanger här.

Finns en skillnad från de flesta "builtins" i GCC. Om jag använder t.ex. __builtin_ffs på en CPU som saknar en specifik assemblerinstruktion för att hitta första biten som är satt så lägger kompilatorn ut motsvarande instruktioner. D.v.s. det kommer alltid att fungera men är mindre effektivt på CPUer som inte direkt stödjer funktionen. Detta är mer likt vad Gameworks gör, allt kommer fungera men vissa operationer är dyrare på GPUer som saknar vissa funktioner och där man (DX infrastrukturen) får ta en lite längre väg.

"shader intrinsics" är helt analogt med GCC Compiler Intrinsics för t.ex. SSE/AVX. Det ger mig som C/C++ programmerare något som passar väl ihop med språket C/C++ (d.v.s. man använder SSE/AVX funktioner som helt vanliga C anrop), men även fast ARM stödjer motsvarande funktioner via NEON så kommer något där man använder SSE/AVX intrinsics överhuvudtaget inte gå att kompilera för ARM, kompilerar inte heller för en x86 CPU som saknar någon av de instruktioner man använt.

Visa signatur

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

Permalänk
Skrivet av Yoshman:

Finns en skillnad från de flesta "builtins" i GCC. Om jag använder t.ex. __builtin_ffs på en CPU som saknar en specifik assemblerinstruktion för att hitta första biten som är satt så lägger kompilatorn ut motsvarande instruktioner. D.v.s. det kommer alltid att fungera men är mindre effektivt på CPUer som inte direkt stödjer funktionen. Detta är mer likt vad Gameworks gör, allt kommer fungera men vissa operationer är dyrare på GPUer som saknar vissa funktioner och där man (DX infrastrukturen) får ta en lite längre väg.

"shader intrinsics" är helt analogt med GCC Compiler Intrinsics för t.ex. SSE/AVX. Det ger mig som C/C++ programmerare något som passar väl ihop med språket C/C++ (d.v.s. man använder SSE/AVX funktioner som helt vanliga C anrop), men även fast ARM stödjer motsvarande funktioner via NEON så kommer något där man använder SSE/AVX intrinsics överhuvudtaget inte gå att kompilera för ARM, kompilerar inte heller för en x86 CPU som saknar någon av de instruktioner man använt.

När jag kollar på "shader intrinsics" så tycker jag att allt ser ut att ligga på samma abstraktionsnivå som ffs. Dvs arkitekturer som inte har opcodes som matchar kan matas med en instruktionssekvens.

Att kunna köra max(a, max(b, c)) som en instruktion är rättså cute!
Om det implementeras med cmove så är det awsome!

Permalänk
Datavetare
Skrivet av CamelCase:

När jag kollar på "shader intrinsics" så tycker jag att allt ser ut att ligga på samma abstraktionsnivå som ffs. Dvs arkitekturer som inte har opcodes som matchar kan matas med en instruktionssekvens.

Att kunna köra max(a, max(b, c)) som en instruktion är rättså cute!
Om det implementeras med cmove så är det awsome!

FFS kan implementeras med rimlig effektivitet även om en CPU saknar det. Anledningen att man inte gör samma sak med t.ex. VFMADD213SS ($0 = $1×$0 + $2 för varje "lane" i AVX-register) trots att det absolut är fullt tekniskt möjligt att låta kompilatorn lägga ut instruktioner som har motsvarande semantik, är inte ens speciellt kompicerat, beror på att man överhuvudtaget inte skulle implementera den operationen med den minneslayouten för operander om man inte använder AVX då det finns långt mer effektiva metoder att göra det.

Var precis sådana saker man var tvungna att fixa mellan det som var Mantle till det som blev Vulkan. Vissa sakar i Mantle var designade så att de absolut kunde implementeras på andra GPU-arkitekturer, men som Mantle specificerade finessen kunde det i praktiken bara göra effektivt på GCN.

Ta en sak som mbcnt, det går inte att göra på något effektivt sätt om GPU ISA inte har en direkt motsvarighet. Rent logiskt kan man absolut få till samma sak, men hela poängen med att använda något som mbcnt är för att det är något mer effektivt än vad man skulle få som resultat om man kompilerade motsvarande logik med standard DX12/Vulkan funktioner.

Så med DX12/Vulkan får man något som är hyfsat optimalt på alla GPUer. Med "shader intrinsics" för GCN får man något som är optimalt för GCN men betydlig ineffektivare än motsvarande skrivit med DX12/Vulkan, så är helt meningslöst för Intel/Nvidia att ens försöka lägga in kompilatorstöd för att hantera det Doom nu använder "shader intrinsics" till. Rätt lösning är i stället att skriva motsvarande funktion med standardfuktioner i Vulkan alt. med "shader intrinsics" för ISA för respektive GPU. Det sista får vi hoppas inte händer, då är vi ett steg mot 3D teknikens linda med Glide FX och liknande (fast nu för shaders i stället för själva APIet).

Visa signatur

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