Vulkan ger upp till 60 procent bättre prestanda i spelmotorn Unity

Att vi har Vulkan-drivare/implementationer på flera plattformar som presterar bra ska nog ses som meriterande och en god förbättring av läget.

Trodde t.ex. att Nintendo Switch bara skulle få Nvidias custom-API NVN, men det finns ju nu tecken på att Vulkan kan komma dit. Har vi vettiga implementeringar från ARM, Qualcomm, Intel, RTG och Nvidia för samma API, över flera olika OS så är det ändå något positivt. Handlar ju åtminstone om GNU/Linux, Android och Windows – macOS verkar få nöja sig med MoltenVK. Det behöver inte vara bättre än D3D12, bara jämförbart och öppet, och ha utvecklare och verktyg som stödjer det. Det finns sämre anledningar att ha flera APIer att välja på. Men det finns ingen vidare anledning att döda den ena, OGL har bland annat används för att utveckla funktioner som blev standard i DX, och nu senare tar man snarare teknik från andra hållet, men är fortfarande något man kan använda för att utveckla nya saker på. Sen tar man såklart in teknik man utvecklat för konsolerna på deras egna lågnivå-apier in i PC med både Vulkan och DX. Tekniska utvecklingen sker hur som helst, det är bra om man får möjlighet att använda funktionerna på fler plattformar och det är bra att det inte får samma hat från utvecklarna som OGL fått p.g.a. knepiga implementationer.

Nu svarar jag visst på mitt eget inlägg, men alternativet för Unity här hade ju varit att porta till både D3D12 och Vulkan eftersom motorn behöver rulla på både Android och Windows. Nu kan de använda samma API och kod på bägge plattformarna mer eller mindre och saker de lär sig på Android kan användas på Windows och vise versa. De kan möjligen använda lite mindre resurser för att få jobbet gjort och behöver inte samma djupa kompetens inom DX12, vilket iofs deras medarbetare kan ha ändå men behöver inte lägga tiden på två olika lågnivå-APIer nu. Sen behöver nog Unity göra mycket för att öka prestandan i övrigt.

Inte riktigt, det är 30-60 % de talar om. Windows, GNU/Linux, Android och Tizen är målen det körs på. Såklart svårt att jämföra DX11 med Vulkan, men Unity har nog gjort arbete för att förbättra prestandan där med, för Android och Linux handlar det snarare om OGLES eller dåligt optimerade drivrutiner. För det senare låter upp till 60 % ganska rimligt. Är inte mycket de sagt, men koden/betan har funnits ute ett tag.

https://youtu.be/pUYmEI26elw?list=PLX2vGYjWbI0S1LhF7-VsBDCcZy...

Ja du snackar fyllesnack. OpenGL är mjukvara som hårdvaran kan accelerera om den vill, precis som Direct3D, Playstation 4:as GNMX o.s.v. OpenGL kan bara implementeras i programvaran – drivrutinen. WDDM/windowsdrivrutiner kör saker i ring0 också för övrigt. Man kan implementera saker i drivrutiner som hårdvaran inte har några funktioner för, men det är för det mesta så slött att det undviks. I båda fallen har drivrutinen en stor del av hanteringen i usermode-delen. När det gäller OGL finns det gott om fall där de släppt nya specifikationer utan att kräva något nytt av hårdvaran, hårdvaran kan också ha gjort saker som låg som extensions under en längre tid som blivit del av OGL i de fallen. Vulkan implementeras i drivrutinen, i user-mode när vi talar API:t, den implementationen är viktig likväl hur spelutvecklaren/motorn implementerar det hela. Både drivrutiner och spel har utvecklats en hel del sedan 1.0. Drivrutinens implementation är viktig fortfarande. Det går inte att hoppa över den. Startläget är bättre än på OGL, men implementationen är viktig.

Visst, men det har inte så mycket att göra med att man ser en prestandaboost när man går från OpenGL till Vulkan i Doom.

