DX12 vs Vulkan jämförelse - Techspot tittar på Strange Brigade

Permalänk
Datavetare

DX12 vs Vulkan jämförelse - Techspot tittar på Strange Brigade

Artikeln hittas här: https://www.techspot.com/article/1685-strange-brigade-benchmarks/

Alltid vanskligt att dra slutsatser från ett enda spel, ändå noterbart att DX12 gav något bättre prestanda både på AMD och Nvidias GPUer.

DX12 vs Vulkan

Inte heller i denna titel ger "async compute" något större prestandavinst, ca 5 % på Vega och ca 2 % på Pascal.
Async-compute på/av

Vad vi ändå ser är en av så här långt rätt få titlar som enbart stödjer DX12/Vulkan, d.v.s. inget DX11 stöd. Börjar vi se övergången till de nya APIerna nu? DX12 har precis passerat sin 3:e födelsedag, så nu kan man nog ändå förvänta sig en utrullning på lite bredare front!

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

Min gissning är att det kommer pusha spelutvecklare att gå över till DX12 och Vulkan mer nu i och med strålspårning. Blir det något halvhjärtat försök till att få till DX12 eller Vulkan med kass prestanda som följd kan dom däremot dra åt helvete.

Visa signatur

sweclockers prestandaindex

Efter 10 kommer 11.
Efter 99 kommer 100.

Permalänk
Medlem
Skrivet av ClintBeastwood:

Min gissning är att det kommer pusha spelutvecklare att gå över till DX12 och Vulkan mer nu i och med strålspårning. Blir det något halvhjärtat försök till att få till DX12 eller Vulkan med kass prestanda som följd kan dom däremot dra åt helvete.

Visa signatur

CPU: I7 7700k @ 4.6GHz - Noctua NH-D14 - Asus ROG Strix Z270F Gaming.
GPU: GTX 1080ti - Accelero Xtreme III @2 st 120mm cf-v12hp hydro dynamic.
RAM: 32GB DDR4 3200MHz. HÅRDDISK: 4 st SSD, 2 Mekaniska.
MONITOR:1 Optix MAG274R 27" MONITOR:2 Samsung 2693HM 25,5" MONITOR/Tv:3 LG 47lv355n-ZB 47". Nätagg: Corsair Newton R2 1000W. Allt i ett Cooler Master CM Storm Stryker.

Permalänk
Medlem

Om man generellt kan räkna med aningen bättre prestanda i DX12 är det ju en sak, men det vore ju logiskt om de lagt all tid på Vulkan eftersom det funkar på Win7 och eventuellt om de portat till Linux

Trist att de inte har något Kepler eller första generationens GCN också

Permalänk
Medlem

Om vi inte kan bli av med skiten vi kallar DX12 så är det ju bra att det optimeras. Alltid något.

Visa signatur

CPU: I7 7700k @ 4.6GHz - Noctua NH-D14 - Asus ROG Strix Z270F Gaming.
GPU: GTX 1080ti - Accelero Xtreme III @2 st 120mm cf-v12hp hydro dynamic.
RAM: 32GB DDR4 3200MHz. HÅRDDISK: 4 st SSD, 2 Mekaniska.
MONITOR:1 Optix MAG274R 27" MONITOR:2 Samsung 2693HM 25,5" MONITOR/Tv:3 LG 47lv355n-ZB 47". Nätagg: Corsair Newton R2 1000W. Allt i ett Cooler Master CM Storm Stryker.

Permalänk
Medlem

Jag tror 5% på async compute är som förväntat? Jag säger inte nej till 5% iaf.

Visa signatur

"There are 10 kinds of people, those
that understand binary, and those
that do not"

Permalänk
Medlem

Intressant sätt att marknadsföra ett spel på.
Inte en recension som inte nämner "well optimized".
Nästan som att siterna följer ett manus !

Avskyr verkligen dessa pinsamma försök till klurig marknadsföring.

Permalänk
Medlem

Hardware unboxed är den som genomför benchmarksen och säljer dessa till techspot. Så det finns aningen mer info där. Tänkte bara nämna det.

Jag är inte säker på om man kan dra slutsatsen att DX12>Vulkan enbart p.g.a ett spel. Det ett annat spel där jag sett en jämförelse är Ashes som stödjer både Vulkan och DX12 , och där hamnar ibland DX12 framför vulkan, men större delen av tiden så är vulkan framför DX12. Dock svårt att veta, då scenerna kan skilja på sig lite emellan. Slutresultatet visas dock i slutet av videon, och där hade Vulkan ett bättre resultat i alla kategorier. Sedan vet man inte om de lagt ner mer tid på DX12 eller Vulkan.

