Nej här har du helt tvärfel. nVidias shader scheduler sköts helt i mjukvara, nVidias gpu'er av senare slag har inte detta alls i hårdvara. Vad i detta kan missförstås?
Denna mjukvarulösning av shader/gpu scheduler är vad som orsakar problemen med nVidia kort på Ryzen.

https://msdn.microsoft.com/en-us/library/windows/desktop/ff47...

"Deferred rendering records graphics commands in a command buffer so that they can be played back at some other time. Use a deferred context to record commands (rendering as well as state setting) to a command list. Deferred rendering is a new concept in Direct3D 11; deferred rendering is designed to support rendering on one thread while recording commands for rendering on additional threads. This parallel, multithread strategy allows you to break up complex scenes into concurrent tasks."

Finns bara en GPU-kö i moderna GPUer, det gäller både Nvidia och AMD. Vad DX11(med deferred rendering) /DX12(som i praktiken endast har motsvarande DX11 deferred rendering) möjliggör är att man utför den CPU-tunga delen av GPU-jobbet parallellt på fler trådar.

Vad Nvidia gjort i DX11, vilket han går igenom rätt noggrant i videon, är att de alltid använder sig av "deferred rendering" vare sig om applikationen är multitrådad eller ej. Detta kostar en del overhead för att sprida ut jobbet över CPU-trådar, men fördelen är att man kan utnyttja fler CPU-kärnor även i fall där spelmotorn i sig är rätt dålig på att använda CPU-kärnor. Risken att en enskild CPU-tråd ska bli flaskhals är därför minskad, han tog upp exempel som Project CARS där Nvidia fungerar riktigt väl då lasten sprids ut medan AMD fungerar riktigt dåligt då deras DX11 driver aldrig sprider ut jobb över CPU-kärnor så huvudtråden blir överlastad då den både tar hand om fysik och GPU-jobb.

I DX12 sprider vare sig Nvidia eller AMD ut jobbet över CPU-kärnor. Här har AMDs driver ett väldigt lätt jobb, posta det hela på en ACE och resten tar den HW-baserade schedulern hand om.

Nvidia får här ingen overhead från att sprida ut jobb över CPU-kärnor, men de måste fortfarande foga ihop alla "command lists" från alla trådar och posta den på GPU-kön. Är helt upp till spelet att det är lagom mycket last på varje CPU-tråd då drivers inte har några egna trådar i DX12 (det gäller som sagt både för Nvidia och AMD).

Edit: när man väl postat jobbet till GPU-kön sker resten helt på GPUn. Att CPUn på någon sätt skulle kunna vara involverad i hur "shader program" kör är totalt orimligt, körs ju potentiellt tusentals program parallellt och de kontextswitchar en gång per cykel!

Dessa hanteras av vad Nvidia kallar "warp-scheduler", går att läsa om i t.ex. Whitepaper om Pascal. Kolla kapitlet "Pascal Streaming Multiprocessor".

Kolla upp async shaders och hur context switching sköts av nVidia där, detta är huvudproblemet. Man saknar denna context switch i hårdvara så man emulerar det i mujkvara och nu gör man det på pascal med pre-emption delvis i hårdvara och fortsatt mjukvaru schemaläggande. På maxwell sköttes det helt i mjukvara med rätt hård prestandaförlust som resultat. Detta är ganska väl dokumenterat vid detta laget. Exakt hur stor overhead som skapas av detta är svårt att säga då ingen verkar vara villig att testa men det är i grund detta som ligger till orsak att nvidias gpu'er beter sig underligt i dx12 titlar som stödjer just async med Ryzen.

Det finns videos som i detalj visar cpu belastning med olika gpu'er, där visade nvidia långt högre cpu belastning vid samma fps som motsvarande AMD gpu, denna cpu belastning uppkommer inte från ingenstans.

Nej det är också helt fel.

För Kepler/Maxwell stoppar drivern in all som postas på DX12 "Compute kö" i samma instruktionsström som allt som postas på "3D Queue". Det är helt OK enligt DX12/Vulkan specifikationen, är även så Intels GPUer hanterar "compute kön" (där finns överhuvudtaget inget HW stöd för compute-köer, men det kräver inte heller DX12 utan måste bara finns en "compute kö" på API-nivå, upp till driver att göra vad som är lämpligt på underliggande HW).

