Doom får stöd för Vulkan

Precis, ROPen blir ett problem. Skulle vara ytterst intressant att se hur CF står sig.

Men tycker att man kan dra ganska klara slutsatser att ju mer parallellt en utvecklare kör mellan CPU och GPU på draw calls med Vulkan och DX12 ju bättre kommer AMDs CGN står sig, speciellt mot Maxwell som inte alls kan komma upp i samma nivå parallellt.

Detta inlägg förklarar det väldigt bra, även om folk gärna ville påstå att den typen av gains som AMD såg i AoS bara skulle vara i AoS:
http://www.overclock.net/t/1569897/various-ashes-of-the-singu...

"Therefore in game titles which rely heavily on Parallelism, likely most DirectX 12 titles, AMD GCN 1.1/1.2 should do very well provided they do not hit a Geometry or Rasterizer Operator bottleneck before nVIDIA hits their Draw Call/Parallelism bottleneck. The picture bellow highlights the Draw Call/Parallelism superioty of GCN 1.1/1.2 over Maxwell 2:"

Indeed är det en del av förklaringen. Men samtidigt så ser vi att RX480 är på en nivå av GTX980 med Vulkan där man i DX11 är på en nivå mer likt GTX970.

Detta är såklart inte på grund av dåliga drivrutiner utan för att DX11 är gjort for mestadels seriell körning där nVidias drivurtiner via optimeringar kölägger tasks för bästa genomkörning seriellt.

Med DX12/Vulkan så sker detta parallellt direkt från CPUn utan att vara bundet till en tråd på CPUn där drivrutinerna sen får använda övriga trådar för att strukturera om kön för seriellt körning.

Man kan komma förbi ROPs begränsningen genom att använda "Primitive discard accelerator" som är en feature i 480. Tekniken utvecklades av konsoll folket som mjukvara. Innebär att man behöver inte göra en Crysis2 där tessalation pågick fast det inte syntes. Utan det som inte syns tas bort. Folk som testat funktionen i vissa scenarier säger att inget kort på marknaden kan jämföras när det används rätt. Att 480 är svagare på 4k är för det är ett mainstream kort.

@CamelCase:
För några år sedan såg det ut så här:
http://www.anandtech.com/show/4061/amds-radeon-hd-6970-radeon...
http://gamegpu.com/action-/-fps-/-tps/wolfenstein-the-new-ord... - se högre upplösningar min fps

Det hela ändrades iom lanseringen av Maxwell - 900-serien. Dispatchern i den samt en primitive discard accelerator och 4 triangles samt 16 pixels per rasterizer per och clock-cykel ger en hel del skjuts över allt. AMD OpenGL prestanda blev inte dålig över en natt så att säga. Det var bara att Nvidia slängde bort double precision och fyllde upp utrymmet med dessa egenskaper vilket resulterade i problem för AMD som bara rebrandade 200-serien till 300-serien med högre clocks. Om jag inte är helt ute och cyklar förstås...

Edit: Blandade ihop Maxwell och Kepler, Maxwell är 16 pixels per raster varav varje SM ger 4/2 (int8/fp16) pixels/clock, Kepler är 8 per raster med samma förhållande för SM - om jag fått rätt information...

För de som genuint är intresserad av att förstå varför Maxwell inte alls skalar med en typiskt gaming PC CPU rekommenderar jag att man läser detta: Nvidias DX12 Do's And Don'ts och även t.ex. denna presentation från AMD, notera specifikt sidan 6.

Nvidia har plöjt ner enorma resurser i sin DX11 drivare, specifikt har man detta

"On DX11 the driver does farm off asynchronous tasks to driver worker threads where possible – this doesn’t happen anymore under DX12"