Hmm... jag har försökt lista ut en del saker med async compute och dess prestandapåverkan i spel. Första gången jag jag stötte på det var i DOOM (2016), där No AA, TAA (har aldrig nämts officiellt, men kan härledas om man ser noggrant på CPU tiden), TSAA8X som aktiverade async compute. Jag fick det till en ~6% prestandaökning med en RX480 i 1080p och ~7% i 4k om jag jämför FXAA med TSAA8X (med async compute säger även ingame profilern att CPU:n tar längre tid på sig ju högre upplösningen är).
Jag märkte alldeles nyss att Wolfenstein 2 har fått en hel drös uppdateringar som gör så att jag inte kraschar längre när jag aktiverar och avaktiverar async compute. Det har ingen FPS begränsning (ok, 1000 FPS, men det är CPU bundet långt innan dess) så jag testar med så låga inställningar som möjligt och enbart ändra på upplösningen. Då alla effekter i princip var på lägsta nivån, och upplösningen på 640x480 så var async compute ~5% långsammare. Dock så ska vi ta i hänsyn att det var ungefär 475 FPS mot 455 FPS. Att öka upplösningen till 4k så var nu async compute 4% snabbare, 66 FPS mot 69 FPS. Jag har sett ett liknande mönster förut, fast med en annan kontext.

När HWU testade 8700k och 2700X i 35 olika spel så testades även Sniper elite 4 med async compute (med DX12). Följer man testerna från 720p till 1440p så får 2700X ett mycket bättre resultat för 1% minimum i 1440p jämfört med 1080p och 720p. Tidigare har även 2x E5-2670 testats i DOOM och där fick den sämst resultat i 720p och bäst i 4k.
Betyder det att Vulkan och DX12 samt async compute har några inneboende superkrafter för multicore CPU:er? Det kan man inte veta om just async compute, men jag skulle gärna vilja se mer undesökningar på det. Multitrådad command buffer generering kan möjligtvis också ha en påverkan.

Såg en presentation om just att porta från DX11 till DX12 och Vulkan från AMD (mycket möjligt att samma person hjälpte till med detta spel, då det är en AMD sponsrad titel). Timestampen som jag lagt den på är async compute, transfer queues och ett exempel på hur dessa används ihop.

Men iallafall, tror just den titeln är för att AMD ville ha det som DX12 eller Vulkan då de anser att de har mer framgång i såna titlar. Men med RTX på ingång med DX12 och Vulkan som krav så lär vi se flera spel som går över till det. Sedan så är känns det som Turing har nog en hel del att tjäna på att köra saker asynkront även där. När titan V testades så var de spel med async compute de som gav störst prestandaökning jämfört med pascal (DOOM och SE:4) . Enda undantaget var egentligen hellblade , men Ghost recon, For honor och Destiny så var skillnaderna inte lika imponerande. Värt att nämna att den enda titeln som NVIDIA hade för prestandasiffror för Turing som inte hade någon koppling till NVIDIA genom RTX, gameworks eller Ansel var Wolfenstein 2 (mer av en AMD titel, men båda hade en del i utvecklingen för doom), som använder samma motor som doom. Kan även tillägga att resultaten verkar rimliga för wolfenstein.

Mer arbete för en ej garanterad prestandaökning är nog något som många spelutvecklare inte vill göra. Större spelstudios lär vara först att implementera DX12 eller Vulkan. Att den flerkärniga trenden tar fart igen kan också leda till en snabbare övergång. T.ex wolfenstein 2 som utnyttjar 32 trådar utan katastrofala problem med prestandan är ändå inte så illa.

Permalänk
Datavetare

@Radolov: angående Hardware Unboxed vs TechSpot, är väl medveten om deras upplägg men är så pass gammal att jag i princip alltid föredrar text-versionen av en artikel jämfört med att se det som en video, speciellt när det handlar om tester.

Så vitt jag sett är TechSpot-artiklarna identisk med motsvarande Hardware Uboxed video när det kommer till innehåll.

Du pekar på huvudproblemet med "async compute": det är relativt komplicerat att använda och inte alls säkert att man ens får en prestandavinst i slutändan. När det ändå ger en prestandavinst handlar det på PC-sidan om ett par procentenheter. Därför inte speciellt förvånande att det inte riktigt ses som en "killer feature".

