AMD arbetar på optimerade drivrutiner för Rise of the Tomb Raider

Tycker det är så fruktansvärt fel när en spelutvecklare samarbetar mer direkt gällande drivrutiner med ett grafikkortsföretag när det finns två. Det är så klart business men varken spelutvecklaren eller grafikkortsföretaget växer direkt i ens ögon. Hade inte sett några problem ifall t.ex Nvidia jobbade för att få in specifika funktioner som deras kort stöder men när det handlar om att en ska vara före med optimerade drivrutiner så blir man lite ledsen i ögat.

Hoppas AMD kan få ut sina drivrutiner snart och ska bli intressant att se hur stor skillnad dom kommer göra i spelet. Förhoppningsvis gör Sweclockers en uppföljning.

Konstig fråga med tanke på att lanseringen var igår och att fixen inte är släppt än.

Det är väl dessutom inget märkligt med tanke på att det är ett Nvidia-spel (Gamewrecks). Amd har ju inte haft en chans att optimera innan release.

Är detta värt en nyhet? Jag menar... Det dyker väl alltid upp drivrutiner optimerade för nya AAA-spel? Förr eller senare.

Källa på det senare?

Förövrigt ska de ju ha samarbetat även med AMD, exempelvis med PureHair.

Har ingen formell källa på det, men om det är ett Gamewrecks-spel så vore det ju inte så konstigt om så var fallet, hade inte varit första gången ett Nvidia-spel fungar dåligt på Amd.

TressFX 3.0 (Pure Hair) är ett bibliotek i GPUOpen, det måste därför inte betyda att Amd har haft chans att optimera annat än just håret i Tomb Raider.

Fast mycket tyder på att det inte är Gameworks finesser som HBAO+ som är boven till att spelet relativt sett presterar sämre på GCN än Maxwell jämfört med "normalt". För övrigt användes inte HBAO+ i SweClockers snabbtest. Det stora droppet för GCN ligger mellan "medium" och "high", i "high" slås bl.a. tessellation på vilket inte har med Gameworks att göra utan är en standardfunktion i DX11.

Är det för övrigt något mer än HBAO+ (ShadowWorks) och TXAA (PostWorks) som kommer från Gameworks i denna titel? GCN har inga problem med någon av dessa finesser.

Det ironiska här är att det var ATI som för över 10 år sedan började pusha för tesselering, nu när det väl finns som en standardfiness i DX och även börjar användas allt mer (och i Rise of the Tomb Raider används det på många ställen enligt Eurogamer, kolla 6:14 i videon nedan) så verkar man ha försummat just detta då geometrikapaciteten är långt högre i Maxwell för konkurrerande GCN modell.

@Yoshman: Funderar på vad du menar med Geometrikapacitet?

Det går att hitta svaga punkter i alla kretsar, frågan är varför man väljer att använda det som konkurenten är sämst på in absurdum, finns ingen anledning till att Tesselera något som bara har ett par pixlars storlek, ytterligare.

Tycker inte att det finns mycket till Ironi, Tesseling är något bra så länge det inte missbrukas.

Ja, som du nämner är det just "förr eller senare" som är kärnfrågan. Bakgrunden är att Sweclockers valde att presentera en test av Rise of the Tomb Raider med en mängd grafikkort som en stor nyhet då de precis fått en pinfärsk drivrutin optimerad för Tomb Raider från Nvidia, och i samma test använde en icke optimerad drivrutin från AMD.

Det visade såklart hur läget såg ut, och som det ser ut nu, det går inte att förneka. Men eftersom Rise of the Tomb Raider är ett TWIMTBP-spel har ju AMD med största sannolikhet inte haft tillgång till den slutgiltiga versionen av spelet, medan Nvidia har haft det under en längre tid, och då är det ju inte riktigt fair play att publicera en sån stor test. Iaf går det inte att dra några större växlar på det. Bättre att istället vänta med testet tills AMD också fått en rimlig chans att hinna optimera (i den mån det går), såvida de inte segar med att leverera, såklart.

Då hade det varit roligare, mer lärorikt och intressant att se en test med bara Nvidiakort, där man jämfört prestandan i den äldre Nvidiadrivrutinen mot den nya optimerade drivrutinen för att se ev skillnader. I första steget kunde man skippat AMD helt och hållet, eftersom det ändå nu mest blev en del av Nvidias marknadsföring. Nvidia hade ju spelet i sin hand, så att säga.

Den här nyheten kan därför ses mot bakgrund av diskussionen i forumet till den testen. Rent allmänt är jag kritisk mot Day 1-tester av sponsrade spel, vare sig sponsorn är Nvidia eller AMD, det blir ju alltid obalanserat. Från publicistisk synvinkel kan man säkert argumentera om vad som väger tyngst, allmänintresset och ivern att presentera en nyhet med ett nytt spel, kontra risken att vara en del av marknadsföringen för en sponsor? Det är mer den diskussionen som intresserar mig i det här fallet.

