Ang Ryzen's spelprestanda (matchar 7700K idag, presterar bättre i morgondagen)

Jo, när patcharna släppts, då får vi se var vi hamnar. Innan dess så är det glada spekulationer som gäller!

Här har vi än mer mätvärden, nu från hardware.fr (http://www.hardware.fr/articles/958-2/latence-bande-passante....) som testat minnen igen. De visar bl.a. latenser i förhållande till klockning.

Om nu AMD lyckats, som sades i veckan, sänka latensen med 6 nanosekunder så är det ju trevligt. Frågan är (i ljuset av det här diagrammet från hardware.fr) vid vilken minnesfrekvens och timing det är. 6 av 103,4 är mindre än 6 av 75,9.

Jag fumlade lite innan och lade en uppdatering till ett tidigare inlägg i den här tråden, i en annan tråd av misstag.

En rejäl genomgång, varför det det är som det är och vad som måste ske för AMD om det ska ha någon chans.

Väldigt intressant och teknisk.

3660 med tight timings. Ger en bra skjuts i prestandan det. Men jag har nog mer tro på høgre frekvens kontra tightare timings. Men frekvens kanske ger diminishing returns efter vart och timings blir viktigare. Vi får se.

Riktigt bra video, med andra ord:

Nvidias drivers kan automatiskt dra nytta av flera CPU-kärnor i DX11 en möjlighet som saknas i AMDs DX11 drivers, att sprida ut last över CPU-kärnor kostar dock CPU-cykler. Så korrekta sättet att beskriva AMDs vs Nvidias GPU-drivers är att Nvidias har mer overhead men är mer effektiva om man har tillräckligt mycket CPU-kraft över. Så i DX11 är det absolut en fördel med Nvidia kort om man har många CPU-kärnor.

I DX12 är schemaläggningen av trådar helt upp till applikationen så ingen av den automatiska spridningen till CPU-kärnor som drivers görs i DX11 kan utföras av drivers här (detta är något Nvidia själva pekar ut här). Så om ett DX12 spel är väldigt bra på att sprida ut lasten över CPU-kärnor är det nackdel Nvidia om CPUn är flaskhals då deras drivers har högre overhead.

Ännu viktigare, i det jag länkade ovan pekar Nvidia specifikt ut detta:

"Don’t rely on the driver to parallelize any Direct3D12 works in driver threads"

Så om ett DX12 spel i någon läge begränsas av att en enskild CPU-tråd är flaskhals så kommer det bli ett värre problem ju lägre prestanda per kärna CPUn har. DX12 verkar vara kul att hantera för spelprogrammerarna, ännu en detalj i raden av detaljer som flyttats från drivers i DX11 till applikationen i DX12

Och för att förstå varför det kan få relativt stor effekt på Ryzen kontra Kaby Lake i vissa lägen måste man titta på prestanda per CPU-kärna, det specifikt för skalära heltal då det är vad spel främst beror av. Tyvärr är det inte så många CPU-benchmarks som testar skalära heltal (de tenderar att testa skalära flyttal, där är IPC hos Ryzen lysande, den matchar Broadwell).

För skalära heltal finns det nu rätt många olika fall som är rätt samstämmiga: IPC för skalära heltal är runt 40 % högre i Skylake/Kaby Lake jämfört med Ryzen. Heltalsdelen är en svag länk, prestandamässigt är R7-1700X väldigt nära en i7-2600K med åtta kärnor.

Några exempel som visar på denna skillnad. Kompilering, skalar helt perfekt med CPU-kärnor och för att i7-7700K och R7-1700 ska prestera i stort sett identiskt (vilket är fallet i praktiken) så måste IPC vara ~40 % högre.

Enkeltrådade fall som jobbar med skalära heltal, t.ex. WebXPRT och Google Octane, pekar också på att heltals IPC är på Sandy Bridge nivå vilket betyder att Skylake ligger ~40 % högre.

Även Hardware Unboxed videon, som postats tidigare i denna tråd, har ett fall som visar samma sak (det oavsett om man använder Nvidia eller AMD GPU)

Rent praktiskt betyder detta: om CPU är flaskhals kan R7-1700 aldrig prestera bättre än i7-7700K i spel, kompilering är så mycket "best-case" det kan bli för Ryzen (här är till och med cache-designen en fördel för Ryzen, två CCX med icke-inkluderande L3 är en perfekt match när man kör en enkeltrådad kompilatorinstans per CPU-tråd).

R7-1800X skulle rent teoretiskt kunna bli snabbare, men det kräver att spelet kan utnyttja 8C/16T i det närmaste perfekt. Tittar man på Amdahls lag krävs det att värdet på p (hur stor andel av programmet som kan skalas till alla CPU-kärnor) måste överstiga 85 % om CPUer är klockade lika och det måste överstiga 92 % om de kör på sina normala frekvenser.

Bortsett från Ashes of the Singularity är inget spel i närheten av dessa p-värden. I just AoS är ju i7-6900K 25 % snabbare än i7-7700K i CPU-testet, vilket är inte är i närheten av resultatet i något annat spel.

Vad jag sett så verkar Nvidia drivers vara en bov också när det gäller begränsning av prestanda i ryzen.

i princip alla reviewers testade ryzen med Nvida kort och då var det ~20-30% skillnad mellan 1800x och 7700k i rise of the tomb raider.

Testade man med crossfire RX480 så försvann gapet.

Man kan direkt se något inte riktigt fungerar korrekt när varken cpun eller grafikkortet flaskar. Sett detta i flertalet titlar när ryzen körs.

7700k vinner ofta marginellt men kikar man på siffrorna så ligger GPU på 99% medans på ryzen så är GPUN bara 90% trotts att cpun ligger under 50-60% på alla cores.

Prestandan kommer bara ökad med nya mjukvaruoptimeringar både från AMD och andra.

Det är svårt att lära en gammal hund att sitta ;).
Folk pratar fortfarande om att AMD kort blir super varma.
Även under Nvidia Fermi korten sa alla att amd blir
Super varma och kräver mycket ström. Medans
Nvidia drog mer det var bara för man är van vid att amd drog mer tidigare.
Eller att AMD har dåliga drivers och Nvidia funkar bättre. Senaste tiden har Fan
Nvidia haft riktigt dåliga drivers jämförelse med AMD x).