Det pratades om 20-30 % prestandavinst med "async compute", det är vad jag förstår också vad man typiskt ser på konsoler. Den stora skillnaden är att på PC är nästan alltid GPU-delen flaskhals medan på konsolerna är nästan alltid CPU-delen flaskhals. Är GPU-delen flaskhals är det ju bara väldigt speciella fall där det kan vara en fördel att lägga ännu mer jobb på GPU!!!

Nvidias Turing-serie kommer med rätt stor sannolikhet göra "async compute" (och därmed DX12/Vulkan) betydligt mer main-stream. Detta då Turing i praktiken består av tre rätt oberoende delar, SMs, Tensor-cores samt RT-cores. Ska man få någon effektivitet alls från Turing måste ju dessa tre delar användas parallellt så mycket som möjligt, då de är oberoende kommer "async compute" ge en massiv prestandavinst mot vad man skulle se med en rent seriell hantering.

En stor skillnad med Turing är dock att "async compute" kommer vara rätt automatiskt där. Utvecklarna jobbar egentligen bara mot Direct X Raytracing APIet (är även på väg för Vulkan i form av "Vulkan RT"), så man slipper hantera de håriga detaljerna.

Just håriga detaljer är är huvudproblemet med DX12/Vulkan. Av vad jag kunnat läsa mig till är dessa två APIer funktionellt extremt nära varandra. Så inte förvånande att vi ser rätt liten prestandaskillnad mellan dessa.

Personligen hoppas jag Vulkan "vinner" då jag föredrar Linux, men tror tyvärr det är rätt osannolikt då spel nästan uteslutande utvecklas på Windows i Visual Studio där verktygen för DX historiskt alltid legat snäppet före andra APIer. Tror därför ändå att DX12 i praktiken kommer ha en liten prestandafördel, det enbart då AMD/Nvidia/Intel kommer lägga mer resurser på att optimera dessa då den marknaden lär komma bli större.

Just att dessa två APIer är så väldigt ner på detaljer gör ändå Apples beslut att köra med Metal rätt lätt att förstå. Metal är mer som OpenGL/DX11 där man fixat bristerna men ändå behållit ett "högnivå API", medan DX12/Vulkan dumpar allt för mycket i knät på spelutvecklarna. Rent praktiskt undrar jag om det finns någon relevant fördel med DX12/Vulkan modellen, den är garanterat dyrare att använda!!!

Angående DX12/Vulkans möjlighet att skala saker över kärnor. Här var förväntningarna totalt fel ställda bland folk på teknikforum likt detta. Finns ingen i dessa som magiskt skulle göra det lätt att köra över väldigt många kärnor, så här långt har vi i flera fall sett det omvända då multi-core optimeringar är extremt dyrt att göra och i spel kommer man med dagens förutsättning aldrig få någon gigantisk utväxling (lite som "async compute").

Vi har ju i flera fall snarare sett motsatsen på Nvidias GPUer, detta då Nvidias DX11 drivare faktiskt ger ett visst mått av "automatiskt" utnyttjande av flera kärnor medan motsvarande är omöjligt att erbjuda i DX12/Vulkan (där är all form av multi-core optimering explicit, d.v.s. måste utföras av spelmotorn).

Vidare är en GPU en tillståndsmaskin sett till grafik, oavsett API går det inte att komma ifrån att alla grafikkommandon måste i slutändan köras i en specifik ordning och dessa grafikkommandon måste skrivas till en enda grafikkö, så man måste serialisera accessen till grafikkö -> det ger en hård gräns för hur pass mycket de grafikintensiva delarna faktiskt kan utnyttja flera kärnor.

Om spel ska dra nytta av många kärnor måste de börja göra beräkningar som är skilda från grafik men som lämpligen körs på CPU. I det läget kvittar det totalt om man kör DX11 eller DX12!

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:

@Radolov: angående Hardware Unboxed vs TechSpot, är väl medveten om deras upplägg men är så pass gammal att jag i princip alltid föredrar text-versionen av en artikel jämfört med att se det som en video, speciellt när det handlar om tester.

Så vitt jag sett är TechSpot-artiklarna identisk med motsvarande Hardware Uboxed video när det kommer till innehåll.

Ja, de är mer eller mindre identiska. Säger bara till de som vill se t.ex inspelat innehåll där även processoranvändningen på individuella kärnor visas. Spelet är inte krävande alls.

Skrivet av Yoshman:

