Snabbtest: Doom med Vulkan

Detta har även uppmärksammats på andra spel t.ex. i Dota med Nvidia kort så verkar det som spelet flyter på bättre i Vulkan även fast det är lite lägre Fps i Vulkan.

Har du kollat att du inte har något "DPC latency" problem sett många som har haft problem med just gtx 1070, Msi verkar haft en hel del problem med detta, även andra tillverkare har samma problem, verkar vara något problem med micron minnen, på dom korten som tillverkas i kina. Du kan kolla vad du har för minnen i GPU-Z.

Ifall du har micron minnen, kanske du kan byta ut kortet ifall du fortfarande har tid kvar, eller reklamera kortet.

Var problem på även 1080 med "DPC latency", Nvidia har släppt en hotfix för detta men verkar inte som det löst problemet för alla.

Kan läsas mer om detta här: https://www.reddit.com/r/nvidia/comments/4wh8jc/msi_officiall...

Och här: http://www.overclock.net/t/1605618/ongoing-pascal-latency-pro...

OT: Riktigt imponerande prestanda med Fury X, verkar som att kortet äntligen får sträcka på benen.
Vulkan verkar vissa vad korten verkligen kan prestera, hoppas på flera spel med vulkan med bra implementation.

Siter att jämföra Sweclockers resultat med är tex. PC perspective, Anandtech, Techreport, Guru3d och Hardocp. När Swe clockers benchar överensstämmer med dessa så kan man vara lugn med att resultaten är korrekta. När dom sticker ut kan man spekulera i varför.

Relativt ny och oslipad än i jämförelse kanske.

I din graf kan du inte gör ett snitt för alla testerna då det skulle bli det mest rimliga resultatet? ny rad snitt alla test

Mest rimliga är att RX480 ska få en boost mellan 25-35% när man går från OpenGL till Vulkan på 1440p beroende på AA/AF under Ulra inställningen (vilket alla kör). SweC fick fram 9%

Mest rimligt är också att skillnaden i boosten på 1080p och boosten i 1440p bör vara runt 95% i jämförbar ökning. SweC fick fram 80%

Skickades från m.sweclockers.com

från 47 till 67 med furyx och 45 till 53 med 390x.

Jag är också lite sisådär på att räkna ut procent så denna är guld att ha som bokmärke:
http://www.percentagecalculator.net/

GTX1080 är fortfarande snabbast.

Tänkte bara föreslå ett par andra tänkbara felkällor som kanske kan ha drabbat RX 480 och dess något annorlunda värden jämfört med andra sajter.

Att byta upplösning inne i spelet utan att starta om.
Min erfarenhet av att byta upplösningen inne i menyn i Doom utan att starta om är att det kan sabba prestandan. För att vara säker på att undvika den ev prestandaförlusten måste man starta om. Vet inte hur testandet gått till, men eftersom det säkert tar dryga minuten att ändra upplösning och sedan vänta på alla introsekvenser efter omstart, är det ju inte otänkbart att det har varit lockande att hoppa från 1080p till 1440p och sen till 2160p utan omstart. Speciellt i en snabbtest.
Om det då råkar introduceras ett fel vid ett byte, så består det. Då hjälper det inte att köra testslingan flera gånger efter varandra. Man får visserligen samma resultat, och luras därför att tro att det är korrekt. Felet och dess prestandaförlust ligger dock latent kvar i varje körning, tills nästa omstart. Vilket då troligtvis sker med ett nytt kort,

Att testa med demon och inte fullskalespelet.
Jag fick bättre prestande med fullskale-Doom jämfört med demon, subjektivt kanske 10% bättre i hissen i The UAC. Återigen vet jag inte hur testet genomförts, men när Emil pratade om testet i Fredagspanelen pratade han om att hitta en upprepbar sekvens som passade. Det finns en sådan sekvens i början av nivån Advanced Research Complex som är en rälsåkning (ungeför som testslingorna i Far Cry 4 och BF 4). Kanske inte så representativ slinga för spelet, men konsekvent likadan varje gång i knappt en minut. Att nivån The UAC används istället, dvs samma nivå som i demon, kan tala för att det är demon som testats, och inte fullskaliga spelet. Och de kan alltså skilja sig i prestanda.

Fel i Sweclockers egna rutiner/program.
Det har hänt tidigare, prestandan i t ex DX 11 stämde inte överens för GTX 1070 i RotTR mellan DX11 och DX12-sidorna (vilket nu rättats). Fel kan alltså drabba enskilda kort i Sweclockers egen hantering.

Jag kan bara köra med ett kort i detta spelet. Får +60bps 4K men vill att 3 kort går i halvfart istället för ett som får jobba i 70-100% (Fury X kort)

Skickades från m.sweclockers.com

Blir lite nekropost på denna, har haft _väldigt_ mycket annat att göra sedan i fredags.

Kikar man i specifikationen så handlar det faktiskt om variabel storlek på instruktionerna, få är faktiskt kortare än 96 bitar (3 st 32-bitars ord)!

SPIR-V har bara en standardiserat sätt att stoppa in icke-standardiserade instruktioner. Det är väldigt snarlikt hur x86 idag använder VEX-kodning för att lägga till nya saker till SSE/AVX. Även om Sandy Bridge begriper sig på VEX så kan den ändå inte köra AVX2 instruktioner då den inte har någon aning om vad de nya opkoderna ska göra. Däremot kan en äldre CPU ändå se vilka register som används då det är standardiserat i VEX.

SPIR-V fungerar i stort sätt exakt lika, även för tillägg kan man hoppa runt mellan instruktionerna då dess storlek står i den standardiserade delen. Men precis som med VEX betyder opkoderna ingenting för en implementation som "bara" implementerar Vulkan 1.0, något som står klart och tydligt i just sektion 3.1

"Extended instruction sets are specified in separate documents from the core specification."

"These numbers are part of the specification of the extended instructions, and must be shared by at least the front end creating SPIR-V and the back-end lowering it to a target instruction set."

Det sista säger i princip: man måste ha kontroll på både den ände som genererar koden och den som konsumerar den, SPIR-V är bara en bärare av information som endast har någon vettig mening för ett specifikt kontext. I fallet shader instrincts functions för GCN är det bara relevant GCN back-end.

Rent teoretisk kan naturligtvis Nvidia göra något motsvarande, men t.ex. "baliot" är ju något som kan användas i specifika fall där man normalt skulle behöva atomära instruktioner. Det finns dock ingen 1:1 mappning mellan instruktionen och vad man ska göra om den inte finns, finns inte ens någon rimligt väg att ersätta instruktionen då det skulle bli betydligt långsammare än att köra den generella vägen.

D.v.s. shader instrincts function låser helt fast kod som använder det i en specifik GPU eller familj av GPUer.