Om AMD inte försöker optimera är det en annan sak att "hänga ut" dem, men nu verkar det alltså som att de reagerar inom rimlig tid, och kommer att leverera en ny drivrutin snarare förr än senare. Och då blir ju testen med en gång historia iaf.

Tur att man inte köper grafikkort baserat på prestandan i ett visst spel vid releasedag.

För så dum kan man väl inte vara...

Väldigt förenklat kan man säga: kretsen kapacitet att trycka trianglar genom pipeline. Det som än mer antyder att det just är det är antalet trianglar detta spel processar är hur nära 390/390X/Fury/FuryX presterar varandra i 1080p/1440p, dessa kort har all samma geometrikapacitet per MHz.

Inget är bra om det missbrukas och i just denna titel verkar ju tesseling användas på ett sätt så det faktiskt tillför något. Sedan är det också något som går att slå av separat, så enkelt att åtgärda.

I DX11 är ju API-designen en stor flaskhals till hur många trianglar man i praktiken kan hantera, enda sättet att riktigt pusha detta är tesseling då trianglar skapas dynamiskt i GPUn (d.v.s. noll overhead från DX APIet). Med DX12/Vulkan blir det möjligt att faktiskt kraftigt öka antal trianglar som används i modellerna, få se vad det betyder för dagens GPUer.

Och visst har alla kretsar svaga punkter, något om helt verkar gå många förbi när de hävdar att Nvidia skiter i Kepler. Den kretsen har svagheter som tyvärr för Keplerägarna har blivit allt mer framträdande i moderna titlar. Det är inget som går att fixa med drivare utan är en konsekvens utav riktningen tekniken i speldesign har tagit.

Microsoft verkar ha åkt på en liknande mina med XboxOne, mängden eDRAM är tillräckligt för 1920x1080 med "forward rendering" men det är för lite idag då nästan alla spel gått över till "deferred rendering", är ingen slump att spelen typiskt kör 1600x900, med den upplösningen behövs strax under 32 MB för de mest bandbredskrävande delarna i "deferred rendering".

Mest kanske detta visar hur totalt hopplöst det är att avgöra vilken krets som är mest "framtidssäker"...

Vad hittar du information om att det är så? Läser man EULA för GameWorks så finns ingen sådan restriktion, däremot får en speltillverkare inte skicka med GameWorks SDKn till 3:e part men finns inget hinder att skicka med biblioteken i binärform.

Börjar bli tragiskt med alla dessa förberedda titlar, vare sig det är Nvidia eller AMD.
Spelet släpps, benchmarking görs och företaget som är förberedd vinner.

Hur många stora sidor gör om testerna när båda lagen har optimerat drivrutinerna ?

Du gör ett påstående och motsäger det i samma inlägg. GG

@Ratatosk: en drivrutin kan rimligen inte innehålla patchar i form av förändring av själva spelbinärerna, något som skulle krävas om man ska göra förändringar i spelets kod. En sådan förändring skulle haverera så fort man trycker ut nästa patch för spelet. Alla eventuella optimeringar i spelkoden måste levereras som patch för spelet.

I drivrutiner kan man analysera saker som vilken frekvens och vilken typ av anrop som spelet gör via DX11 mot drivers och sedan optimera utifrån det. Är just detta man gjort när man släpper drivare med optimeringar för specifika titlar. Den här typen av optimeringar kan rent tekniskt utföras helt utan att ha källkod till någon del av spelet. Har själv gjort just den här typen av optimeringar i operativsystem, i det läget bryr man sig överhuvudtaget inte om källkoden till de program som körs ovanpå OSet utan det enda man analyserar är hur de använder OS-anropen och från det funderar man vad man kan göra i OSet för att köra just den lasten snabbare.

Är därför skitsnack från AMDs sida att de inte kan optimera titlar som använder Gameworks bara för man inte har tillgång till källkoden. Gameworks använder bara standardfunktioner i DirectX som i sin tur använder underliggande drivare.

@Yoshman: jag läste något annat, kan möjligtvis vara fel, det handlade om att man ibland kunde byta ut delar av den kod som anropade hårdvaran, kräver som sagt, tillgång till spelets källkod.
Nej det är givetvis inte fråga om en drivrutin när du patchar ett spel, patchen levereras dock med rutinen och av AMD eller Nvidia.

Tycker att du underskattar AMD, det vore ganska naivt av dem att försöka sig på en lögn som enkelt kan avfärdas som "skitsnack".

Det handlar om att de vill få tillgång den större möjlighet att optimera, som de får, om de har tillgång till kjellkåden.

Med risk för att underskatta Nvidia, att få vissa spel att gå dåligt med AMD-kort, borde inte ligga i deras intresse, det stora problemet för både AMD och Nvidia är PC-plattformens popularitet som spelplattform, vad de håller på med nu, riskerar att skjuta PC-spelandet totalt i sank.