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

@cubeR: jag köpte mitt 7970 för 3562:- i maj 2012. Pressar kortet i spel än idag utan större problem. Bra köp alltså!

Vad jag tror vi i grunden diskuterar är varför Nvidia verkar äta mer CPU-kraft och framförallt: kan Nvidia göra något åt detta i DX12 (utöver det uppenbara att göra deras drivers generellt snabbare)?

Är inte helt stolt över förra inlägget, men ett visst mått av frustration inställer sig ändå när du flera gånger hävdar att det jag skriver är fel, det trots att länkarna (som bl.a. är den officiella beskrivningen från Nvidia, ingen random youtuber) visar på motsatsen.

Du har så här långt överhuvudtaget inte styrkt det du påstår med någon artikel eller white paper som beskriver det hela.

Tog ett tag att svara, min gamla laptop hade tydligen fått nog. Tangentbordet var på fallrepen och blev ohållbart till slut, men sitter nu med ny fin maskin.

Förstår vad du menar här och håller till största del med på den punkten. Är dock VÄLDIGT svårt att föra en diskussion när felaktiga termer används.

ALLA DX12 GPUer stödjer "async compute" då två operationer är asynkrona om de är oberoende på tidsaxeln. Vad du menar är att AMD har HW stöd för parallell exekvering av compute och 3d-shaders (rätt term är egentligen "kernel" för ett GPU-program).

Delen med om det saknas HW-stöd är fel i sak: både Pascal och Maxwell gen 2 har stöd för att samtidigt köra compute- och 3d-kernels. Till skillnad från GCN kan dock Pascal/Maxwell gen 2 endast köra compute- ELLER 3d-kernel per SM, däremot kan man vid ett visst tillfälle ha vissa SMs konfigurerade att ta jobb från grafik-kön medan de andra plockar jobb från beräkningskön.

Skillnaden är att uppdelningen är statisk i Maxwell och dynamisk i Pascal, den statiska uppdelningen gjorde det i praktiken värdelöst att köra compute- och 3d-kernels parallellt då det blev långsammare om man råkar göra en icke-optimal split. Så numera fungerar Maxwell gen 2 precis som Maxwell gen 1 och tidigare samt som Intels GPUer. D.v.s. finns fortfarande stöd för separata köer på DX12 nivå (direct and compute), men allt stoppas in i en och samma GPU-kö.

Hittade detta, är tydligen fler än jag som stör sig på att folk inte kan hålla isär "parallel" och "async". Här påpekas också helt korrekt att folk väldigt ofta använder termen "concurrent" på fel sätt. "Parallel execution" kräver minst två fysiska kärnor, "concurrent execution" går alldeles utmärkt att göra även på ett system med en CPU-tråd (multitrådning i Windows 95 t.ex.).

Några axplock vad som sägs i inlägget jag hittade:

"Pascal solves this problem with 'dynamic load balancing' ; the 8 SMs assigned to A can be reassigned to other tasks while Task B is still running; thus saturating the SMs and improving utilization.

For some reason many people have decided that Pascal uses preemption instead of async compute.

This makes no sense at all. Preemption is the act of telling a unit to halt execution of its running task. Preemption latency measures the time between the halt command being issued and the unit being ready for another assignment."

Han håller uppenbarligen med mig om punkten kring "preemption", finns liksom noll teknisk anledning varför man skulle implementera samtidig körning av compute- och 3d-kernels på det sättet. Är ju betydligt effektivare att bara köra dem sekventiellt, det är HELT tillåtet enligt både i DX12 och Vulkan (är fortfarande "async compute", dock inte parallell exekvering av compute/3d).

Har även plöjt denna Beyond3D tråd. Mycket matnyttigt där, bl.a. klarläggning av skillnaden på "async" och "parallel". Ser inte att något som framkommer där motsäger något jag skrivit om Nvidias DX12 drivare i den tråden.

En sak som nämndes i tråden om "context-switch" är att Nvidias GPUer har två kontext: ett för grafik och ett för compute. Detta kan nog förvirrat vissa till att dra slutsatsen att man aktivt hoppar mellan dessa i DX12. Så är inte fallet, kör man CUDA/OpenCL använder GPUn compute-läget (då har Kepler och framåt 32 köer). Kör man däremot DX12/Vulkan är man alltid i grafikläget, grafikkön är ett grundmängd av beräkningsköerna så allt som kan köras i compute-läget kan även köras i grafikläget.

