Unreal Engine 4.21 gebruikt standaard Vulkan op Linux

Versie 4.21 van de Unreal Engine gebruikt op Linux standaard de Vulkan-api voor renderingwerk en gebruikt OpenGL alleen nog als een fallback. Dit moet leiden tot verbeterde prestaties op het besturingssysteem.

Unreal-ontwikkelaar Epic Games maakt het nieuws bekend in een uitgebreide update-post. Standaard gebruikt de engine de Vulkan-api zonder enige melding aan de gebruiker. Gebruikers kunnen binnen projectinstellingen of met een command line switch het gebruik van Vulkan of OpenGL uitschakelen. Volgens Epic moet Vulkan ook tot twintig procent sneller draaien dan OpenGL ES 3.1 op Android met deze update. Dat zou te danken zijn aan optimalisaties bedoeld voor Fortnite, die de studio samen met Samsung heeft ontwikkeld.

Vulkan wordt ontwikkeld door de Khronos Group, een samenwerking tussen vele techbedrijven. Ondersteuning voor de api, die in 2016 het levenslicht zag, zit in verschillende populaire engines, waaronder id Tech, CryEngine, Unity en de Source Engine. De lijst met games die Vulkan ondersteunen, is niet lang, maar bevat wel wat prominente titels.

Verder maakt Epic Games bekend dat de Unreal Engine nu volledige ondersteuning heeft voor mixed reality headsets, zoals die van HP en Samsung. Mixed Reality is het nieuwe vr-platform van Microsoft. Tweakers heeft daarover in december van 2017 een review geschreven. Gebruikers moeten hiervoor wel de April 2018 Update van Windows 10 hebben geïnstalleerd.

De Amerikaanse ontwikkelaar brengt ook voor het eerst Pixel Streaming uit. Dat is de mogelijkheid om een packaged Unreal Engine-applicatie te draaien op een computer in de cloud, terwijl de viewport gestreamed kan worden naar een client via een webbrowser. Voordeel hiervan is dat de client niets hoeft te downloaden of installeren. Ondersteuning om invoer van muis, keyboard en touchscreen naar de host-pc te sturen is er ook. De functie is nog wel in early access.

Reacties (32)

[923789]

Los van de techniek, maar geeft Vulkan nu mooiere plaatjes op het beeld of is het alleen voor achter de schermen echt interessant ??

[dmantione]

Het is de bedoeling van Khronos om OpenGL volledig bij de tijd te houden en dat in beginsel alles ook mogelijk is met OpenGL. Bovendien is er kruisbestuiving: Bijvoorbeeld één van de onderscheidende kenmerken van Vulkan was de ondersteuning van SPIR-V als tussenrepresentatie voor shaders, zodat een flink deel van de compilerlogica voor GLSL in OpenGL niet meer in de driver hoeft te zitten (en ook ondersteuning in spelengines voor shaders in andere talen in Vulkan eenvoudiger is). Welnu, SPIR-V is in OpenGL 4.6 toegevoegd, zodat je deze voordelen ook met OpenGL kunt krijgen.

Als OpenGL bijgehouden wordt, dan is er geen reden waarom er verschil in plaatjes zou ontstaan. Uiteindelijk ligt het evenwel aan de makers van de spelengine: Alles is bij beide API's mogelijk, maar wil je de moeite doen om alles bij beide API's te implementeren?

[Gamebuster]

Vulkan schijnt betere low-level access te geven en features als multithreaded rendering, waardoor rendering van scenes niet meer vanaf 1 CPU core hoeft te gebeuren en vele calls minder van de CPU vragen. Als bonus is Vulkan cross-platform*, iets dat voorheen alleen voor OpenGL was.

*Vulkan heeft geen officiele support van Apple, maar er zijn wel "mappings" beschikbaar van Vulkan naar Metal: Apple's eigen "OpenGL alternatief".

Het zou er dus voor kunnen zorgen dat de CPU minder belast wordt en de GPU efficiënter zijn werk kan doen om het zelfde plaatje te renderen.

Bron: Hearsay. Ik heb OpenGL wel eens aangeraakt voor de fun maar ik ben verre van een expert

[Reactie gewijzigd door Gamebuster op 27 juli 2024 22:57]