Du pekar på huvudproblemet med "async compute": det är relativt komplicerat att använda och inte alls säkert att man ens får en prestandavinst i slutändan. När det ändå ger en prestandavinst handlar det på PC-sidan om ett par procentenheter. Därför inte speciellt förvånande att det inte riktigt ses som en "killer feature".

Det pratades om 20-30 % prestandavinst med "async compute", det är vad jag förstår också vad man typiskt ser på konsoler. Den stora skillnaden är att på PC är nästan alltid GPU-delen flaskhals medan på konsolerna är nästan alltid CPU-delen flaskhals. Är GPU-delen flaskhals är det ju bara väldigt speciella fall där det kan vara en fördel att lägga ännu mer jobb på GPU!!!

Nvidias Turing-serie kommer med rätt stor sannolikhet göra "async compute" (och därmed DX12/Vulkan) betydligt mer main-stream. Detta då Turing i praktiken består av tre rätt oberoende delar, SMs, Tensor-cores samt RT-cores. Ska man få någon effektivitet alls från Turing måste ju dessa tre delar användas parallellt så mycket som möjligt, då de är oberoende kommer "async compute" ge en massiv prestandavinst mot vad man skulle se med en rent seriell hantering.

En stor skillnad med Turing är dock att "async compute" kommer vara rätt automatiskt där. Utvecklarna jobbar egentligen bara mot Direct X Raytracing APIet (är även på väg för Vulkan i form av "Vulkan RT"), så man slipper hantera de håriga detaljerna.

Just håriga detaljer är är huvudproblemet med DX12/Vulkan. Av vad jag kunnat läsa mig till är dessa två APIer funktionellt extremt nära varandra. Så inte förvånande att vi ser rätt liten prestandaskillnad mellan dessa.

Personligen hoppas jag Vulkan "vinner" då jag föredrar Linux, men tror tyvärr det är rätt osannolikt då spel nästan uteslutande utvecklas på Windows i Visual Studio där verktygen för DX historiskt alltid legat snäppet före andra APIer. Tror därför ändå att DX12 i praktiken kommer ha en liten prestandafördel, det enbart då AMD/Nvidia/Intel kommer lägga mer resurser på att optimera dessa då den marknaden lär komma bli större.

Just att dessa två APIer är så väldigt ner på detaljer gör ändå Apples beslut att köra med Metal rätt lätt att förstå. Metal är mer som OpenGL/DX11 där man fixat bristerna men ändå behållit ett "högnivå API", medan DX12/Vulkan dumpar allt för mycket i knät på spelutvecklarna. Rent praktiskt undrar jag om det finns någon relevant fördel med DX12/Vulkan modellen, den är garanterat dyrare att använda!!!

Jag håller fullständigt med. En extra anledning till att DX12 kommer få en större utbredning är p.g.a de avtal som de stora spelutvecklarna redan har med Microsoft. Det finns nog prestandavinster att hämta in om man har skickliga grafikutvecklare, men det lär bli svårt att konkurrera med AMD:s och NVIDIA:s drivrutinutvecklare.

Skrivet av Yoshman:

Angående DX12/Vulkans möjlighet att skala saker över kärnor. Här var förväntningarna totalt fel ställda bland folk på teknikforum likt detta. Finns ingen i dessa som magiskt skulle göra det lätt att köra över väldigt många kärnor, så här långt har vi i flera fall sett det omvända då multi-core optimeringar är extremt dyrt att göra och i spel kommer man med dagens förutsättning aldrig få någon gigantisk utväxling (lite som "async compute").

Vi har ju i flera fall snarare sett motsatsen på Nvidias GPUer, detta då Nvidias DX11 drivare faktiskt ger ett visst mått av "automatiskt" utnyttjande av flera kärnor medan motsvarande är omöjligt att erbjuda i DX12/Vulkan (där är all form av multi-core optimering explicit, d.v.s. måste utföras av spelmotorn).

Nja, jag skulle nog inte säga att ingenting i DX12/Vulkan ger bättre möjligheter att skala över fler kärnor. Redan när mantle släpptes talades det om fördelar för flerkärniga processorer jämfört med DX11/OpenGL. I doom med 2x E5-2670 och GTX 1080 så är skillnaden enorm om man jämför OpenGL och Vulkan. ~80 mot 190 FPS. Intressant att se att mer arbete (och mer utspritt arbete över kärnorna) utförs , samtidigt som hög prestanda fås.