något som AMD saknar, där kör driverkoden i praktiken helt på det man kallar "rendering thread" i DX11/OpenGL. Nvidia blir därför CPU-bundna långt senare då redan deras DX11/OpenGL drivare kan utnyttja flera CPU-trådar "under huven". Då DX11 inte alls är designat för detta krävs handpåläggning i var enda titel för att detta ska fungera bra, något som kräver enorma resurser.

Men det är fel att tolka Maxwells brist på skalning som att den är dålig på DX12, grejen är att den är extremt bra i DX11. Tänk på att sett till rå beräkningskraft är det extremt jämt skägg mellan 970 och 380 samt mellan 980 Ti och 390/480, men inte riktigt dessa kort som striden står mellan i praktiken.

HardOCP har gjort ett test med en i7-5960X nerklockat till 1,2 GHz. Två saker man ska titta på här, dels att Nvidia faktiskt kan använda en del extra kärnor redan i DX11 och 980 Ti är därför ~80 % snabbare än Fury X i Ashes of the Singularit @ 1,2 GHz. Båda GPUerna får en rejäl boost av DX12 (och 980 Ti är Maxwell...) och hamnar på mer eller mindre identiskt resultat.

Jag vet inte hur jag skulle kunna "bevisa" det jag hävdar mer tydligt än så här. Har i.o.f.s. en 8-kärnors Atom-server @ 2,4 GHz på jobbet, kanske kolla om man får låna hem den och stoppa i lite olika grafikkort för att testa t.ex. Doom

Och visst har konsolerna kommit längre. Men även här vet jag inte hur jag tydligare kan peka på elefanten i rummet: PS4 och XBO är typiskt CPU-bundna i spel och majoriteten av vinsten man får av "async compute" där kommer från att man avlastar det som är flaskhals, d.v.s. CPU-delen.

Gaming PCs är inte ens nära att vara CPU-bundna. För att göra en liten mellan tummen och pekfingret kan man jämföra flyttalsprestanda mellan CPU-delen i PS4 med en oklockad i7-6700K, det är 77 GFLOPS mot 512 GFLOPS. D.v.s det skiljer en faktor 6,6 i beräkningskapacitet. På PC är det mer intressant att göra det omvända, flytta en del GPU-jobb till CPU-delen, Intel är väldigt intresserade kring detta då det skulle höja vill-ha faktorn på E-serien rejält bland gamers. Föga oväntat har just Intel jobbat en del på detta.

I korthet: PC-system kan i dagsläge inte få samma boost av async compute som konsoler då en av huvudnumren som konsolerna använder inte är relevant på PC. Det sagt så kan man i framtiden mycket väl komma högre med denna teknik än vad man ser idag, men om inget radikalt ändras kommer man aldrig i närheten av dagens konsoler (i hur mycket boost "async compute" ger).

Och visar inte videon jag åter-länkande ovan, @kelthar postade länken först i tråden, att det stora lyftet på 480 kommer när man går från OpenGL till Vulkan utan async compute. Det är absolut <10 % extra i genomsnitt när man sedan lägger på async compute. Så ser liksom inte var jag har haft fel i mina uttalanden, men peka gärna ut dem och allra helst genom en länk till en artikel eller annan förklaring så man kan lära sig något nytt!!!

Har inte läst, men +1 för tipset och ska absolut läsa detta under kvällen!

I de mätningar Gamersnexus gjort ser ju trots allt FX480 en förbättring och precis som SMT kan ge en klar boost i lägen där man är begränsad av t.ex. minnesbandbredd så nämner Oxide i artikeln jag länkade ovan att ett fall där "async shaders" kan ge en boost är när en av jobben är VRAM-begränsade, ypperligt tillfälle att kombinera med något med hög datalokalitet som då inte stressar VRAM. 480 lär precis som du skriver vara kraftigt bandbreddsbegränsat i 4k.

Däremot hjälper det inte i detta fall

"The RX 480 is completely unplayable [in 4k] – as one might expect – but still produces a consistent scaling of 24.7% AVG FPS increase."