Även om det tekniskt finns 1 grafikkö och 31 beräkningsköer från Maxwell gen 2 och framåt i grafikläget pekar det mesta på att man bara använder 1 + 1 för Pascal (i Maxwell gen 2 användes 1 + 1 ett tag men nu är det 1 + 0, d.v.s. allt går till 3d-kön på HW-nivå).

Nu verkar vi långt mer överens än tidigare! Har hela tiden hävdat att Nvidia inte kan göra speciellt mycket i DX12 då drivern där inte har någon möjlighet alls att lägga ut jobbet på flera trådar. Det finns en form av schemaläggning som utförs, men den har absolut inget med "preemption" att göra (vilket du hävdat innan och jag hängt upp mig på).

Nvidia når långt närmare sina GPUers teoretiska kapacitet jämfört med AMD, en orsak av detta är garantera att Nvida lägger långt mer CPU-tid på att konstruera en optimal kernel för varje jobb. Att skapa en kernel kan förenklat liknas vid att kompilera ett program, bara att detta måste ske på millisekundnivå! Så länge man är GPU-bunden är Nvidias lösning lysande, man offrar mer CPU-cykler för att få ut mer av GPUn som är primär flaskhals.

Problemet med vad Nvidia gör är att det blir viktigare att endera ha väldigt hög prestanda per CPU-kärna alt. sprida jobbet väldigt jämnt mellan CPU-trådar. I DX11 gör Nvidia ett lysande jobb här, i DX12 måste detta göra i varje spel.

En viktig sak som skiljer här är att man vill hitta en optimal ordning att köra alla compute- och 3d-kernels. Inte alls säkert att man vill köra saker i samma ordning de postades till DX12/Vulkan köerna, båda dessa APIer innehåller explicita synkroniseringspunkter i form av barriärer (barriers) och uppsamlingspunkter (fences) som beskriver vad en viss kernel förutsätter ska vara färdigt när den når en viss barrier/fence.

AMD löser detta problem i HW via ACE medan Nvidia löser detta i drivers. Notera att CPUn endast bestämmer vilken ordning kernels ska köra och vilka som eventuellt kan köra parallellt, detta läggs in i en (eller i Pascal, potentiellt två 3d/compute queue) kö som processas av GPUn. När en kernel väl börja köra är CPUn helt ute ur ekvationen oavsett GPU (gäller även Intel).

Om det vore fallet stämmer ju inte Nvidias egna information. Rätt säker att man har olika optimeringspunkter för hur man synkroniserar anrop som görs från olika trådar, alla dessa ska ju serialiseras ner till underliggande en/två GPU-köer. Nvidia har en punkt kring detta i deras "do's and don'ts for DX12"

"don’t create too many threads or too many command lists
Too many threads will oversubscribe your CPU resources, whilst too many command lists may accumulate too much overhead
"

Detta är generellt sant, använder man för mycket parallellism kommer man till slut till en punkt där fler CPU-kärnor minskar prestanda i stället för att öka den. Det här fenomenet ser man i alla applikationer där trådarna måste kommunicera med varandra, är också därför Amdahls lag inte blir exakt utan det är en övre gräns på hur väl något kan skala.

Amdahls förutsätter att den seriella delen är konstant, i praktiken ökar den ju fler CPU-kärnor man slänger på då kostnad för synkronisering ökar, ännu en orsak varför jag har svårt att se 6-8 kärnor bli speciellt relevant på skrivbordet inom överskådlig tid. De flesta desktop-program är inte "embarrassingly parallel", så maximal prestanda per kärna trumfar nästan alltid fler långsammare kärnor (gick själv från fyra kärnor till två kärnor på min huvudlaptop, den nya är i praktiken snabbare på nästan allt jag gör och du snurrar ändå saker som Hyper-V/Ubuntu konstant i bakgrunden).

Är vi inte överens egentligen? Nvidia har en GPU-design som lägger mer ansvar på driverprogramvara, i DX12 är det helt upp till applikationer att sprida lasten -> Nvidia kan inte göra något utöver att generellt minska CPU-overhead (i DX11 kan de däremot själva bättre sprida lasten).