Pascal har en feature som kallas "Compute preemtion", många tubers och inlägg i form som (felaktigt) dragit slutsatsen att den på något sätt är involverad i hur Pascal hanterar "Async compute" (en term som kommer från AMD, DX12 nämner överhuvudtaget inte den termen, det folk typiskt menar är det DX12 kallar "multi engine").

Vad Pascal har, men Maxwell/Kepler saknar, som gör att man nu kan köra "compute" parallellt med "3d" kallas "Pascal Dynamic Load Balancing".

AMD lyckades förvirra rätt många att tro "async == parallel", men det är fel. DX12 kräver att alla drivers implementerar 3 st köer (3d-, compute- och copy-kö), dessa måste kunna köras asynkront på ALLA DX12 implementationer.

En implementation kan sedan välja att köra jobb postade på en DX12 kö parallellt med jobb postad på en annan DX12 kö. Detta sker i praktiken endast hos GCN och Pascal, det då det krävs HW-stöd från GPU om detta ska fungera i praktiken. CPUn är inte på något sätt involverad här!

Parallellt: två eller flera saker händer samtidigt.
Asynkront: två eller flera saker händer utan att vara ihopkopplade med varandra på tidsaxeln, behöver inte alls ske parallellt.

Vet inte riktigt vad du svamlar om just nu men gå gärna och läs på lite om just async shaders/async compute och hur det har implementerats i dx12 titlar trots att det per definition inte är en uttalad del av dx12 även om funktionen som sådan faktiskt fins i dx12 likväl (async compute).

Rise of the Tomb Raider använder sig av async shaders/compute, AOTS likväl. Bägge dx12 titlar.

Async compute/async shaders hanteras sedan av nVidias drivare helt och hållet på maxwell då maxwell saknar denna typ av context switching i hårdvaran, därför sköts detta helt och hållet i mjukvara på maxwell (ren emulering med stor prestandaförlust). På pascal är det lite förbättrat tack vare pre-empting delvis i hårdvara (context switching sker vid draw call nivå normalt men kan ske ända ner på per pixel nivå) men mycket av context switching jobbet sköts fortfarande i ren mjukvara även på pascal.

Hmm, några frågor då: vad är "async compute/async shaders"? Varken DX12 dokumentationen eller Vulkan-specifikationen nämner denna term.

Och du säger alltså att Nvidias whitepaper om GTX 1080 är fel, för t.ex. AnandTech har precis samma uppfattning att det är just "dynamic load balancing" som gör det möjligt att effektivt köra jobb från 3d-kön (korrekt term är "direct-queue") och compute-kön parallellt.

Maxwell kan köra beräkningar och grafik parallellt, men varje SM kan bara köra endera beräkning eller grafik så man måste göra en statisk partitionering av vem som gör vad. I praktiken är en sådan uppdelning omöjlig att göra på ett generellt sätt så man har stängt av möjligheten att köra grafikjobb och beräkningsjobb parallellt. Vare sig DX12 eller Vulkan kräver att beräkningar och 3D körs parallellt, det är en implementationsdetalj.

Både Nvidias och AMDs GPUer är en form av barrel-processorer. I Nvidias fall kan upp till 32 "warps" vara aktiva i en och samma SM, i AMDs fall kan upp till 40 "wavefronts" vara aktiva per CU (10 per SIMD, finns fyra sådana per CU).

Du hävdar alltså att det är realistiskt att CPUn är involverad i schemaläggning av "warps"? Det är att likställa med att någon krets utanför en x86 skulle hantera front-end. Med minimal förståelse av hur en GPU och CPU fungerar måste man ju inse hur totalt absurt det är att CPUn på något sätt är involverad i schemaläggning av shaders som har börja exekvera på en GPU.

Om inte annat borde några saker i "DX12 do's and don'ts" kanske ge en vink om det, t.ex.

"Don't submit extremely small command lists.

Small command lists can sometimes complete faster than the OS scheduler on the CPU can submit new ones. This can result in wasted idle GPU cycles.
The OS takes 50-80 microseconds to schedule command lists after the previous ExecuteCommandLists call. If a command list or all command lists in the call executes faster than that, there will be a bubble in the HW queue
Check for bubbles using GPUView
"