Jag tycker dock att det är roligare att undersöka saker själv. Så jag tar det som jag har tillgängligt, RX480, 1700X @ 3.8Ghz, 16GB 3066Mhz CL14. Jag tänker undersöka hur vissa applikationer skalar över flera kärnor. De applikationer som testas är:
Ett Vulkan exempel på multitrådad command buffer generering, DOOM Vulkan (högsta inställningar, men låg upplösning), DOOM GL, Wolfenstein 2 med låga inställningar och låg upplösning. I samtliga fall ges ingen input från tangentbordet och medelvärden från FPS tas. Kärnorna aktiveras i ordningen 0, 1,2,3...15.

Vid samtliga fall så kommer de till en gräns där mer prestanda omöjligen kan fås. Dessa gränser är:
9 kärnor för vulkanexemplet, 6 kärnor för wolfenstein 2, 5 kärnor för OpenGL i doom, 11 kärnor för openGL i vulkan. Jag kollade även in hur lång tid CPU:n användes för de punkter där prestandan är maximal i doom, och jämförde mot 16 kärnor i doom (genom att skapa en GPU bottleneck, 1080p). Då får jag ut att i GL så är tiden 12.6 ms vid 5 kärnor, och 10.6ms för 16 kärnor. Så rent tekniskt så sker det en förbättring, men uppenbarligen på en annan sida än renderingen.
För Vulkan så var dessa siffror 4.82ms vid 11 kärnor, och 4.65 ms vid 16 kärnor. Det uppstod ett mönster när logiska kärnor aktiverades, så ökade CPU tiden.

Det kan vara två saker som sker: Antingen så sänks i teorin den snabbaste FPS:en med ett snabbare grafikkort, eller så ökar arbetet som utförs på nästkommande frames (detta kan ske med async compute för deras profiler. Då sjunker GPU tiden samtidigt som CPU tiden ökar, och resulterar i högre FPS). För att testa detta så jämförde jag med SMT på och av. Med SMT av så var AVG CPU 4.35ms och ~7.3ms per ruta, medan med SMT så var AVG CPU 4.65ms och ~7.25ms per ruta. Det kan dock ha varit vilket som, då skillnaderna är så extremt små och den mänskliga faktorn spelar in i mätningarna.

Det fanns ingen chans i världen att automatiskt utnyttjande av flera kärnor i NVIDIAs drivers skulle skala över ett stort antal kärnor. Det är av den anledningen som jag påstår att om fler kärnor blir vanligare, så bör rimligtvis lågnivå API:er få en större spridning. Jag säger inte att 16 kärniga processorer helt plötsligt blir mycket snabbare än 6 eller 8 kärnor. Det blir bara inte lika dåligt att köra på dem som förut.

Permalänk
Datavetare
Skrivet av Radolov:

Nja, jag skulle nog inte säga att ingenting i DX12/Vulkan ger bättre möjligheter att skala över fler kärnor. Redan när mantle släpptes talades det om fördelar för flerkärniga processorer jämfört med DX11/OpenGL. I doom med 2x E5-2670 och GTX 1080 så är skillnaden enorm om man jämför OpenGL och Vulkan. ~80 mot 190 FPS. Intressant att se att mer arbete (och mer utspritt arbete över kärnorna) utförs , samtidigt som hög prestanda fås.

Jag tycker dock att det är roligare att undersöka saker själv. Så jag tar det som jag har tillgängligt, RX480, 1700X @ 3.8Ghz, 16GB 3066Mhz CL14. Jag tänker undersöka hur vissa applikationer skalar över flera kärnor. De applikationer som testas är:
Ett Vulkan exempel på multitrådad command buffer generering, DOOM Vulkan (högsta inställningar, men låg upplösning), DOOM GL, Wolfenstein 2 med låga inställningar och låg upplösning. I samtliga fall ges ingen input från tangentbordet och medelvärden från FPS tas. Kärnorna aktiveras i ordningen 0, 1,2,3...15.

Kolla in den applikation du nämner här, den renderar bara från en enda tråd (kolla in t.ex. updateCommandBuffer()). Det var min poäng ovan, i slutändan är man alltid tvungen att serialisera accessen till grafikkön -> hur mycket man kan utnyttja flera CPU-kärnor kommer alltid bli väldigt begränsad.

Vad man gör i det exemplet i threadRenderCode() är spelar in en kommandobuffert som sedan skickas till primärtråden som spelar upp den bufferten mot grafikkön (det man kallar primär instruktionskö).