I slutändan är detta rätt mycket ett icke-problem, i alla fall med i7-7700K. Flaskhalsen är ju ändå nästan alltid GPU-delen och för tillfället har Nvidia monopol på high-end segmentet. D.v.s. även om AMD GPUer äter mindre CPU kommer ändå totalresultatet bli bättre med GTX 1070 eller bättre, det även om man har en Ryzen CPU. Problemet är att man inte kan veta hur mycket DX12/Vulkan utvecklingen tar far och framtida spel blir väsentligt mer CPU-tunga. DX12/Vulkan lär inte vara i majoritet än på något år i alla fall.

Killen kan ju inte läsa sina egna grafer. Han anser att prestanda är sämre i DX12, men graferna visar ju på konsekvent bättre 1 % low (det oavsett om CPUn är i7-7700K eller Ryzen) med DX12 jämfört med DX11. Vem bryr sig om genomsnittlig FPS minskar med 3-4 % för GTX 1060 med Ryzen när man går från DX11 till DX12?

Nu är jag rätt skeptisk till 0,1 % siffrorna, misstänker att de har VÄLDIGT hög osäkerhet. Men man kan i alla fall konstatera att GTX 1060 har rätt konsekvent högre 0,1 % värden i DX12 jämfört med RX 480 (oavsett CPU). Hur är det en försämring?

Finns det någon konstigt i dessa resultat alls? Blir man CPU-bunden är i7-7700K @ 5 GHz > R7-1700X @ 4 GHz. Ja, är inte det helt förväntat? Att skillnaden är väsentligt mindre än 40 % tyder ju på att man fortfarande till viss del är GPU-bunden alt. så skalar dessa titlar relevant förbi 4 CPU-kärnor.

Du missade poängen rätt duktigt där, det man visar är en försämring i dx12 med specifikt ryzen (inte intel) med just nvidia gpu samtidigt som en amd gpu inte visar detta beteende, samtidigt visas i dom avsnitten inte samma problem på intel cpu'n, om det vore ett simpelt problem med cpu limitering skulle bägge visa samma beteende då bägge var just cpu limiterade.

Alltså, i 720p testerna med cpu limitering presterar nvidia sämre i dx12 än det borde relativt dx11 bara på ryzen samtidigt som detta inte händer på intel, dessutom presterar nvidia sämre relativt amd på ryzen med lägre minneshastighet även i dx11, deltat mellan rx480 och 1060 ökar, med AMD gpu så sker detta inte på intel eller ryzen, deltat mellan gpuerna krymper/ökar på ett sätt som det inte ska göra, kom ihåg bägge var kraftigt cpu limiterade och fps skulle inte dykt på kombon nvidia/ryzen om allt funkar bra. Tittar man på graferna så ser man dessutom att ryzen är fullt kapabel att leverera mer än den fps som just kombon ryzen/nvidia/dx12 ger. Nu är det dock detta som visats i två andra videos också så det är inte något nytt, det råkar bara vara ännu en i leden som verifierar faktumet. Här syns dock inte lika stor procent som hos dom andra då denna kille inte hade tillgång till att köra rx480 i cf vilket som han också säger hade ökat skillnaderna än mer, vilket också har demonstrerats av andra (alltså kraftigare nv gpu & amd i cf). I dom videorna så uppvisas stora skillnader inte bara i relativ prestanda utan direkt prestanda när nvidiakort springer in i en artificiell fps vägg på ryzen samtidigt som en AMD gpu inte gör det.

Det intressanta här är att som mindblank säger så minskas problemen genom att köra högre minneshastighet på ryzen så det skulle kunna vara så simpelt att den overhead som orsakas av nvidia drivarn äter minnesbandbredd i förhållande till antal kärnor som jobb sprids över, om den förklaringen rimmar... Det skulle kunna vara så att nVidia har i drivarn limiterat trådspridandet till max 8 trådar på processorer med 8+ och man identifierar detta genom cpu id men att den inte känner igen ryzen och däför ställer till problem (ren amatörmässig spekulation alltihopa)

Det ska hur som helst bli intressant att se när vega dyker upp eller om nvidia kryper till korset och erkänner att det finns en bugg i deras mjukvara.

Edit: Just 0,1 och 1% frametime värden är riktigt vanskliga att ha med om man inte är stensäker på att inget annat påverkar dom och att man räknar ut dom på korrekt sätt, i Mass Effect Andromeda som exempel så har man vid första inladdning i spelvärlden 0,1 & 1% värden oavsett setup som är riktigt dåliga, efter ett par minuter eller vid laddning två och framåt sker inte detta, i detta fall beror det såvitt jag luskat ut på Denuvo som ligger och kranar på cpu belastning så mycket det bara får för dekryptering av data. Andra saker som påverkar just 0,1 & 1% till mycket hög grad är minnesbandbredd och allmän optimering i spelen. GamersNexus visar på ganska stora förändringar på Ryzen och frametimes med olika patchar och uppdateringar som kommit sedan launch.

i den klassen spelar det ingen roll egentligen, inte med dagens spel. Min nuvarande burk i signatur har spelprestanda som en 1800x, i snitt lite snabbare än en 1800x (än så länge, ganska precis som en 4790k) men hur som helst så är ett överklockat 1080 inte limiterat av min cpu i 2560x1080 i något nytt spel så oddsen att se detta problem är praktiskt taget obefintligt just nu med ett 1060 och ryzen. Om spel blir oerhört mycket mer cpu krävande så kan detta förändras såklart men det kan även spela ännu mindre roll om nVidia ser till att fixa problemen.

Detta är i princip bara ett problem vid cpu benchmarks speciellt eftersom alla och hans mormor kör nvidia kort vid cpu testande samt att man gärna vill vara just cpu limiterad vid benchmark av just cpu. Anledningen till att det kommer på tal alls egentligen är att det målar upp en något felaktig bild av Ryzens faktiska spelprestanda med en artificiell sänkning av fps tack vare nVidia gpu/drivare

Edit: Jag bör lägga till att jag pratar om spelande vid ultra inställningar för runt ~100fps snarare än low och massiv fps (200+), detta är dock väldigt spelberoende hur det reagerar vid hög fps. Men för absolut max fps gaming är idag en 7700k med 3600 minne bättre än ryzen men då pratar vi ofta runt 300fps och liknande men det beror på hur enkeltrådat det i slutändan är.

Har vi sett samma video?

• BF1: ungefär samma resultat med 480 oavsett DX-API, det för båda CPU-modellerna. Med 1060 är DX12 sämre oavsett CPU-modell.

• RoTR: DX12 presterar bättre oavsett GPU och CPU (d.v.s DX12 presterar bättre än DX11 med samma GPU/CPU)

• Hitman: DX12 presterar bättre oavsett GPU och CPU

• DeusEx: med 1060 presterar DX12 4 % sämre med 1700X och 4 % bättre med 7700K, är det definitionen på "bug"?

Angående 0,1 och 1 percentilerna. När har 1 % fallet varit ett problem? I detta fall är resultatet helt samstämmigt inom varje titel och CPU, d.v.s. det är samma relativa skillnad mellan genomsnittlig FPS och 1 % low oavsett om man använder 1060 eller 480 -> rimligen är resultatet OK och skillnaden som finns mellan CPUer är en effekt av att de har olika antal CPU-kärnor och olika kapacitet per kärna.

Problemet med 0,1 % är att en sekvens på en minut med genomsnittlig FPS på 100 kommer basera sitt 0,1 % värde på att mindre än 10 scener över hela sekvensen inte störts av något externt. Det är i genomsnitt en mätpunkt per tio sekunder!

För att 1 % värdet ska bli opålitligt krävs att minst 100 scener, i genomsnitt en per sekund, får omotiverat lång renderingstid. Om så är fallet har man ett problem även i praktiken. 0,1/1 % är inte genomsnitt, så enstaka avvikande värden påverkar inte detta mätetal. Är som median fast i stället det mittersta värdet väljer man den lägsta renderingstiden av de 0,1 alt. 1 % scener med högst renderingstid för hela sekvensen.

Är sekvensen kortare alt. genomsnittlig FPS är lägre än 100 FPS blir ju 0,1 % än mer utsatt.

Sedan rent generellt: hur kan någon hävda att Nvidias drivare är "buggiga" baserat på dessa resultat när de klart och tydligt visar att man får mindre varians (mindre skillnad mellan genomsnittlig FPS och 1 % low) med 1060/DX12 jämfört med 1060/DX11, 480/DX11 samt 480/DX12? Eller har låg varians helt plötsligt blivit oviktigt (var viktigt när det fanns rapporter om att varians eventuellt var lägre med Ryzen, få har dock lyckats visa detta i reproducerbara mätningar).