Boosten kommer främst från att OpenGL stödet suger i dagens konsument GPUer. Vilket inte är så konstigt givet att noll AAA-titlar lanserats med OpenGL som huvud API de senaste ~10 åren. Jämför man DX11->Vulkan ser man i princip samma sak som för DX11->Vulkan.

Gissar att många missat att DX11 faktiskt har rätt OK stöd för att använda fler CPU-kärnor. Gör man lite kurvanpassning av Amdahls lag till t.ex. RoTR i 1280x720 med GTX 1080 så ligger "p" värdet (hur stor andel av tiden som spenderas i den del som kan dra nytta av flera kärnor) runt 0,8.

Det är bättre i DX12, där närmare man sig 0,9 (1,0 är perfekt skalning och 0,0 är helt seriellt).

Grejen är att med "vettiga" grafikinställningar så är GPU flaskhals så kvittar om man slänger på mer CPU-kraft.

Är fullt medveten om var OpenGL kommer ifrån, men ser överhuvudtaget inte relevansen i det när mitt påstående var: Doom får en boost av Vulkan främst för att OpenGL suger, inte för att Vulkan på något sätt är tekniskt bättre än DX12 (på en tekniskt nivå är DX12 och Vulkan extremt lika).

För den diskussionen spelar det ingen roll varför prestanda i OpenGL suger. De flesta som läser SweClockers bryr sig nog främst om spel och om OpenGL har bagage som gör det sämre där är det bara, well, sämre än DX.

Men OpenGL har större problem är gammalt bagage. Det riktigt stora problemet är att OpenGL bygger på att man modifierar en global tillståndsmaskin (OO-programmerare kan set det som att varje funktiontionsanrop får en dold this/self pekare som allt alltid är samma).

Detta är vad Apples dokumentation säger om OpenGL ES (och samma sak gäller OpenGL)

"Each thread in iOS has a single current OpenGL ES rendering context. Every time your app calls an OpenGL ES function, OpenGL ES implicitly looks up the context associated with the current thread and modifies the state or objects associated with that context.

OpenGL ES is not reentrant. If you modify the same context from multiple threads simultaneously, the results are unpredictable. Your app might crash or it might render improperly. If for some reason you decide to set more than one thread to target the same context, then you must synchronize threads by placing a mutex around all OpenGL ES calls to the context. OpenGL ES commands that block—such as glFinish—do not synchronize threads."

Har man bara en skärm och en GPU finns i praktiken ingen poäng att ha fler än ett "rendering context". Det betyder att alla trådar delar ett och samma "rendering context" i ett API som "is not reentrant". D.v.s. i praktiken måste allt som gör grafikanrop köras på en och samma tråd. Det är DX9 nivå.

Faktum är att DX11 och DX12 har i grunden exakt samma design för att använda flera CPU-kärnor, men DX12 (och även Vulkan) är designade så att än mer av grafikspecifikt jobb som inte direkt behöver prata med GPU kan köras helt oberoende på flera trådar.

DX11, DX12 och Vulkan måste alla fortfarande serialisera de flesta anrop som görs till strukturer synliga från fler än en tråd (Vulkan), men det är ändå ett rejält lyft över hur DX9/OpenGL fungerar.

Efter att läst på lite mer om just Vulkan-stöd i Unity så är min gissning: de 30-60 % prestandaboost man pratar om är med väldigt stor sannolikhet tagna från Android.

Tänk billiga lurar med quad Cortex A53, de har en enkeltrådprestanda per klockcykel någonstans mellan ursprungliga Atom (Bonnell) och Atom Silvermont. Cortex A53 är precis som Bonnell en in-order dual-issue design, dock bättre designad än Bonnell så presterar bättre per cykel.

OpenGL/OpenGL ES är på DX9 nivå vad det gäller multitrådstöd, d.v.s. i praktiken är det ett API som bara kan användas från en tråd på ett vettigt sätt.