Men den där videon var väldigt intressant.

Då läste du inte alls vad Nvidia skriver i sin "DX12 Do's And Don'ts"

"
Don’t rely on the driver to parallelize any Direct3D12 works in driver threads

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

• While the total cost of work submission in DX12 has been reduced, the amount of work measured on the application’s thread may be larger due to the loss of driver threading. The more efficiently one can use parallel hardware cores of the CPU to submit work in parallel, the more benefit in terms of draw call submission performance can be expected.

"
Jag säger absolut inte emot att overhead är högre i Nvidias drivers, allt pekar tvärt om på att så är fallet. Det jag pekar på är att det finns ingen "Nvidia scheduler" i DX12, är precis det man skriver ovan. I DX12 är det helt upp till applikationen att sprida lasten på ett lämpligt sätt över CPU-kärnor, drivern kan överhuvudtaget inte göra något här (vilket den kan i DX11).

Det absolut enklaste förklaringen till varför prestandadelta mellan Ryzen och Kaby Lake är större i DX12 med Nvidia GPUer är just att RoTR begränsas i någon läge av mängden arbete som kan utföras på en specifikt tråd. Drivern har inga möjligheter alls att lösa detta problem i DX12. Så länge som skillnaden i prestanda mellan Kaby Lake och Ryzen är ~40 % eller mindre behöver det inte vara en bug, den absolut enklaste förklaringen är i stället skillnaden i prestanda per CPU-tråd och FPS begränsas av att någon CPU-tråd nått sin kapacitet (det kan också förklara varför SMT ibland kan ge negativ boost).

Hardware unbox test med Far Cry Primal visar ju också att i ett läge där 4 eller färre CPU-kärnor används och man är helt CPU-bunden så presterar ju i7-7700K ungefär så mycket bättre som är förväntat sett till dess högre IPC. Det gäller oavsett om man använder AMD eller Nvidia GPU.

Den lägre enkeltrådprestandan kommer absolut synas mest just i fallet Nvidia + DX12, finns i nuläget inget som pekar på att det är en bug i Nvidias drivers utan är en effekt av att Nvidias GPUer gör vissa saker i programvara som AMDs GPUer gör i maskinvara. Är absolut möjligt att lindra problemet på system med många kärnor, men det är något som måste göras i varje applikation då DX12 inte möjliggör den typ av automatiskt multitrådning som Nvidia har i DX11.

Fast nu har du nog blandat ihop cpu och gpu scheduler, det jag pratar om är nVidias implementation av mjukvaru scheduler för gpu arbetet i sig, inte hur schedulerns jobb sedan sprids ut (vilket är symptom på problemet). Schedulern kan inte bara "tas bort" i dx12, gpu'n måste ha denna server tråd igång för att överhuvudtaget kunna rendera/jobba alls. På AMD kort så sköts detta i hårdvara, på nVidias senare GPUer sköts det i mjukvara. Hur lasten sedan sprids för schedulern till gpu'n sköts helt och hållet av Nvidias drivare/mjukvara. Här kommer sedan problemet i dx12 där overhead ökar dramatiskt på ryzen med nvidia gpu. Varför detta sker är än så länge bara spekulation men problemet finns där likväl.

Nej, har inte blandat ihop något där. Det finns ingen GPU-driver specifik scheduler what so ever i DX12, är precis det Nvidia säger på den sidan.

I DX12 kommer Nvidias driver aldrig skapa nya trådar och den flyttar aldrig anrop mellan existerande trådar, så är helt upp till applikationen att sprida lasten väl. DX12 har dock lägre overhead och finns fler möjligheter att sprida last över trådar, men det måste ske explicit!

I DX11 har drivern egna "worker-threads", även om spelet är enkeltrådat kommer GPU-jobbet fördelas över flera CPU-trådar.

Se sidan 6 i denna presentation.

Kontrollfråga: Har du någonsin programmerat för DX11 och DX12? D.v.s. förstår du vad man refererar till när man pratar om "software scheduler" i detta kontext?

Motfråga, förstår du vad som menas med gpu scheduler för gpu arbete? Det har precis 0 att göra med en cpu scheduler och hur arbete sprids på cpu egentligen, det är nVidias fullösning som gör att dom kan sprida ut draw calls och liknande över fler cpu kärnor. Det är i sig separat från gpu-schedulern egentligen.

Det är en context switching scheduler som tillåter att GPUns kärnor kan jobba med olika saker så som CUDA, opencl, osv osv samtidigt som den jobbar med 3d rendering i valfri api.

Och i DX11 kan de automatiskt sprida ut detta jobb över flera CPU-kärnor, d.v.s. de har en programvarubaserad schemaläggare i DX11. I DX11 är applikationen något som producerar jobb och postar detta till en eller flera CPU-trådar som ägs av drivern, d.v.s. GPU-jobbet som utförs av CPU utförs på en annan OS-tråd(ar) än den som kör spelmotorn.

I DX12 utförs allt CPU-relaterat GPU-jobb direkt i anropstråden, d.v.s om applikationen är enkeltrådad kommer även allt GPU-relaterat arbete som CPUn utför köras i samma tråd. Så finns ingen "scheduler" här.

När väl jobbet är processat av CPU och postat till GPUn skiljer det sig överhuvudtaget inte mellan DX11 och DX12 på Nvidia GPUerna. Så den scheduler som finns på GPU (som hanterar shader-program) är överhuvudtaget inte relevant för diskussionen, den schedulern är helt implementerad i GPUn.

Det är inte alls vad han pratar om i videon, vilket förklarar varför din bild av detta blir rätt förvirrad.