Skulle säga att videon visar exakt det man borde förvänta sig. Nvidia har valt en design där drivern bör upprätta en DAG över beroendet mellan alla väntande 3d/compute-jobb för att sedan köa dem i optimal ordning till GPU. AMD gör motsvarande i HW (inte kritiskt för AMD att skapa en DAG, de kan ju bara köra flera saker parallellt och hoppas att det löser sig självt i de flesta fall).

AMDs lösning är mycket enklare att implementera i drivers och äter mindre CPU-kraft. Nvidias lösning ger långt mer flexibilitet, ACE är t.ex. helt värdelöst i DX11 vilket resulterar i att Nvidias GPUer kan prestera bättre på en viss transistorbudget och teoretisk kapacitet. Även i DX12 är det fortfarande så att Nvidias GPUer presterar bättre sett till teoretisk kapacitet och transistorbudget, men här finns ändå fördelar med ACE i form av lägre CPU-last om man är CPU-bunden (det normala är trots allt att man är GPU-bunden).

Vad videon i stället visar är: 7700K lär fortsätta prestera bättre i spel även i morgon, också med RX 480 presterar 7700K bättre om man är GPU-bunden. Så är inte ett Nvidia specifikt "problem", man blir däremot något tidigare CPU-bunden med ett 1060 jämfört med ett 480 fast det är ju en effekt av olika HW-designer och ingen "bug".

Du har helt enkelt inte fattat problemet, jag kan inte förklara det bättre för dig, kika på de övriga videor som släppts angående detta, adoredtv och Hardware Unboxed. Att du sedan Inte förstår att buggen enbart uppstår med nv/ryzen kombon och dx12 där prestanda absolut inte motsvarar vad som de fakto bör vara.

Du låter mer och mer som någon som ursäktar nVidia in i det sista...
Tänk på detta, om det vore ett enkelt overhead problem som drabbar alla processorer på samma sätt så skulle Intel cpun reagera exakt likadant, varför? Jo därför att bägge plattformarna jobbar redan under konstant CPU limiterade förhållanden. Använd en smula logik... Att jag sedan Inte enbart kikar på frametime mätningen beror på att väldigt få ställen rapporterar just dessa under cpu benchmarks, då denna bugg ger störst genomslag på medel och max fps som man av en händelse normalt använder vid testande så ger buggen direkt ofördelaktigt negativa resultat för ryzen i CPU benchmarks. Ett resultat som garanterat kan förbättras genom att nVidia ser över buggen/problemet.
Vad i detta förstår du inte?

Edit:Om nVidia valt en design i mjuk och hårdvara som skapar en ohållbart hög overhead på just Ryzen, är det då AMDs fel eller nVidias fel? Vem bör fixa denna oproportionerligt stora overhead, AMD eller nVidia?
Om man gör CPU benchmark testande vilken gpu bör man då använda för att påvisa processorns riktiga och ovinklade prestanda, AMD eller nVidia?

Skickades från m.sweclockers.com

Vi har i flera år sett en viss person vända och vrida på precis allt till Intels och Nvidias fördel. Så är du förvånad? Blir väldigt svårt med trovärdigheten tycker jag. Kör själv enbart Intel och Nvidia i dagsläget, och t om jag ser hur det ser ut i argumentationen.

Tycker också att det är extremt tydligt att något är "off" gällande Ryzen tillsammans med Nvidiakort. Det behöver man inte vara någon raketforskare för att se i de test som länkats.

Vi får helt enkelt se om fler testare och recensenter plockar upp detta och utreder. Hade personligen gärna sett Sweclockers göra ett nytt test med andra minneshastigheter samt grafikkort nu när det är så mycket snack om detta.

I den klassen spelar det mindre roll, jag hade kört den som var billigast för tilfället i valet mellan RX 480/ GTX 1060.

När det gäller "problemet" med nvidia så känns det återigen som att man så gärna vill att Ryzen ska vara störst bäst och vackrast på allt så man letar efter corner case till absurda nivåer. Spontant skulle jag gissa på att fallet DX12 i ROTR på nvidia lägger en större last på CPUn kontra AMD. Jag skulle även gissa på att denna last inte går att parallellisera vilket ger en fördel till intels snabbare kärnor.

Allt tyder fortfarande på att Intel med sin 7700K har den snabbaste CPUn för spel, däremot lär AMD ta tronen för bästa köp med R5 nästa vecka eftersom ingen lär köra så låga grafikinställningar att skillnaden blir speciellt signifikant mellan CPUerna.