Men den möjligheten finns ju även i DX11 i form av deferred context

"However, you can create and use multiple deferred contexts simultaneously, each in a separate thread. Then, you can use those multiple deferred contexts to simultaneously create multiple command lists."

Precis som man i Vulkan (och DX12) i slutändan måste serialisera access till grafikkön gäller exakt samma sak för DX11

"You cannot play back two or more command lists simultaneously on the immediate context."

Skrivet av Radolov:

https://i.gyazo.com/42d1d12e5d578d74e74ebb91b46837db.png
Vid samtliga fall så kommer de till en gräns där mer prestanda omöjligen kan fås. Dessa gränser är:
9 kärnor för vulkanexemplet, 6 kärnor för wolfenstein 2, 5 kärnor för OpenGL i doom, 11 kärnor för openGL i vulkan. Jag kollade även in hur lång tid CPU:n användes för de punkter där prestandan är maximal i doom, och jämförde mot 16 kärnor i doom (genom att skapa en GPU bottleneck, 1080p). Då får jag ut att i GL så är tiden 12.6 ms vid 5 kärnor, och 10.6ms för 16 kärnor. Så rent tekniskt så sker det en förbättring, men uppenbarligen på en annan sida än renderingen.
För Vulkan så var dessa siffror 4.82ms vid 11 kärnor, och 4.65 ms vid 16 kärnor. Det uppstod ett mönster när logiska kärnor aktiverades, så ökade CPU tiden.
https://i.gyazo.com/a9c0265ab584ac97690a2547114a4500.png

Nu testade jag programmet dels på en laptop med Intels iGPU (där blev det exakt samma prestanda vare sig man körde en CPU-tråd eller fyra CPU-trådar, detta med Ubuntu, inte ens 320x200 upplösning ändrade något i sak). Såg ingen större skillnad på ett GTX970 heller som drivs av en i7-5775C, en viss boost från en till två arbetstrådar (detta med Win10). i7-5775C är dock rätt ordentligt overkill för GTX970, ska uppgradera till RTX2080 alt. RTX2080Ti vad det lider då kanske man ser bättre skalning.

Huvudpoängen med DX12/Vulkan var aldrig att kunna skala över CPU-kärnor, huvudpoängen var att göra något med lägre "draw-call overhead" -> är primärt fallen där CPU-delen är en flaskhals som gynnas, vare sig de har 2, 4 eller massor med kärnor.

När TechPowerUp testade Wolfenstein 2 ligger ju faktiskt 4C/4T modeller i topp, det i 1280x720 med GTX1080Ti!!!

Edit:

När man testade i7-8700K hade man fortfarande med Doom/Vulkan, det slår ju nästan i 200 FPS cap:en med en G4560 (2C/4T @ 3,5 GHz), frågan hur mycket det är därför Doom går att driva med en miniräknare (Xbox One X drar runt den titeln riktigt bra i 4k) och hur mycket som kommer från Vulkan (har för mig att det var väldigt lättdrivet även med OpenGL)
Skrivet av Radolov:

Det fanns ingen chans i världen att automatiskt utnyttjande av flera kärnor i NVIDIAs drivers skulle skala över ett stort antal kärnor. Det är av den anledningen som jag påstår att om fler kärnor blir vanligare, så bör rimligtvis lågnivå API:er få en större spridning. Jag säger inte att 16 kärniga processorer helt plötsligt blir mycket snabbare än 6 eller 8 kärnor. Det blir bara inte lika dåligt att köra på dem som förut.

Det hävdade jag aldrig heller. Med DX11 kan flera kärnor användas både explicit (med DX11 deferred context) men även implicit om man har ett Nvidia kort. Något Nvidia specifikt nämner inte är teknisk möjligt med DX12

"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"

Det fanns absolut brister i DX11, t.ex. så finns designmissar som till viss del begränsar effektiviteten hos "deferred context". Men känns ändå som man angrep problemet på helt fel sätt när man skapade DX12/Vulkan, något som Apple rätt mycket visat med Metal som i princip är ett DX11 med de kända misstagen lösta -> samma fördelar som DX12/Vulkan men utan att man behöver dras lika mycket pillriga detaljer.

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:

Kolla in den applikation du nämner här, den renderar bara från en enda tråd (kolla in t.ex. updateCommandBuffer()). Det var min poäng ovan, i slutändan är man alltid tvungen att serialisera accessen till grafikkön -> hur mycket man kan utnyttja flera CPU-kärnor kommer alltid bli väldigt begränsad.