[Carharttguy]

Ik ken er niet zoveel van, maar Vulkan, OpenGL e.d. werken toch op de GPU, toch niet op de CPU (Ok, eventueel als fallback misschien wel?). Dus multithreading lijkt mij van beperkt nut? Of misschien in SLI setups?

Vulkan is eigenlijk gewoon de opvolgen van OpenGL, en dat lijkt me niet slecht. De eerste versie van OpenGL kwam ongeveer 26 jaar (!) geleden uit, voor software is dat wel een heel lange tijd.

[Gamebuster]

OpenGL e.d. werken toch op de GPU, toch niet op de CPU

Dat is correct, alleen het aansturen van de GPU wordt gedaan door de CPU. Je hebt allerlei data die je naar de GPU moet sturen en je moet de GPU opdrachten geven. In het begin ging dat als volgt:

CPU: "Yo bitch, begin met het tekenen van driehoeken."
GPU: Sure thing, boss!
CPU: *ahum* Begin met punt 1, 0, 0, kleur 1.0f, 1.0f, 1.0f, normal 1.0f, 1.0f, 1.0f
GPU: Sure, en nu?
CPU: Punt 1, 1, 0, kleur 1.0f, 1.0f, 1.0f, normal 1.0f, 1.0f, 1.0f
GPU: Got it. Next?
CPU: Wacht ff hoor... ff rekenen... ja hier! Punt 0, 1, 0, kleur 1.0f, 1.0f, 1.0f, normal 1.0f, 1.0f, 1.0f
(en dat een miljoen keer)

De waardes van die punten, kleuren en "normals" waren gebruikelijk deels vooraf berekend en deels realtime gemanipuleerd. Dit is allemaal gruwelijk inefficient, want de CPU & GPU zitten continue op elkaar te wachten.

Later kon je alle punten, kleuren en "normals" vooraf berekenen. Dit kan je zelfs in een andere of meerdere threads doen! Super cool! Alleen uiteindelijk heb je een blok geheugen dat je dan alsnog naar de GPU moet kopieren, en dit moet alsnog door 1 CPU thread gedaan worden.

Weer later kon je ook berekeningen uitvoeren op de GPU (zodat de CPU niet on-the-fly allerlei berekeningen hoeft te doen) & heb je de mogelijkheid om bijv. alleen manipulaties in de data heen-en-weer te sturen. Al deze zaken zijn nog steeds single-threaded! Als je 2 "calls" doet tegelijk, wordt je beeld 1 grote soep of krijg je gewoon een crash. Wanneer je dus 1000 bewegende elementen naar zo'n GPU moet sturen, moet je dus per frame 1000x een blok data heen en weer schuiven, en dit moet allemaal vanaf 1 core. Denk bijv. aan een game als Cities Skylines: Ieder autootje, ieder persoon, ieder huisje, ieder stukje weg, etc. Nu kan je al die zaken individueel updaten in de simulatie, verspreid over meerdere cores; maar het uiteindelijke renderen: 1 core. Dit is waarom single-core performance belangrijk is bij vele games.

Zelfs al zou je alles berekenen op meerdere cores en dan vanuit 1 core de data heen-en-weer sturen, moet je alsnog wachten op het synchroniseren en het "vrijgeven" van de data tussen de meerdere threads.

Nu heb je recent, in laatste DirectX & OpenGL versies, en dus ook in Vulkan, Apple's Metal en AMD's Mantle (ja, kennen we die nog?), de mogelijkheid om vanuit meerdere threads direct data erheen te sturen. Hierbij hoef je dus niet continue te synchroniseren/wachten bij wisselingen van threads. Het versturen van data vanuit de CPU is hierbij efficiënter en kan makkelijker verspreid worden over meerdere cores.

Tot slot zijn er veel meer "low-level" apis mogelijk. Hierbij heb je veel meer mogelijkheden om nog meer berekeningen direct op de GPU uit te voeren zodat de CPU vooraf minder hoeft voor te bereiden & minder data hoeft te sturen. Dit was al grotendeels mogelijk met "shaders", maar met "direct-compute" en low-level access zijn je mogelijkheden hier een stuk breder. Zo breed, dat je er misschien wel massaal elektronische muntjes mee kan verzamelen. (maar niet doorvertellen, want straks gaat iedereen massaal GPUs kopen en weer dumpen als de prijs zakt)