Om man inte använder "async compute" alls i Gamersnexus mätningar undrar man ju lite vad skalningen kommer av...

Som jag redan påpekat, anser att både AMD med "Shader Instrinsic Functions" och Nvidia med Gameworks aggregerar precis som de rimligen borde givet att båda är börsnoterade företag och är direkta konkurrenter mot varandra. Tror däremot inte att PC-spelbranschen gynnas av en eventuell splittring i AMD och Nvidia specifika tillägg utanför DirectX standaren då det drar upp kostnaden.

På ett filosofiskt plan är det också intressant att det var ett sådant herrans liv om Gameworks, en teknik som helt ligger ovanpå DX-standardfunktioner och undantaget Hairworks (som inte borde vara ett problem på GCN4) faktisk presterar riktigt bra även på GCN (t.ex. FXAA, HBAO+, Waveworks).

Men sedan är det alltså helt OK när AMD pushar för "shader instrinsic functions" där huvudsyftet är att gå utanför etablerad standard. Även för AMD är ju detta ett problem då man gräver fast sig i den ISA GCN använder, att göra en övergång likt den man gjorde från VLIV5 till VLIV4 till GCN är blir en lågt högre tröskel om "shader instrinsic functions" rejält tar fart. För Nvidias del lär det ju finnas en del resurser att routa om från DX11 drivare till att hacka "shader instrinsic functions", så lär knappast gå någon nöd på dem.

Framförallt är detta intressant just nu när det börjar dyka upp titlar med DX12/Vulkan. En annan av huvudpunkterna med dessa APIer är att de erbjuder en långt bättre abstraktion av hur moderna GPUer faktiskt ser ut. Man har en abstraktion just för att kunna gömma implementationsdetaljer och om abstraktionen är bra (vilket rimligen både Vulkan och DX12 är i detta läge då de är helt nya) så ger abstraktionen inget relevant påslag på kostnad.

Angående det sista så är det drivers som hanterar en sådan sak som 3,5+0,5 GB poolen i 970, så i DX11/OpenGL behöver applikationer överhuvudtaget inte bry sig. För DX12 och Vulkan är det något som måste hanteras explicit, men det blir då en extra minnespool över de två som redan är ett krav för alla kort. Måste finns ett "device local" som typiskt är VRAM om det inte är en iGPU, samt ett som är "host-visible" & "host-coherent" som i praktiken alltid är reserverat "vanligt" RAM som.

970 är inte den enda GPUn som har flera pooler. Intels iGPUer har alla en extra pool då det går att explicit hantera CPUns L3-cache. Iris Pro på Broadwell lär ha två extra pooler då även L4-cachen kan hanteras explicit, dock är den "osynlig" för grafikkretsen i Skylake. Lär knappast behövas en specifik render-path bara för 970, det är en allt för liten detalj. Däremot kan det mycket väl finnas specifika optimeringar för speciella GPU-familjer.

Fast det enda du bevisar är att nVidia via drivrutiner får upp prestandan genom att recomplica för att bättre passa seriell körning inom den begränsade förmåga nVidia har att köra parallellt.

Så för varje gång nVidia ska komma upp i prestanda så måste ett drivurtinsjobb göras. Antagligen därför de trycker hårt på Gameworks få då kommer saker "rätt" från början och de slipper tweaka sina drivisar lika ofta.

Nej Maxwell kanske inte är direkt dålig i DX12 utan utmärkt i DX11, det beror på hur man jobbar med "the spin of words".

Intressanta här skulle vara och jämföra hur Maxwell skalar på DX11 med i7-5960X nerklockat till 1,2 GHz mot Poralis i DX12.

Mer att du pratar om dagsläget som en "klart och färdigt stadie". Problemet är att du inte kan isolera ut något då vi i diverse AC patchar inte vet hur AC används. Därför blir det konstigt att idag peka på PC spel som kör AC idag och säga "Där är vad vi kan förvänta oss".