Hur ska CPUn kunna vara involverad i schemaläggning av GPU-jobb när det det kan vara ett problem att GPUn färdigställer jobb snabbare än CPUn ens kan köa dem?

"Consider a ‘Master Render Thread’ for work submission with a couple of ‘Worker Threads’ for command list recording, resource creation and PSO ‘Pipeline Stata Object’ (PSO) compilation

The idea is to get the worker threads generate command lists and for the master thread to pick those up and submit them
"
Det enda man pratar om är "command list recording", "resource creation", "PSO compilation" och "submit". CPUn sätter alltså upp shaders och talar om för GPUn vilka shaders som ska köra när. Men CPUn är överhuvudtaget inte involverad i hur GPUn sen väljer att köra dessa, det sköts i Nvidias fall av "warp-scheduler" som finns i varje SM.

Men anta att du inte dragit allt du skriver från en plats utan soltimmar, länka gärna någon artikel som beskriver hur CPUn är involverad i schemaläggning av shaders. Förklara gärna också varför "Pascal dynamic load balancing" inte fungerar och varför redan Maxwell/Kepler har 32 beräkningsköer (kallas Hyper-Q i länken) om de ändå inte kan köra jobb parallellt i HW.

Som bonusuppgift: även om man får usel FPS i RoTR med Intels GPU, förklara gärna hur det ens är möjligt att köra spelet då Intels GPU bara har en enda kö på HW-nivå. Ändå implementerar Intels driver DX12 direct, compute och copy queue på logisk nivå (krav i både DX12 och Vulkan)... (tips async!=parallell).

Maxwell/kepler har 32 som du så korrekt antyder, problemet är att du kan inte blanda jobb inom dessa 32, det är antingen 3d jobb eller compute eller 1 3d och 31 compute. Hela poängen med async shaders är att kunna injicera compute jobb i köerna av 3d jobb. Detta är maxwell helt okapabel till annat än med hjälp av mjukvaru scheduler som "paketerar om jobben" från vad async är tänkt till att lösa och det är idlande shaders som skulle kunna jobba med compute under tiden, nackdelen med nVidias metod är såklart den extra overheaden som skapas med cpu tid som går åt till att förbereda compute jobb till att passa nvidias rigida jobbkö. För AMDs del så fungerar async shaders mycket bra då dom inte skapar någon extra cpu tid alls utan enbart nyttjar tillfälliga idlande shaders i jobbköerna genom att på valfri kö injicera compute jobb.

Är detta mer förståeligt?

nVidia har helt enkelt inte hårdvaran att hantera async shaders jobb medans AMD har det, nVidias metod att lösa det är att lägga till ett extra mjukvarulager mellan api och hårdvara som paketerar om jobbköer från normal async till att passa en stelbent hårdvarjobbkö.

Klart att något är skumt. De som påstår något annat gör ju bort sig.

En av de bästa djupdykningar jag har sett.

AMD har 64 hårdvaruköer. Men i DX11 går endast jobbet till den första.

nVidia har avancerade drivrutiner som lägger ut jobb automatiskt på flera CPU kärnor.

Att lägga ut drawcalls på flera kärnor i DX12 är inget som sker automatiskt utan upp till utvecklarna, men kan i teorin få bort AMDs flaskhals.

Du har fragment som är rätt, men om du faktiskt försökte göra en koherent förklaringen av hela kedjan skulle du inse att din förklaring är

Har länkat Nvidias egen beskrivning av hur Pascal hanterar "async compute" (vad folk egentligen menar här är parallell exekvering av grafikjobb och beräkningsjobb).

Men då rätt många i denna tråd uppenbarligen inte orkar titta i länkar kommer den relevanta delen här:

"async compute"

Det som beskrivs som "overlapping workloads" är alltså parallell exekvering av arbete från DX12 "direct-queue" och "compute-queue", det AMD av någon anledning kallar "async compute".

Och angående Maxwell (gäller endast gen 2) säger man

Rent konkret betyder det att en delmängd av alla SM plockar jobb från grafikkön (DX12 direct-queue) medan resten plockar från beräkningskön. Efter att jobbet påbörjas är det ingen "preemption" för att byta (vore ju katastrofalt för prestanda).

Preemtion