Nogmaals disclaimer: Ik ben geen expert, mijn informatie kan onvolledig of onjuist zijn.

Vulkan is eigenlijk gewoon de opvolgen van OpenGL, en dat lijkt me niet slecht. De eerste versie van OpenGL kwam ongeveer 26 jaar (!) geleden uit, voor software is dat wel een heel lange tijd.

Ik hoop gewoon dat er niet een of andere grote mobieltjes verkoper koppig gaat zijn en gewoon een eigen grafische API op de markt gaat pushen ipv open standaarden te ondersteunen...

[Reactie gewijzigd door Gamebuster op 27 juli 2024 22:57]

[Gropah]

Nog een interessant feitje, AMD omschrijft vulkan als een afstammeling van Mantle, omdat het grotendeels een open source (her)implementatie van vulkan is. Waarschijnlijk is dit gedaan omdat NVIDIA anders niet aan de standaard wou. Zie ook dit artikel voor iets meer achtergrond.

[cdwave]

De GPU heeft direct toegang tot het geheugen, en de eerste stap naar een efficientere interface was om met grotere commando blokken te werken, en die in een wachtrij te plaatsen. Dus de interface wordt dan iets van "ik heb daar een paar honderd punten voor je klaarstaan". De bandbreedte tussen GPU en dat geheugen (meestal de cache...) was nog steeds een grote beperking, en door rekenen in de GPU toe te staan kun je zo'n blok dat bijvoorbeeld een autootje beschrijft een aantal keer recyclen voor alle autootjes in beeld, en hoef je per autootje nog maar een enkele matrix te geven (en die geef je ook weer in zo'n blok...). Je ziet de bottleneck nu ontstaan, een soort "boom" van instructie en data blokken, en dan komt multithreading te hulp om de losse takken van de boom over CPUs te verdelen.

[robvanwijk]

De eerste versie van OpenGL kwam ongeveer 26 jaar (!) geleden uit, voor software is dat wel een heel lange tijd.

Wat maakt het uit wanneer de eerste versie uitkwam...!? Zoek voor de gein eens op wanneer de eerste versies van HTML, Windows, TCP, MS Office, PHP, Linux, ... uitkwamen. Moeten we dat dan ook allemaal vervangen door from-scratch alternatieven? Het zou een stuk relevanter zijn om te kijken wanneer de huidige versie van OpenGL is uitgekomen. En zelfs dan, hoe lang geleden dat is zegt niet heel veel over de vraag of het vandaag de dag nog voldoet. Als een standaard al jarenlang ongewijzigd is (en nog steeds op grote schaal gebruikt wordt) dan zou dat ook een teken kunnen zijn dat het prima werkt en er simpelweg geen aanpassingen nodig zijn.

[Carharttguy]

Tuurlijk is dat relevant. Als je verder blijft werken op een basis van 26 jaar geleden zitten er sowieso zaken in die niet meer relevant zijn of gewoon hopeloos verouderd.
Om even te overlopen:

-HTML is een RFC, een afspraak, de implementatie ervan is waarschijnlijk al zo'n 100 keer herschreven.
-Windows is ook al herschreven, er zit geen Windows 1 code in Windows 10
-TCP is idem als HTML
-MS Office, idem Windows
-PHP en Linux kan ik nog enigzins volgen. Hoewel die alletwee ook met massa's legacy code zitten.

Als een standaard al jarenlang ongewijzigd is (en nog steeds op grote schaal gebruikt wordt) dan zou dat ook een teken kunnen zijn dat het prima werkt en er simpelweg geen aanpassingen nodig zijn.

Klopt, maar OpenGL is toch geen standaard? Dat is toch gewoon een implementatie in de vorm van een API?

[robvanwijk]

HTML is een RFC, een afspraak, de implementatie ervan is waarschijnlijk al zo'n 100 keer herschreven.

Dat betekent alleen dat er geen oude code in de implementatie zit, maar het ontwerp van de taal zelf kan wel degelijk keuzes bevatten die indertijd logisch waren, maar waar we inmiddels weten dat een andere aanpak beter geweest zou zijn.

Windows is ook al herschreven, er zit geen Windows 1 code in Windows 10

Ik weet niet of dat waar is. Het "langste" voorbeeld dat ik persoonlijk toevallig ken is dat er stukken code van (tenminste) Windows 3 grotendeels ongewijzigd tot (tenminste) Windows XP zijn blijven zitten.

Maar hoe dan ook, dit waren gewoon een aantal voorbeelden. Het punt was voornamelijk dat informatica voor een heel groot deel bestaat uit het steeds verder verbeteren van bestaande oplossingen. Ja okee, af en toe beginnen we ergens een keer helemaal van voren af aan, maar dat is relatief zeldzaam. Een bepaalde oplossing afdoen als "de eerste versie is 26 jaar oud" en impliceren dat het daarom automatisch tijd is om een volledig nieuwe oplossing te bedenken, dat vind ik onzinnig.

Klopt, maar OpenGL is toch geen standaard? Dat is toch gewoon een implementatie in de vorm van een API?

Ik weet niet wat je hier precies bedoelt. De OpenGL API is juist een standaard. Doordat het een standaard is kunnen volkomen verschillende implementaties toch compatible met elkaar zijn.

[rjmno1]

Opengl is al tijden DE betere renderer dan andere concurentie draaiende op unreal engine.
Ik draai al jaren opengl op ut99 en het is de beste renderer wat je maar kent bedenken.Nu met die nieuwere unreal engine hebben ze dat door getrokken van vroeger en dus ook beschikbaar voor opengl.

[EasyBoarder]

Niet mooier, maar vloeiender.
Door deze nieuwe API te gebruiken i.p.v. het verouderde OpenGL, zullen prestaties beter zijn (a.k.a. vloeiender draaien).

[2green]

Doordat het mogelijk is vloeiender jetzl3fe beeld weer te geven, is het uiteraard ook mogelijk iets mooiers weer te geven.

Dit simpelweg omdat er met vulkan processortijd bespaard word (zowel cpu als gpu) als het goed toegepast wordt.

Probleem is wel dat de huidige generatie game ontwikkelaars relatief weinig kennis hebben van low level programming methoden. Wat juist de kracht is.

[EasyBoarder]

@2green en @Mic2000
Jullie hebben helemaal gelijk. Extra performance geeft ruimte om mooiere beelden te maken.
Ik doelde er echter op dat beelden niet automatisch mooier worden. Een direct resultaat is dat het programma (of game in dat geval) beter gaat draaien. dat een slimme developer deze ruimte gebruikt om de game mooier te maken is een ander geval, maar zeker waar

[2green]

Klopt beelden worden inderdaad niet automatisch mooier. Daar moeten die ontwikkelaars zelf wat voor doen. Vermoede al dat je zoiets bedoelde, maar dacht ik zeg het toch .

[Mic2000]

Ook mooier, want als ontwikkelaar kan de extra performance gebruikt worden voor meer fps of meer grafisch detail te renderen in dezelfde tijd.

Dus of vloeiender of mooier, of een beetje van beide, het is maar hoe de extra performance wordt benut.

[Reactie gewijzigd door Mic2000 op 27 juli 2024 22:57]

[pieterdebie]

Iemand die als aanvulling op @923789 zijn vraag kan bevestigen of het verschil tussen API, los van eventuele features, 1 op 1 hetzelfde beeld geven?

Heeft de ene api bijvoorbeeld betere reflecties dan de andere, of scherpere textures?

[CH4OS]

Of een texture scherper is, is niet aan de engine. Dat doet vooral de resolutie van het texture.

[pieterdebie]

Akkoord, vooral. Wat ik mij dan afvraag is of er bv verschil zit in de texture filtering. Het was dan ook maar een voorbeeld, ik bedoel dus vooral: zelfde instellingen, andere api.

[Gropah]

Vulkan zelf maakt niet per se mooiere plaatjes. Het zorgt over het algemeen wel voor efficiëntere werking van GPU doordat hij directer aan te spreken is, waardoor het mogelijk is om danwel hogere FPS bij zelfde settings te hebben, danwel mooiere settings met een zelfde FPS.

[Diamondo25]

Om mooie plaatjes te maken heb je best wel wat processorkracht nodig. Als je nu voor OpenGL 1.5x zoveel opdrachten moet doen om hetzelfde beeld te tekenen als in Vulcan, scheelt dat nog best wel wat processorkracht, waardoor het voor de gebruiker dus een voordeel oplevert.

[Azbest]

Nee, en nee. De eindgebruiker ziet betere performance: https://www.gamersnexus.n...benchmark-rx-480-gtx-1080

Dus ook voor de gebruiker interessant.

[Flake]

Vulkan biedt low level hardware access en in tegenstelling tot OpenGL wordt er geen enkele vorm van validatie toegepast op de instructies. De theorie erachter is dat je daarmee een cross platform low overhead high performance graphics API hebt en dat je niet meer afhankelijk bent van de bereidwilligheid van de driver. Keerzijde daarvan, with great power comes great responsibility, zeker als er geen validatie op de instructies plaats vindt.

Ten opzichte van OpenGL is Vulkan absoluut bloedsnel. OpenGL valideert instructies wél, wat resulteert in driver overhead en de ontwikkelaar mag goed zn best doen om die te drukken. Daarentegen is het een fluitje van een cent om met OpenGL een driehoek te tekenen en mag je daar bij Vulkan nog de nodige randvoorwaarden (zoals memory management) verzorgen.

Linux had geen high performance graphics API - DirectX is Windows only en OpenGL kan niet mee (en is ook nooit bedoeld) op dat niveau.

[Verwijderd]

Voor de geïnteresseerde, een eenvoudig met Python3 te draaien voorbeeld van een Diekhoek met Vulkan (d.m.v een Python Vulkan wrapper)
En een code voorbeeld/verschil OpenGL (Python2)

[Reactie gewijzigd door Verwijderd op 27 juli 2024 22:57]

[Azbest]

Ik ben benieuwd naar de volgende benchmark van Phoronix, zou het gat in prestaties met Windows nu gedicht zijn?

[parryfiend]

In theorie zou Vulkan inderdaad het gat in prestaties met DirectX11/12 moeten vullen. Goed nieuws voor elk OS dat niet windows is!

[Azbest]

Je hebt gelijk, ik hoop alleen dat de drivers of iets anders in dat geval geen dramatische dingen aan het licht brengt. Nvidia's eigen driver vind ik goed werken, en gekeken naar de ruwe rekenprestaties zou Linux niet achter hoeven te blijven:
https://www.phoronix.com/scan.php?page=article&item=pascal-win10-linux&num=11

[parryfiend]

Nice, dat ziet er goed uit!
Hopelijk kan Vulkan de hegemonie van DirectX als de dominante api over de gaming industrie doorbreken.

[pieterdebie]

Dus wel met DirectX, maar niet zozeer met Windows, aangezien Vulkan op windows ook vrolijk draait.

Dit is niets negatief natuurlijk

[2green]

Dat gat is het resultaat van 1) de achterstand in OpenGL wat vulkan dus verhelpt 2)de performance van OpenGL wat ook verbeterd is met vulkan 3) minder geoptimaliseerde drivers, wat ondanks de praatjes van AMD en Nvidia zeker nog niet gelijkwaardig is, maar wel verbeterd. Helaas met low level window code wrappers, dus kan met penalty zijn 4) games die niet zo ver geoptimaliseerd zijn voor Linux/vulkan als windows/DX.

Het gaat de goede kant op, maar duurt zeker nog 5 a 10 jaar voordat dit bijgetrokken is.

Er is nog relatief weinig commerciële interesses in linux games, dus minder focus daarop.

[Reactie gewijzigd door 2green op 27 juli 2024 22:57]

[Pinkys Brain]

Leveren ze hun ontwikkelomgeving voor Windows nou al eens standaard met Vulkan of moet je nog steeds zelf het zaakje hercompileren?

[maali]

nog niet echt in Vulkan verdiept, maar ik zag wel dat voor een roterende kubus je al gauw iets van ~150 regels code mag typen, dus, tja, low-level is leuk, maar maar ja, drawcalls minder afhankelijk van de CPU maken zal een slok op een borrel schelen