Vart skalningen kommer av? AMDs ACE som kan köra fler draw calls från CPUn parallellt, typ hela poängen med CGN.

Att det skalar på GTX 1080 såg vi ju redan i Gamesnexus-testerna då det blev en boost att gå till Vulkan trots att "async compute" inte används på Pascal ännu i Doom. Fast bara i låga upplösningar, men det är fallet som är sannolikast att ha någon form av CPU-flaskhals.

Håller absolut med om det sista du skriver. Skulle däremot vara intressant att se en i3 (eller ännu hellre något klenare än en Haswell i3) på Maxwell. Givet tillräckligt klen CPU kommer även Maxwell se en positiv effekt av både DX12 och Vulkan. Med normala gaming CPUer är även system med 980 Ti totalt GPU-bundna redan med DX11/OpenGL (bl.a. tack vare att drivarna där explicit sprider arbetet mellan flera CPU-kärnor).

För några månader skrev jag att 380/7970 skulle vara bättre än 780 i i nya API och fick massa flame för det Chockerande för de som äger en 780ti tom Titan http://gamegpu.com/images/stories/Test_GPU/Action/DOOM/test/v...

Nu är internet ganska stort så finns ju alla möjligheter att jag totalt hamnat fel. Men är inte detta ett diskussionsforum som i detta fall handlar om att ett spel fått stöd för den teknik vår diskussion främst handlar om?

Vad anser Ni att man lämpligen avhandlar i denna tråd?

I alla sådana här trådar på teknikforum dyker det alltid upp troll som störs av att deras rena databas för perfekta köpråd smutsas ner ...
Dom har antagligen inte ens reflekterat över termen "diskussionsforum". Shame on them

Nej samma nivå är inte frågan men när folk pratar ner AC och vi redan ser 10% gain så blir man konfunderad. Hade nVidia eller AMD släppt en drivrutin som gav 10% gain så skulle det vara hyllat, nu när vi redan idag ser 10% (in best of cases) så pratar foilk som det är inget väsentligt.

Sen som sagt så vet vi inte vad som är aktiverat idag i dagens AC switchar i spel. Kan vara så att en del redan finns utanför AC switchen, typ köa upp i Copy que, och därför blir det svårt att isolera vad dagen effekt är.

Ok, låt oss säga att jag är mer positiv om vad AC kommer ge PC

Men såklart, du har inte fel i sak om konsol vs PC.

Fast det är till stor del motsägelsefullt då du sen säger att Compute är en del av Grafiken. ACE används flitigt för att ta emot och dela ut tasks till CUs och det är därför GCN har lyckats så bra i parallella syften där ACE står för dels fördelningen av resurserna, prioriteringarna, och switchningarna. Det är också tack vare ACE som tasks inte behöver tugga i väntan på att andra tasks blir klara utan de kan göras async. Detta kan, som du säger, användas för en del saker en CPU gör men idag finns det gått om uträkningar som ska göras parallellt med graphic ques där uppenbarligen ACE gör ett fenomenalt jobb.

Kort och gott gör ACE i DX12 och Vulkan det som nVidia gör med drivrutiner i DX11, fördelar jobbet. Det är tack vare ACE strukturen som GCN är i Tier 3 och Maxwell i Tier 2:
https://msdn.microsoft.com/en-us/library/dn899127(v=vs.85).as...

Nej, ACEär med och tar emot kommandona och delar ut den till CU (grafikkortet engines). Det är uppsättningen ACE + GPC som ser till att kommandona fördelas ut, hållas koll på och prioriteras till CU. CU gör bara beräkningarna men har absolut noll koll varför den gör det eller riktigt vad den räknar. Man måste se det som att typ lägga pussel, CPU skickar kommandon hur varje bit ska ligga samtidigt (parallellt) och ACE prioriterar upp hur man gör det effektivt och just parallellt. Typ börja med kanterna på pusslet (Prioritera), en del CU ska organisera bitar och en del ska lägga bitar (Fördelningen). Varje individuell CU jobbar men det vet inte med vad, det är ACE som vet att CPUn vill ha ett färdigt pussel i slutändan när det når pipen.

Allt måste köas, oavsett vad det handlar om så det är ganska självklart att hur köer hanteras och hur många köer som kan hanteras är ganska vitalt.

Det du länkar till bekräftar det. Poängen men DX12 är också att du flyttar över "kontrollen" av vad Draw Calls ska leda till från CPU/Drivrutiner till GPUn, men någon på andra sidan måste fortfarande lösa biffen.

Lite om hur Compute kan användas/användas för maximera pipen bättre finns här:
http://www.slideshare.net/gwihlidal/optimizing-the-graphics-p...

Det är också därför du ser direkta gains på CGN med de nya APIerna mot DX11, gains som inte nVidia får. nVidia har som sagt använt Drivurtiner och extra CPU trådar för att recompila jobben till sina "engines".

Still, ACE är med i jobbet att fördela ut, prioritera, omprioritera och resursfördela dessa kommandon till CUs. Så ja det är helt rätt men ja det är till stor del tack vare hur CGN jobbar med ACE.

Det enda jag har sagt hela tiden är att ACE är med för att se till att GPUn kan jobba med parallella tasks och är med och hanterar vad som går in i CU delen. Det du nämner om och om ovanför är bara bekräftelser men jag får känslan av att du tror CPUn skickar direkt till CU och ACE ligger "vid sidan om"?

Tycker själv det är ganska givande och har hellre en ingående omgång med Yoshman om hur moderna APIer jobbar än att posta:

"Bara nördar spelar Doom därför är Vulkan skit"

Missade helt att svara på detta.

Vem i denna tråd har pratat ner "async compute"? Min invändning i första posten (som var ett svar på ett inlägg jag gissar var adresserat bl.a. till mig, brukar annars sällan kommentera i speltrådar) var mot att AC skulle vara huvudanledningen till varför AMDs kort ser en sådan boost med Vulkan. YouTube videon som postas i tråden visar rimligen med all tänkbar tydlighet att den stora vinsten erhålls när man går från OpenGL till Vulkan utan AC. Förklaringen är att AMD-korten underpresterar relativt Nvidia i OpenGL, en nackdel som försvinner i Vulkan tack vare dess "low overhead" design (drivers har helt enkelt mycket mindre påverkan på prestanda).

Lägger man sedan till AC visar YouTube-videon att man får en liten boost till, men den är inte i närheten lika stor som byte av API/runtime ger. Boosten verkar vara ungefär som tidigare DX12 titlar, d.v.s. < 10%. En ökning är alltid positivt och kan inte se att någon i denna tråd hävdar annorlunda. Men 10 % är kanske inte heller något att bli allt för upphetsad över, det är trots allt ungefär den skillnad som finns mellan Maxwell referens och korten med eftermarknadskylare (och då får man den boosten i alla titlar bara de är GPU-bundna).

Så på PC ger AC ett trevligt tillskott, men det är inte den viktigaste fördelen med DX12/Vulkan. Det är i stället deras "low overhead" design.

För konsolerna är däremot AC absolut något man måste lyfta fram, begriper inte riktigt varför en del verkar tolka detta som en diss av tekniken på PC i stället för vad det borde vara: en finess som absolut är viktig på enheter där CPU-delen är flaskhals! På PC råkar det förhålla sig så att CPU-delen inte ens är nära att vara flaskhals när man använder DX12/Vulkan, som konsekvens av detta blir effekten av AC mindre.

Och har aldrig sagt att AC är dömt att stanna under 10 % boost på PC, däremot kan man med 100 % säkerhet säga att så länge konsolerna är CPU-bundna och PC GPU-bundna kommer effekten alltid vara väsentligt större på konsol.