Men men, preemtion då? Ja, det är också beskrivet i samma dokument för den som orkat läsa. Användarfallet för preemption är inte att köra 3d och compute samtidigt. Om man har någon koll på skillnaden mellan ett realtids OS och ett server OS borde det vara helt uppenbart att det finns två fall att ta hänsyn till.

Det fall som fått mest uppmärksamhet är fallet där man kan öka utnyttjandegraden på GPUn genom att köra 3d och compute parallellt. Här är det verkligen så att det MÅSTE köras parallellt för att kunna ge någon som helst fördel då eventuell vinst endast kan uppnås när det blir "stalls" i endera 3d eller compute delen, i det läget kan "den andra" delen utnyttja resursen. Detta är precis varför SMT fungerar på CPUer. I ett server OS optimerar man helt för detta fall, d.v.s. få ut så mycket utfört arbete per tidsenhet.

Det andra fallet är när något redan kör, men något med högre prioritet postas. I det läget vill man att det med högre prioritet ska köras så fort som möjligt, även om det betyder minskad total mängd utfört arbete. DETTA är vad compute preemtion används till och typfallet som brukar nämnas är "timewarp" i VR. Är precis det som Nvidia nämner i dokumentet som exempel

D.v.s detta fall har INGET med parallellism att göra.

Liten ordförklaring

DX12/Vulkan kräver att det som postas till två olika "engines" måste antas vara asynkront. Huruvida två saker postade till olika "engines" körs parallellt är en implementationsdetalj.

Saker kan vara asynkron och seriell (hela "async" i dotnet är detta, Nvidia Maxwell och Intel implementerar både DX12 och Vulkan på detta sätt), asynkron och parallell (GCN och Pascal implementerar DX12/Vulkan så), seriell och synkron (normala enkeltrådade program) samt parallell och synkron (är så fork-join ramverk fungerar, t.ex. OpenMP och Cilk+).

Vad sa han egentligen i videon

Börjar misstänka att flera här endera inte tittat på videon alt. inte fattat vad som sägs.

Hur fungerar DX11?

Vad han nämner i slutet på videon är att de gröna fälten här (som han kallar "intercept->worker", d.v.s. kostnad för att ta ett jobb och flytta det till Nvidia driver-worker threads som BARA finns i DX11) eventuellt kan kosta mer på Ryzen om det går över CCX-gränser.

I DX11 har har Nvidia-GPUer en fördel om man sitter på en stark CPU med många CPU-kärnor, deras driver kan automatiskt sprida jobb över CPU-kärnor vilket är positivt för prestanda i lägen där CPU-delen inte är flaskhals (vilket är det normala om man inte sitter med de absolut kraftigaste GPUerna och kör i relativt låg upplösning).

DX12 då?

Där säger han att det Nvidia gör i DX11 händer inte i DX12, att sprida lasten över CPU-kärnor är något som måste göras av applikationen och han nämner att det är väldigt svårt att få balansen rätt så man inte överlastar någon enskild tråd

De gröna boxarna här är den samordning Nvidia drivern måste göra då DX12 tillåter att jobb postas till de olika "engines" från alla trådar, men på HW-nivå finns bara en kö per "engine" så drivern måste synkronisera alla anrop (här är det möjligt att AMD kan utnyttja ACE till att likt moderna nätverkskort ha en kö per CPU-kärna, synkronisering av strömmar sker då i stället i HW).

Vulkan drar detta ett steg till. Där är det dokumenterat att applikationen måste säkerställa att alla anrop mot en specifik "engine" är serialiserad, om flera trådar använder samma "engine" är det upp till applikationen att säkerställa synkronisering. Vulkan själv gör ingen som helst försök att själv säkerställa att saker är synkroniserade (vilket DX12 gör). Detta verkar vara positivt för Nvidias HW, i alla fall om man ska tro 3DMark API-overhead test där Maxwell/Pascal presterar bättre med Vulkan jämfört med DX12.

D.v.s. detta är den enda punkt där schemaläggning av grafikrelaterade saker har möjlighet att kraftigt påverka prestanda, typiskt blir den kraftigt negativt påverkad om man överlastar någon tråd (vilket verkar hända i t.ex. RoTR med DX12). Finns INGET Nvidia kan göra för att fixa detta, detta måste lösas i varje applikation.