Vad man gör i det exemplet i threadRenderCode() är spelar in en kommandobuffert som sedan skickas till primärtråden som spelar upp den bufferten mot grafikkön (det man kallar primär instruktionskö).

Ja, threadpool.wait() kommer inte ha ett annat beteende än i vanliga fall, dvs många trådar leder till snabbt ökande synkroniseringstider. Märkte även att en command buffer ignoreras om ett objekt inte syns i view frustum.

Skrivet av Yoshman:

Men den möjligheten finns ju även i DX11 i form av deferred context

"However, you can create and use multiple deferred contexts simultaneously, each in a separate thread. Then, you can use those multiple deferred contexts to simultaneously create multiple command lists."

Precis som man i Vulkan (och DX12) i slutändan måste serialisera access till grafikkön gäller exakt samma sak för DX11

"You cannot play back two or more command lists simultaneously on the immediate context."

Ja, det är lite förvirrande när det finns en tidigare slide från flera år tidigare när samma person säger att det är möjligt i DX11. Han måste ha menat DX10 och innan eller något...

Skrivet av Yoshman:

Nu testade jag programmet dels på en laptop med Intels iGPU (där blev det exakt samma prestanda vare sig man körde en CPU-tråd eller fyra CPU-trådar, detta med Ubuntu, inte ens 320x200 upplösning ändrade något i sak). Såg ingen större skillnad på ett GTX970 heller som drivs av en i7-5775C, en viss boost från en till två arbetstrådar (detta med Win10). i7-5775C är dock rätt ordentligt overkill för GTX970, ska uppgradera till RTX2080 alt. RTX2080Ti vad det lider då kanske man ser bättre skalning.

Huvudpoängen med DX12/Vulkan var aldrig att kunna skala över CPU-kärnor, huvudpoängen var att göra något med lägre "draw-call overhead" -> är primärt fallen där CPU-delen är en flaskhals som gynnas, vare sig de har 2, 4 eller massor med kärnor.

När TechPowerUp testade Wolfenstein 2 ligger ju faktiskt 4C/4T modeller i topp, det i 1280x720 med GTX1080Ti!!!

Edit:

När man testade i7-8700K hade man fortfarande med Doom/Vulkan, det slår ju nästan i 200 FPS cap:en med en G4560 (2C/4T @ 3,5 GHz), frågan hur mycket det är därför Doom går att driva med en miniräknare (Xbox One X drar runt den titeln riktigt bra i 4k) och hur mycket som kommer från Vulkan (har för mig att det var väldigt lättdrivet även med OpenGL)

Jag kan bara stå för mina egna siffror och de som visas i spelet, men det kan mycket väl vara så att det är de som presterar bäst. Svårt att avgöra utan att se testscenen.

Skrivet av Yoshman:

Det hävdade jag aldrig heller. Med DX11 kan flera kärnor användas både explicit (med DX11 deferred context) men även implicit om man har ett Nvidia kort. Något Nvidia specifikt nämner inte är teknisk möjligt med DX12

"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"

Det fanns absolut brister i DX11, t.ex. så finns designmissar som till viss del begränsar effektiviteten hos "deferred context". Men känns ändå som man angrep problemet på helt fel sätt när man skapade DX12/Vulkan, något som Apple rätt mycket visat med Metal som i princip är ett DX11 med de kända misstagen lösta -> samma fördelar som DX12/Vulkan men utan att man behöver dras lika mycket pillriga detaljer.

Jag hävdade aldrig att du hävdade det, så då kan man upphäva den diskussionen. Jag är inte tillräckligt insatt i metal för att kunna kommentera det.

Permalänk
Datavetare
Skrivet av Radolov:

Ja, threadpool.wait() kommer inte ha ett annat beteende än i vanliga fall, dvs många trådar leder till snabbt ökande synkroniseringstider. Märkte även att en command buffer ignoreras om ett objekt inte syns i view frustum.

Ja, det är lite förvirrande när det finns en tidigare slide från flera år tidigare när samma person säger att det är möjligt i DX11. Han måste ha menat DX10 och innan eller något...

Jag kan bara stå för mina egna siffror och de som visas i spelet, men det kan mycket väl vara så att det är de som presterar bäst. Svårt att avgöra utan att se testscenen.

Jag hävdade aldrig att du hävdade det, så då kan man upphäva den diskussionen. Jag är inte tillräckligt insatt i metal för att kunna kommentera det.