Och det var den lilla poäng jag försökte göra: Nvidia kan inte fixa eventuella problem på Ryzen när det handlar om DX12/Vulkan, det måste göras i varje titel. Däremot kan absolut Nvidia potentiellt gräva fram lite extra prestanda i DX11 fallet i lägen där CPU-delen är flaskhals p.g.a. att huvudtråden är överlastad.

@Yoshman: Du pratar om en sak jag om en annan och du blandar ihop saker rätt friskt. Sen att du försöker förlöjliga på den nivån är en aning pinsamt.

Igen skilj på äpplen och päron.

AMD har hårdvarustöd i sin gpu scheduler för async compute, detta har inte nvidia, inte ens på pascal, där gör man en fullösning som egentligen inte hanterar async compute som det är tänkt. Detta i sak är separat från den arbetsfördelning som sedan sker av denna hantering.

Problemet är att cpu belastningen av denna hantering och generell arbetstråd för gpu är på nvidia betydligt större än på AMD, dessutom så sprids detta cpu-arbete ut i dx11 på kärnor på ett vettig sätt så där märker man det inte speciellt mycket förutom i extremt cpu begränsade scenarion, där kommer en AMD GPU med samma prestanda annars vara betydligt snabbare då cpu inte blir en flaskhals för AMD gpu'n (trots högre fps). Edit: Kan tillägga att det tillkommer ännu en komplicerad vinkel på prestanda här och det är att trots AMD's lägre overhead så finns i dx11 problemet att deras huvudarbetstråd inte fördelas över mer än en tråd. Detta gör att prestanda vid cpu flaskhals blir extremt vansklig att bedömma mellan AMD & nV och skiljer från spel till spel beroende på t.ex. draw calls och geometri.
Fördelningen av detta arbete i dx11 på cpu'n står nVidias drivare för som det förklaras ganska ingående i videon, problemet kommer i dx12 där nVidia vill lägga över ansvaret på utvecklare att hantera deras fullösning till async shader/compute som tilkommer i dx12 titlar med async stöd. Detta orsakar en del problem som kan ses extremt tydligt i ROTR i just dx12 med Ryzen. Lösningen till problemen här ligger enbart hos nVidia då det defakto är deras mjukvarulösning som ställer til det. Om det vore spelet i sig eller OS så skulle man se samma resultat med en AMD gpu men det gör man inte, det sker enbart med nvidia gpu.

Frågor på detta?

Edit: Det går att slå av flertrådad optimering i nVidias drivare på pascal även för dx12, inte enbart dx11 (spelprofil, trådad optimering/threaded optimization). Körde nyss en benchmark i ROTR med trådat och otrådad optimering och det gav en rätt bra prestandaskjuts i dx12 med trådad optimering (25% på vissa ställen). Med andra ord så sköter drivarn fortfarande en utspridning av jobbet även i dx12, frågan som uppstår här är vad som sprids ut då drivarn egentligen inte ska ha med detta att göra i just dx12 enligt allas utsago...

@Yoshman vs @tellus82 - själv har jag en åsikt om vem som ser ut att argumentera (bete sig) bäst, men är helt enkelt inte kompetent nog att veta vem som faktiskt vinner. Tänker dock fortsätta läsa med spänning.

Man bör tänka på att den overhead som jag nämner är vid normalt spelande <144fps på nVidia inte ett jätteproblem men det finns definitivt där, som exempel där withcer 3 testas på AMD och nvidia gpu och bägge systemen har samma fps men cpu belastning med nvidia gpu ligger >20% högre på fyra trådar (rätt nära en hel kärna i belastning extra med bara overhead) än med AMD gpu, det är inte en trivial belastning. Vid CPU testande så kör man tyvärr ofta 720p och mycket höga framerates vilket ökar overhead för varenda frame producerad, sen ökar overhead ännu mer baserat på hur många trådar det sprids ut på pga hur nvidia designat det hela. Detta i sin tur öka latenser och väntetider i jobbkön. Allt detta betyder i slutändan lägre fps än det behöver vara pga massiv overhead.

saxat från https://youtu.be/TzdaOzxIsyI

Om detta nu är sämre än AMD's tillvägagångssätt låter jag vara osagt då deras blir limiterad av prestanda på en kärna men i stort sett saknar overhead. En sak är säker, man kan absolut inte påstå att denna overhead inte finns hos nvidia mjukvaran.