Tycker inte dina mätningar egentligen alls motsäger vad TechPowerUp fått. Dels mäter ju lite olika saker och tar man t.ex. din datapunkt för 4C/4T fallet i Wolfenstein så ligger din R7-1700X på 3,5 GHz (om den inte är överklockad) medan i3-8350K ligger på 4,0 GHz.

Jämför man sedan prestanda utan SMT (Windows kommer inte använda mer än en tråd per CPU så länge man lastar färre trådar än det finns fysiska kärnor) och skillnaden vid samma frekvens mellan Kaby Lake och Zen i de spel som inte är uppenbart GPU-begränsade även i 1280x720 i TechPowerUps tester får man ungefär en fördel på ~25 %.

Lägger man på det i din graf skulle ju en i3-8350K slå i 200 FPS cap:en i Doom även i din graf när den kör med 4C/4T och även nå vad som ser ut att vara GPU-cap:en i din Wolfenstein mätning. Då ett RX-480 lär vara snabbare än ett GTX970 i Vulkan så blir inte heller mitt resultat speciellt konstigt givet att en i7-5775C lär vara minst lika snabb som en i3-8350K per tråd (kör MCE på dator, så alla kärnor går på 3,8 GHz).

Länken du postar säger väl exakt samma som MSDN länken jag postade? D.v.s. i DX11 kan man "spela in" kommandon på olika trådar (där då en hel del av "draw-call" kostnaden kan betas av) för att sedan bara kopiera den färdiga strömmen till grafikkön när det passar (den tråden får då mindre last).

De teoretiska fördelarna med DX12/Vulkan är att lite mer av jobbet kan utföras "up-front", men som jag förstått det är det primära att man designat om vissa saker så det är möjligt att utföra vissa operationer med lågt färre cykler i DX12/Vulkan. Det senare är ju en fördel oavsett hur många CPU-kärnor man råkar ha.

Angående OpenGL vs Vulkan i Doom, där är det en signifikant skillnad, framförallt med CPUer med lite sämre enkeltrådprestanda (så var ute och cyklade där). Däremot har de flesta fall jag sett där man jämfört DX11 vs DX12 (eller Vulkan som t.ex. DOTA) inte visat någon relevant skillnad, har kunnat slå åt båda håller vilket även SweClockers såg i deras artikel igår där man jämför Fury X och GTX980Ti.

Så tror vi ändå är rätt överens

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

@Yoshman: Jag skulle säga att vi är överens. Jag vet inte exakt vilka parametrar exakt som påverkas av att jag har 16 trådar ursprungligen, men kör med färre trådar. 7600k hamnar ju trots allt väldigt högt upp med 4c/4t på flera ställen.
Sånt kan möjligtvis påverka resultaten (speciellt då jag inte har annan hårdvara att testa med). Jag ser fram emot att se idTech7 där de har ökat geometrin i scenerna med 5x(!).

Varför dota2 inte har så bra prestanda i Vulkan är för mig ett mysterium (i synnerhet då Valve är den största sponsorn av proton, LunarXChange och har sitt namn på sidan av den officiella tutorialen). Möjligtvis har det att göra med att de har en väldigt stor frihet när det kommer till att välja projekt att arbeta på och att det helt enkelt inte blivit gjort så mycket.

Jag har även lite ny information angående RTX i battlefield V. I en video från Digitalfoundry så får vi reda på att RT cores körs efter rasterisering av G-buffern. Ett filter används för att få bort granularitet (och tensor cores används inte för tillfället). Jag vet inte om NVIDIA sitter och klurar med drivers eller om det krävs något explicit (såsom async compute) för att få RT cores att köra asynkront. Det förklarar även prestandan, och varför granularitet kan vara uppenbar på vissa ställen.

Jag ställer mig iallafall positiv till att tekniken går framåt, men vill helst inte se alltför stora kompromisser (höga priser, 1080p 60 istället för 4k ~90 , etc.). Mina förhoppningar är att prestandan ökar signifikant när de fått allting att köra asynkront och dessutom använda tensor cores.

Permalänk
Medlem

PCgameshardware.de har publicerat sitt test nu och det är enda testet jag sett som inkluderar Kepler (GTX 780) och GCN 1.0 (R9 280x).

http://www.pcgameshardware.de/Strange-Brigade-Spiel-61029/Spe...

Överlag verkar ju AMD ha övertaget i dethär spelet.

Permalänk
Hjälpsam
Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |