Valve wil multithreading in Linux-kernel optimaliseren om gamen beter te maken

Valve wil de kernel van Linux aanpassen om games beter te kunnen ondersteunen. Het platform stelt manieren voor om gaming op het platform te verbeteren, onder andere door multithreading beter te ondersteunen.

Het voorstel valt samen met de release van Proton 4.11 door Steam, die eerder deze week plaatsvond. Proton 4.11 is gebaseerd op WINE 4.11 en heeft, naast een hoop bugfixes en ondersteuning voor Direct3D.9, functionaliteit waarmee de cpu-load bij multithreaded games kan worden verlaagd. Daarvoor moet echter wel de Linux-kernel worden aangepast. Dat heeft Valve inmiddels voorgesteld. Het voorstel van Valve om de kernel aan te passen zou leiden tot meer dan tien procent verlaging van de cpu-load, zegt Valve. Dat testte daarvoor Tomb Raider op een high-end machine, maar volgens het bedrijf kan ook bij goedkopere systemen sprake zijn van een flinke loadverlaging.

In de nieuwe versie van Proton zit ook een experimentele nieuwe functie waarmee esync kan worden vervangen. esync was altijd de manier om multithreaded games te spelen op Linux, maar Valve wil de kernel aanpassen om multithreading in het algemeen sneller te maken in het besturingssysteem. Dat moet gebeuren door fast user-space locking-functionality of futex() uit te breiden door meer kernfunctionaliteit beschikbaar te stellen. Ook stelt Valve voor aanpassingen te doen aan glibc en lbpthread.

Er zijn al twee experimentele packages van fsync beschikbaar voor Arch en Ubuntu, die door gebruikers als bèta kunnen worden geprobeerd. Daarnaast zijn er proof-of-concept-patches uit voor glibc, die door gebruikers kunnen worden getest.

Reacties (115)

[DancingMonkey]

De eerste comments op de mailing list zijn niet echt postief. Alle reacties geven aan dat er of fouten in de patch zitten of dingen niet kloppen of dat de orignele submitter dacht dat dingen anders werken dan dat ze doen. Hoe gefundeerd deze beweringen zijn laat ik in het midden maar dat zegt wel dat deze patch met een korrel zout genomen mag worden.

[dmantione]

Ik lees geen afwijzing van het idee om een operatie toe te voegen om op meerdere Futexen te wachten. Wel wordt er gereageerd op de implementatie en dat lijken me terechte commentaren. Conclusie: Valve heeft nog huiswerk, maar in basis lijkt Valve goede grond te hebben om dit aan de kernel te willen toe te voegen.

[fo0]

Precies, dit zijn gewoon normale code-review comments.

[Verwijderd]

Daarnaast moet er naar een 10 worden gewerkt, indien je voldoende scoort, heb je een eerste versie, maak maar eens een eind project, dat gaat ook zo, waarom zou dat in de business anders zijn. Je haalt niet in 1x een 10, daarnaast is software schrijven altijd goed om te reviewen. waarom denk je dat linus z'n groep hamert op code kwaliteit. door een benedengrens te hanteren krijg je veel minder kernel panics.

[hackerhater]

Ik heb iets van laat maar komen mits het voldoet aan de code-kwaliteit standaard van de Linux-kernel

[RoestVrijStaal]

Ik vind het eerder jammer dat er tergelijkertijd geen PR met nieuwe of verbeterde testcases op https://github.com/linux-test-project/ltp is gepost voor de changes

Dat gemis verklapt ook een beetje hoe de nieuwe implementatie van futex geschreven is vòòrdat Tomb Raider aangezwengeld werd.

Edit: interpunctie

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 02:56]

[supersnathan94]

Maar dat is toch inherent aan een code-review. Als er geen commentaar is, is het niet doorgenomen. Men heeft altijd oversights die daarin mogelijk worden rechtgezet. Mocht valve met een algemene verbetering komen (zodat alle multithreading loads er wat aan hebben), dan is het zeker de moeite waard.

[Vlad86]

Klinkt als ze willen de windows counterpart van WaitForMultipleObjects introduceren, alleen zonder de polling gedrag die additionele CPU time kost om te checken.

Wel smerig met die gotos in de code...

[EddoH]

Goto wordt veelvuldig gebruikt in de Linux kernel, en met redenen. Goto's zijn slecht in heel veel gevallen, maar zeker niet in alle (in C). Dat is gewoon napraterij, zoals met veel ongenuanceerde generaliserende 'vuistregels' in software development.

[Sandor_Clegane]

Gotos zijn prima, mits je weet wat je doet. Dat is de crux.

[Vlad86]

Mwa, voor mij is het een teken van een slecht ontwerp. je wilt een duidelijke flow van een functie kunnen zien en gotos helpen daar echt niet aan mee. Mijn moto tijdens programmeren is dat de code die ik schrijf is niet voor mij maar voor iemand anders is bedoeld, dus leesbaarheid staat voorop.

[Reactie gewijzigd door Vlad86 op 23 juli 2024 02:56]

[CrimsonRider]

Obligate link naar Linus, en anderen, hun visie op goto's in een discussie: https://koblents.com/Ches...oto-in-Linux-Kernel-Code/

[Vlad86]

thx

[CrimsonRider]

Ik ben, toen ik nog developer was 24 jaar geleden, ook opgevoed met "goto's are evil", maar eigenlijk nooit goed nagedacht waarom ze evil zouden zijn.

Ik doe nu Python development als hobby, waar ik ze niet zie. En C voor de Attiny waar ze soms handig kunnen zijn. Tis een gereedschap en net als alle tools is het de gebruiker die bepaalt of het gebruik ervan goed of niet is.

"Poor programmers make poor code" vond ik nog de beste uitleg daar.

[Vlad86]

Eens, uiteindelijk is de maker verantwoordelijk. Heb zelf niet zo veel jaren achter de rug als jij, snij dat maar door de midden. Alleen heb voldoende gezien waarom dit vaak geen goed idee is om te gebruiken (vaak door slechte regression coverage en geen juiste state afhandeling). Maar ik ontken niet dat er use-cases zijn waar een goto juist een nette oplossing kan zijn (zo als nested loops).

Code leeft en veranderd, mensen komen en gaan. Uiteindelijk is het altijd iemand anders die de rotzooi moet opruimen, dus als mede developer is het mijn taak om het zo aangenaam mogelijk te kunnen maken voor de andere.

[0timsmit0]

Toen was programmeren nog een stuk minder functie-gebaseerd en stond alles in één grote main functie. Goto’s waren een logisch gevolg van het gebrek om stukken code op verzoek uit te voeren. Natuurlijk maakt dat goto’s niet slecht, maar er zijn nu vaak betere alternatieven.

[CrimsonRider]

Sommige van mjjn eerste stukken code ooit waren in Basic. GW-BASIC, GOSUB en GOTO met line numbers. Hoewel ik echt gruwel van Java moet ik toch toegeven dat we met moderne talen als Python en R een stuk verder zijn gekomen.

[SuperDre]

tja, goto, code zit er eigenlijk vol mee, maar dan ondere andere namen zoals events etc. (want een throw is ook gewoon een vorm van goto en zelfs een 'return' midden in de code ook).

[fastedje]

Wellicht kan je met gotos net een beetje meer performance uit de kernel persen, echter in het algemeen maakt die ene instructie in een applicatie maar heel weinig uit. Leesbaarheid, onderhoudbaarheid en minder fouten wegen over het algemeen zwaarder mee.

[RobIII]

Je schrijft dan waarschijnlijk ook geen kernel code Appels en peren enzo. Totaal verschillende doelen en belangen.

[RobIII]

Je punt?

Ik reageerde gewoon op je reactie; niks meer en niks minder. Ik heb niet op voorhand al je reacties gelezen.

[freaq]

Simpel, een hamer is een prima tool maar niet om mee te schroeven.

de regels van wat goed is wat jij doet gaan niet perse op in andere gevallen.

[Reactie gewijzigd door freaq op 23 juli 2024 02:56]

[Vlad86]

fak freek, jij ook hier... wat ik zo grappig vind is dat mensen zo inhakken op goto en niet over de content van de bericht.. de futex zelf.

ps. goedemorgen, tijd bij je Siggraph booth te staan? 😜

[freaq]

Ja ik ook hier hoor
En ja net klaar met siggraph, goed gaar man... back to work nu hahaha

[Lennie]

Schroeven in hout slaan met een hamer is heel soms wel nodig.:-)

[freaq]

Jup en soms hebben we nested for loops nodig...
Betekent niet dat het ideaal
Is

Maarja soms is het idd de enige manier.
En bouwen met baksteen is in nederland goed, maar in san francisco verboden wegenda aardbevingen.

Het hangt allemaal gewoon af van de onstandigheden.

[Lennie]

bakstenen verboden ? echt ? ohh, daar had ik nog nooiit bij stilgestaan. Interessant feitje !

[84hannes]

Gotos zijn prima, mits je weet wat je doet. Dat is de crux.

C is prima, mits je weet wat je doet. En guess what: mensen maken fouten. Dat heeft echter de linuxkernelontwikkelaars er nooit toe gebracht de kernel in een taal met intelligenter geheugenbeheer te schrijven, dus wellicht zijn de kernelontwikkelaars ook geniaal genoeg om geen fouten met goto's te maken Het zijn wellicht Valveontwikkelaars die de goto's introduceren, maar ook anderen zullen het moeten onderhouden.

[Reactie gewijzigd door 84hannes op 23 juli 2024 02:56]

[cdwave]

Geheugenbeheer in de kernel is al heel lang geen "handwerk" meer. Met de introductie van "devm" functies voor van alles en nogwat is het beheren van geheugen (en interrupts, klokken, voedingen, etc) een no-op geworden.

Ook in C kun je object-oriented programmeren, gebruik maken van managed resources, en alles wat de modernere talen ook kunnen, het kost alleen wat meer moeite.

De goto's die je in de kernel tegenkomt maken de code juist makkelijker te volgen. Binnen kernel ontwikkeling is leesbaarheid en onderhoudbaarheid juist een top prioriteit. Het star vasthouden aan roestige generalisaties zoals "goto considered harmful" werkt juist een goed gestructureerde ontwikkeling tegen. Het star vasthouden aan regels zoals de formattering - het gebruik van tabs en de plaatsing van accolades, en de voorkeur voor compacte leesbare code zijn juist hoekstenen waar het bouwwerk solide op kan rusten.

[84hannes]

Ik kende devm-functies helemaal niet, ik ga me er eens in verdiepen.

Ook in C kun je object-oriented programmeren, gebruik maken van managed resources, en alles wat de modernere talen ook kunnen, het kost alleen wat meer moeite.

offtopic:
Dit is natuurlijk de plaats noch de ruimte voor deze discussie, maar ik kan het niet laten. Als je wilt dat iets veilig is dan moet je zorgen dat het niet veel moeite kost om het veilig te doen. Neem de driepuntsgordel: dit was een revolutionaire uitvinding. Naar mijn bescheiden mening niet omdat hij zo veilig is: een vier- of vijfpuntsgordel is veel veiliger, daarom worden die volgens mij in de meer extreme autosport gebruikt. Het geniale aan de driepuntsgordel is dat het je vrijwel geen tijd en moeite kost om hem om (en af) te doen, waardoor gebruikers veel meer bereid zijn hem te gebruiken. In C++ is het veel makkelijker om geen geheugenfouten te maken (met bijvoorbeeld smart pointers), zelfs (vooral) zonder destructors te schrijven, en in C# en Rust is het zo goed als onmogelijk om geheugen te lekken of juist vergeten te initialiseren. Dat neemt echter niet weg dat discipline (ook in die talen) een belangrijk hulpmiddel is om veilige en onderhoudbare code mee te schrijven.

Ik heb het zelf nooit gezien, maar als jij zegt dat veilige en beter leesbare code met goto's te schrijven dan geloof ik je onmiddellijk. Maar mensen hebben graag iets om zich tegen af te zetten, dus als je zegt dat 'goto' een slecht concept is maak je veel mensen blij, dan kunnen ze heel makkelijk commentaar op anderen geven.

[Reactie gewijzigd door 84hannes op 23 juli 2024 02:56]

[ATS]

Ik kende devm-functies helemaal niet, ik ga me er eens in verdiepen.

[...]

offtopic:
Dit is natuurlijk de plaats noch de ruimte voor deze discussie, maar ik kan het niet laten. Als je wilt dat iets veilig is dan moet je zorgen dat het niet veel moeite kost om het veilig te doen.

Jammer eigenlijk... Dat je hier nooit iets leest over ontwikkelingen in software dev land, maar alles over de nieuwste telefoontjes, TV's en elke boer die Tesla laat.

[Vlad86]

Denk dat de raakvlak hier is veels te laag voor.

[ATS]

Ook niet iedereen heeft interesse in gaming, tv’s, mobieltjes of cpu benchmarks. Je kan overslaan wat je niet bevalt. Maar dit is een deel van de relevante technologie die Tweakers gewoon overslaat, en ik vind dat jammer.

[psychicist]

Ik begrijp wat je bedoelt en het grappige is dat het wel allemaal met softwareontwikkeling te maken heeft, maar het beestje zelf wordt zelden tot nooit bij de naam genoemd. Alsof de "powers that be" liever zien dat iedereen een consument is in plaats van echte informatica te promoten.

Of misschien is er onder de huidige Tweakersleden weinig tot geen interesse voor en willen de meesten gewoon consumeren. Ik vind berichtgeving over gaming (OpenGL, Vulkan), tv's (WebOS, Tizen), mobieltjes (Android, Plasma Mobile) en cpu benchmarks (x86, ARM, POWER) interessant, maar meer op de manier zoals Phoronix en Anandtech dat bijvoorbeeld doen.

Er zijn hier heus wel mensen die van softwareontwikkeling en kernelprogrammering afweten, maar er is buiten de wat rommelige forums niet echt een plaats om daar dieper op in te gaan en dat is inderdaad jammer.

[BCC]

Zijn er sites die hier wel op focussen?

[Lennie]

De consument is een groottere groep dus daar gaat de aandacht naar uit.

Ik zie dat veel mensen in IT aan de 'operations' (systeem beheer, etc.) kant nog steeds op tweakers.net kijken en dus zou tweakers.net een goede plek zijn voor introductie(s) in programmeren, etc.of alleen maar meer/betere scripting voor specifiek die mensen.

[Vlad86]

vind ik ook.

[Bjorn89]

Omdat Tweakers al lang Tweakers niet meer is

[GekkePrutser]

Ik kan me wel voorstellen dat je dit in de kernel doet vooral omdat het gaat om high-performance code. Daar wil je zo dicht mogelijk op de hardware zitten en zo weinig mogelijk overhead hebben. Goto is gewoon het equivalent van de JMP instructie van x86. Als je toch altijd terug gaat springen naar dezelfde plek dan heb je de hele overhead van return adres op de stack zetten niet nodig.

[DohnJoe]

dit heeft niks met return address en stack te maken, het gaat namelijk niet om wel/geen function call.

Het heeft meer met aanvullende condities te maken waar je op moet checken, extra vlaggetjes die je bij moet houden, wat met een goto mogelijk niet hoeft. Plus het leesbaar houden van de code.

[rbr320]

Dat is inderdaad exact het idee. En inderdaad, de code moet nog worden opgeschoond. De initiële patch was slechts bedoeld als proof of concept.

[Reactie gewijzigd door rbr320 op 23 juli 2024 02:56]

[dmantione]

De algemene richtlijn in de kernel wat betreft goto's is dat code die een foutsituatie afvangt en dan opschoont (zoals geheugen vrijgeven), onderin een routine plaatsvindt. Als binnen de routine een foutsituatie gedetecteerd wordt, dan wordt de programmeur geacht rechtstreeks met een goto naar die foutafhandeling te springen, in plaats van met booleans en if-statements te werken.

[Vlad86]

als het een richtlijn is, dan is het prima. Kom zelf niet van de kernel wereldje vandaan. Iig, als dit de richtlijn is, dan moet je daar gewoon aan houden. Anders wordt het echt een zooitje.

Alleen in de code van de proposal is het geen afhandeling van een fout scenario etc.

[Reactie gewijzigd door Vlad86 op 23 juli 2024 02:56]

[Hardwareseller]

Misschien moeten ze naast de optimalisaties (waar ik ook zeker voor ben!) eens kijken naar het volledig porten naar 64bit, aangezien 32bit niet echt toekomst bestendig meer is.

[Umbrah]

Steam zelf is opzich wel 64 bit hoor. Het zijn de games die dat niet zijn. En omdat er veel legacy is waar zelfs de developers niet meer van bestaan (maar de rechten/publisher wel...), en soms zelfs remasters zijn waar core libraries niet van aangepast zijn, is native 64 niet altijd een optie tenzij je naast Mac, Windows, Linux, ook 32- en 64-bit filters in de store wilt. Windows heeft WoW64 (een folder waar een soort van Wine-laag in staat om 32-bit software toch te laten draaien op Windows-64, wat normaal niet zou kunnen, ik weet; super overdreven te versimpeld), maar in dependency hell waar Wine ook nog eens een factor is, is dat wat lastiger... en dat kan je Valve niet aanrekenen...

Gelukkig wordt tegenwoordig een stuk minder platform vast gecode, maar meer agnostisch. Dat gaat gepaard met wat overhead, en vandaar dat er ook een soort oligopolie is ontstaan op engines, die zich juist daar in specialiseren. Een druk op de knop en POEF, het is ARM64... maar dat doet niks aan de legacy.

[The Zep Man]

maar in dependency hell waar Wine ook nog eens een factor is, is dat wat lastiger... en dat kan je Valve niet aanrekenen...

Uiteindelijk zal men daar wel omheen kunnen werken, bijvoorbeeld met wrapper code in Wine/Proton die een 32 bit call kan vertalen naar een 64 bit call naar de libraries die bij bij Steam/het OS meegeleverd worden. Dat zal echter nog wel even duren, want het is niet zo makkelijk.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 02:56]

[dmantione]

Steam heeft zowel 32- en 64-bit componenten, je kunt niet stellen dat Steam 64-bit is, noch dat het puur 32-bit is. Meest prominente 32-bit onderdeel van Steam is op dit moment de GUI. De mengeling zal blijven bestaan zolang mensen 32-bit spellen willen spelen. Wel zal in de loop der tijd het aantal 32-bit componenten afnemen.

[beerendlauwers]

Steam is perfect te porten naar 64-bit, het gaat om games die enkel 32-bit binaries hebben.

[ZpAz]

Dan kan je zo ongeveer het grootste gedeelte van je steam library weg flikkeren, net zoals nu het geval is op Mac OS Catalina.

[Lennie]

Bijna alle 32-bit software op Linux is omdat veel Windows software nog deels met 1 been in 32-bit land staat.

[Durandal]

Klinkt goed maar wat is de kans dat dit goedgekeurd wordt?

[PeterBezemer]

Als games er beter van gaan werken zal het vast voor nog meer toepassingen goed zijn denk ik?

[downtime]

Het is een optimalisatie voor games. Grote kans dat je er in andere scenario’s juist nadeel van hebt. Bijvoorbeeld wanneer je meerdere zware applicaties naast elkaar wilt draaien en niet alleen die ene game.

[rbr320]

Voor zover ik het begrijp is er geen nadeel voor andere toepassingen. Momenteel is er op Linux niet een makkelijke manier voor multithreaded applicaties om tegen de kernel te zeggen "ik heb een aantal threads lopen, laat me even weten als er 1 klaar is, het maakt me niet uit welke", iets wat binnen een game relatief veel voor komt. Dus is er een work around bedacht op basis van file descriptors, maar die oplossing heeft een aantal nadelen, onder andere dat er een limiet zit op het aantal files dat een gebruiker tegelijk open mag hebben. Bovendien is het trager dan iets in het geheugen. Toevallig maakt Wine veel gebruik van deze work around en voelen Windows games die via Wine op Linux draaien deze performance impact dus het meest, maar er zijn ongetwijfeld andere toepassingen die baat hebben bij deze patches.

Deze set patches is een uitbreiding op een bestaande kernel interface zodat dit allemaal een stukje sneller en eenvoudiger wordt. Vergelijkbare functionaliteit is wel aanwezig in de Windows NT kernel, zoals @Niosus en @Vlad86 al melden.

[Reactie gewijzigd door rbr320 op 23 juli 2024 02:56]

[cyberstalker]

Het lijkt me dat je voor het door jou genoemde scenario gewoon condition variables gebruikt. Die zijn daarvoor bedoeld. Is dit wat geoptimaliseerd is?

[rbr320]

Ik ben geen ontwikkelaar en al helemaal geen kernel hacker, dus ik heb geen idee wat je met "condition variables" bedoelt. Ik weet alleen dat @Vlad86 het in deze post correct heeft dat de Windows NT kernel een functie WaitForMultipleObjects heeft die de Linux kernel niet (meer) heeft. De ontwikkelaars van Valve willen deze introduceren. Zie de link in het artikel naar de Linux Kernel mailing lijst voor meer technische informatie.

[Reactie gewijzigd door rbr320 op 23 juli 2024 02:56]

[Vlad86]

condition variables hebben onderaan een os plementatie. deze implementatie is onderandere ook futex wat in de verbeter voorstel is aangegeven.

[Niosus]

Ik zie niet waarom dit zo zou moeten zijn. Games zijn geen magie. Als je een manier vindt om die rapper te doen draaien, zal er echt wel nog ander spul ook gebruik van kunnen maken.

Als ik het goed heb willen ze de functionaliteit van een paar kernel features uitbreiden. Als je die extra features niet gebruikt, zou dit in principe geen performance penalty hoeven te geven. Trouwens, als je gaat kijken naar de bron zie je dat een soortgelijke functionaliteit in Windows ook al aanwezig is.

Als hier verder geen negatieve neveneffecten aan vast hangen zie ik niet waarom dit niet approved zou worden.

[svennd]

Beetje PR voor Valve dit, de kernel is opensource, en als je komt zwaaien met 10% winst in een applicatie (want ook games zijn applicaties) dan komt het er wel in als je het op een correcte manier doet; Zoals zoveel bedrijven meewerken aan de kernel voor hun doelen, zoals ook o.a. Microsoft...

[chaogai]

wat is 10% winst? Bij mij is CPU maximum gebruik 10% in het laatste minuten grafiekje. Met een aantal jaren oude i5 en hyperthreading uitgeschakeld

[rbr320]

Start eens een grafisch intensieve game op waar ook nog wat AI in zit, bijvoorbeeld een moderne RTS, en kijk of je CPU gebruik dan nog steeds op 10% blijft hangen...

[chaogai]

leg eens uit: waar komt die 10% vandaan.
blijkbaar wordt nu 10% van de tijd verspild. Is de GPU 10% van de tijd niets aan het doen? Is de CPU 10% van de tijd niets aan het doen? Is de CPU 10% van de tijd kernel taken aan het doen? Als de CPU 10% niets doet, gaat de klok naar beneden?

[rboerdijk]

blijkbaar wordt nu 10% van de tijd verspild.

Ja... en door dingen slimmer te doen (vaak door minder code uit te voeren, of betere algoritmes te gebruiken) maar toch hetzelfde resultaat te hebben is het dus mogelijk 10% processortijd te winnen.

Als simpel voorbeeld, stel je moet 300 getallen onder de 1000 sorteren. Dat kun je doen door
- ze in de lucht te gooien, en als ze vallen kijken of ze op de goede volgorde liggen ( dat zal uiteindelijk wel een keer gebeuren - dit is uiteraard niet de slimste manier ^^ ).
- 1 te pakken, en de volgende op de juiste plek ertussen te leggen
- je zou ook een tabelletje kunnen maken en aankruisen welke getallen je gehad hebt ( als je ze allemaal gehad hebt zie je in de tabel de sortering ).
- je zou het samen kunnen doen met 3 vrienden (ieder soorteert z'n eigen 100 getallen) en op het einde lopen "mergen" jullie de tussen-sorteer resultaten.

In alle gevallen eindig je met hetzelfde resultaat, maar de ene manier zal handiger/sneller zijn dan de andere. Dit soort verbeteringen is dus waar die 10% vandaan komt.

Is de GPU 10% van de tijd niets aan het doen? Is de CPU 10% van de tijd niets aan het doen?

GPU: Misschien, hangt ervan af hoe veel "rekenwerk" de CPU naar de GPU kan sturen - en hoe snel de GPU is, en of de bottleneck bij de cpu of de gpu ligt.
CPU: Door optimalisaties is het mogelijk om 10% tijd te winnen...

Is de CPU 10% van de tijd kernel taken aan het doen?

Ik denk dat je bedoelt waar die 10% winst vandaan komt. Je zou naar de preciese verbeteringen moeten kijken, maar omdat het gaat om verbeteringen aan de kernel zal daar in ieder geval een deel van de winst (efficientere afhandeling) vandaan komen.

Als de CPU 10% niets doet, gaat de klok naar beneden?

Misschien... maar voor games is het waarschijnlijker dat de game naar een hogere framerate gaat (en die 10% winst dus daarvoor gebruikt wordt). Tenzij je vsync aanzet en je al op 60fps zit, in dat geval denk ik dat je cpu op dezelfde klok blijft (game = high performance), maar met een lage cpu-belasting.

Je wilt in principe voor een game niet dat de klok naar beneden gaat, omdat de cpu de 'rekenopdracht' zo snel mogelijk bij de gpu moet afleveren, zodat die asap kan beginnen. Misschien is de gpu net snel genoeg om het totaal op 16ms (=60fps) te houden, bij een lagere klok zou die dan niet meer snel genoeg zijn. Da's net niet wat je wil, voor een game.

[Reactie gewijzigd door rboerdijk op 23 juli 2024 02:56]

[kakanox]

Ik game niet, ontwikkel wel en monteer ook videos. Ondanks een pittige videokaart vliegt mijn CPU tijdens compilen kortstondig richting 100%, tijdens monteren blijft hij daar vaak zelfs vaak gewoon staan.
Zo is een nog niet zo heel oude i7 quadcore tijdens videobewerking dus de bottleneck terwijl de videokaart het meeste werk doet.

[chaogai]

ik kan de CPU ook volladen, met een of andere simulatie. Maar bij 'gewoon' gebruik lukt dat dus niet. En ik heb ook nog nooit gezien dat de totale bezetting zeg 85% was, als ik drie van de vier (hyperthreading) cores vol laat simuleren en verder niets doe.

Dus ik geloof niet dat 10% winst in willekeurige applicaties een verkoopargument is.

[EraYaN]

10% improvement is voor een stukje veelgebruikte kernel code best heel netjes, vooral omdat applicaties die code nog wel eens heel vaak willen aanroepen. En dit is het dus ook altijd waard, vooral met de aanpassing in het artikel, als men zo het aantal IO operations wat kan terug dringen door een native kernel functie aan te maken, das goeie winst. Bijvoorbeeld je zag dat WSL (eigenlijk een soort linux kernel emulatie laag) een heel stuk trager was voor alles wat met de kernel moest, dus dat maakt wel degelijk heel veel uit. git was bijvoorbeeld niet vooruit te branden, nog erger dan gewoon native op Windows.

Daarbij het gaat hier om tijd (dus zeg iets van 1 ms duurde duurt nu 0.9 ms), niet om het percentage wat je systeem monitor aangeeft voor het gebruik van de CPU of verschillen daar in, dat wil je eigenlijk altijd op 100% hebben als er een taak bezig is.

[chaogai]

10% verbeteren in een stukje kernel code is toch iets heel anders dan 10% performance overall.

[EraYaN]

Absoluut, maar omdat de kernel al in zo'n ver gevorderde staat van optimalisatie is, kun je niet meer de woeste published paper level 100x speedup halen. Er zit niet zo veel meer in, dus zou 10% nog steeds zeer netjes zijn.

[kakanox]

Jij hebt het over een simulatie, ik heb het over dagelijks gebruik (in het weekend niet, door de week meerdere malen).

We hebben met mijn werk een half jaar geleden duizenden euro's geïnvesteerd in een nieuwe server, puur om de tijd van het indrukken van "F5" (run incl. debug) tot het zien van de applicatie te reduceren van ergens tussen de 15 en 40 seconden (extreme gevallen daargelaten) naar 2 tot 5 seconden.

Verder is er nauwelijks merkbaar verschil; dit betrof een latency die alleen optrad bij de eerste start. Scheelt effectief dus misschien 10 of hooguit 20 minuten op een dag, per ontwikkelaar; maximaal 5%. Maar geloof me, die paar duizend euro gaan we dit jaar nog terug verdienen.

Wat ik hiermee wil zeggen is: Die 10% lijkt misschien niet veel, maar kan het verschil maken tussen (in ons geval) irritatie of geen irritatie. Of voor een gamer tussen net wél speelbaar en net níet speelbaar. Daarbij is het zoals het hier beschreven is "gratis" winst. Goed voor de stroomrekening.

Tenzij er duidelijke nadelen of risico's zijn: Altijd doen.

[Verwijderd]

Ik vraag me af of je nu expres dom doet, of daadwerkelijk gelooft dat je CPU altijd rond de 10% zit, vooral tijdens gaming...

[svennd]

10% winst is huge, zo huge zelfs dat niemand dit gelooft algemeen te zijn, zelfs de auteur niet van dit artikel. Mijn Raspberry Pi gebruikt ook nooit meer dan 10% CPU, want hij ligt stof te happen in de schuif.

[The Zep Man]

Best wel hoog, mits er goede patches/pull requests worden aangeboden op de juiste manier. Potentieel hebben de genoemde verbeteringen ook toepassingen buiten gaming om, dus laat maar komen.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 02:56]

[Umbrah]

De impact van multithreading support op gaming is, zelfs in oude(re) titels, enorm. World of Warcraft is een prachtig voorbeeld. Ik heb een CPU met relatief 'middelbare' performance/thread (Threadripper 1950x) en een overkill GPU (RTX2080). (en nee, ben niet zo'n iemand die dat soort hardware koopt voor patience, de hardware heeft andere redenen). Tot BFA was het eigenlijk een DX11 titel, waar in 7.3.5 (antorus patch) ineens DX12 bij kwam. Toen 8.0 uit kwam, werd dat wat volwassener, maar nog steeds niet met multi threading ondersteuning.

Ik liep dus rond met één core op 100%, wel wát restjes op andere cores, en ik ben gek op setting 10 (want wow is een mooie game), en zelfs dan een GPU die lekker op 30-40% load bleef hangen. Resultaat? 29FPS in Boralus (een van de grote steden).

Toen kwam 8.1 (en later nog eens in 8.1.5), en ineens was er multithreaded CPU ondersteuning op de render pipeline, een relatief eenvoudige wissel voor Blizzard. Gevolg? Veel meer cores die iets doen (nog stees wel een die op 100% zit), een GPU die nu maar liefsts op 60-65%% zit, en zowaar bijna 60FPS in boralus (ik vergeef het ze, 100Hz G-Sync scherm hier, Boralus is echter absurd druk, veel reflectie, veel NPC's die hun leventje leiden/rond lopen, en natuurlijk addons die bijdragen). Wat je ook ziet is dat Blizzard daardoor ook natuurlijk de raids weer wat mooier/complexer maakt visueel, maar ook guildies met oude hardware merken een verbetering!

Tsja, dit is een van die kernel changes waar ik dan ook wel achter kan staan. Ik denk dat een Linux Gaming Desktop (ondanks mijn voorkeur, ook voor develop werk, voor Windows, zelfs mét een threadripper, gief 3rd gen plx) alleen maar goed is om ook Microsoft scherp te houden, en laten we wel zijn: DX12 en Vulkan hebben óók baat hierbij (waar DX12 overigens heel erg op Vulkan lijkt)

[GertMenkel]

Onderschat niet de impact die conversie van single- naar multithreading heeft op codecomplexiteit. Op eens wordt code gevoelig voor race conditions, moeten grote delen van de engine herschreven worden en komen bestaande fouten in timingcode opeens naar voren omdat de verschillen in timing loops een stuk groter worden.

Voor bestaande code kan een "relatief eenvoudige wissel" makkelijk maanden werk zijn; helemaal als de code base al wat ouder is.

Ik ben blij dat multithreading vaker wordt gebruikt tegenwoordig, met moderne core counts heeft het een behoorlijke impact. Toch zal het nog wel even duren voordat je Threadripper goed belast wordt door games; op vier of vijf grote engine-onderdelen na (physics/rendering/audio/engine/netwerk) zijn games lastig verder te verdelen over processorkernen. Genoeg ruimte om een consumentenprocessor te belasten, maar een threadripper wordt een uitdaging

[Umbrah]

Threadrippertje is gelukkig niet alleen voor games. Was destijds een machine learning (en wat video editing...) monster, work hard, play hard. Enige reden dat ik niet naar een 3900x ben gegaan direct is dat ik er ook momenteel 40PCI-E lanes aan gebruik aan heb hangen...

En de codecomplexiteit ben ik mij heel erg van bewust, nog clusters lopen programmeren namelijk. De methode van DX12 (en dat lijkt op wat Valve nu wil doen...) is echter daarom zo elegant... het gaat namelijk puur enkel en alleen om een stuk aanpassing van de draw call. Het laatste stukje in de loop van een game (elke game heeft globaal een loop: verwerk input, update game, teken game) wordt multithreaded gedaan. Dat kan betrekkelijk eenvoudig omdat er een gigantisch stuk overhead in zat, effectief krijg je een soort van 4-cilinder motor (of meer) waar altijd een pitje in 'ontsteking' is

[onox]

Toch zal het nog wel even duren voordat je Threadripper goed belast wordt door games; op vier of vijf grote engine-onderdelen na (physics/rendering/audio/engine/netwerk) zijn games lastig verder te verdelen over processorkernen.

Moderne engines gebruiken een job-based system ipv een task-based system: ze delen al het werk op in kleine jobs die vervolgens door een willekeurige cpu core verwerkt kan worden. De cores worden op deze manier beter benut.

[danoam]

Valve doet hele mooie dingen; Proton/Steam Play, Mesa, Fossilize, ACO shader compiler, Valve huurt zelfs devs in om aan Kwin (KDE's compositor) te werken. Valve is fking geweldig.
Dit alles is nog niet eens zo heel oud maar toch heb ik al een hele poos geen dual-boot met Windows meer, ik zie er zelfs van af om een Windows VM met PCI-e passthrough te draaien, en het wordt alleen nog maar beter.

[Reactie gewijzigd door danoam op 23 juli 2024 02:56]

[Tetraquark]

idd. ik zit ook elk jaar op de wipwap om te switchen. het komt steeds dichterbij

[MeMoRy]

Geweldig! Aangezien de source opensource zal zijn, valt hij in te zien en kunnen wij er wellicht iets van leren!
Ik maak me niet zo'n zorgen voor de toekomst van Linux. Ik bedoel: als het niets toevoegt dan wordt het niet gemerged. Als het later blijkt tegen te vallen, wordt het er weer uitgesloopt.

[alex4allofyou]

Kan iemand mij uitleggen waarom dit zo lastig realiseerbaar is en MS dit wel kan met DirectX? Zoveel jaren en nog steeds Linux geen goed alternatief voor gaming.

[rdcL.be]

Microsoft geld, uiteraard.

[Verwijderd]

Er is hier genoeg 'hot air' in het commentaar om een groene energie centrale draaiend te houden.

[eL_Jay]

Voor de mensen die zich afvragen waarom dat mensen positief zijn over valve (en niet over Epic). Zie hier hoe valve zich blijft inzetten voor een betere wereld voor gamers. De enige gamestores die dat doen zijn GoG en steam.

GoG met het fixen van klassiekers zodat ze op moderne systemen draaien en GoG connect (wellicht 2.0 de volgende grote stap?)
En steam met steamOS, steammachines, Vive/VR, Linux pushen, cross platform, steam link etc.etc
Wat brengt Epic ons? Exclusives Oh ja en de spyware natuurlijk niet vergeten.

Epic is de kwaadaardige tumor voor gamers.

Edit: wauw de liefde voor Epic en de EGS zit hier dieper dan ik dacht. Na het vermoorden van UT en de shit praktijken in de EGS had ik minder fanboyism hier verwacht. Van de andere kant fortnite heeft natuurlijk een groot bereik. Ook hier op T.net.

[Reactie gewijzigd door eL_Jay op 23 juli 2024 02:56]

[The Zep Man]

Epic isBeursgenoteerde bedrijven en bedrijven in bezit van beursgenoteerde bedrijven zijn de kwaadaardige tumor van gaming.

Zodra het enkel om geld gaat verliest gaming zijn waarde. Zie EA, Activision, Ubisoft...

En Valve doet inderdaad goed werk. Helaas kijken veel gamers niet verder dan Fortnite.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 02:56]

[eL_Jay]

Ben ik niet met je eens. De door jouw genoemde bedrijven krijgen terecht veel haat, maar Epic is wel echt buitencategorie.

Dat de door jou genoemde partijen hun pareltjes op hun eigen platform houden is wat anders dan third party Dev's betalen voor exclusiviteit of zelfs games wegkopen van steam . (Ik weet dat die bedrijven meer op hun kerfstok hebben maar epic's shit praktijken zijn imo next level)

[kakanox]

Stelling: De beurs is voor niemand goed.
Het zorgt ervoor dat de geldelijke belangen volledig losgekoppeld worden van zowel het product als de lange termijn.

Het zal een aandelenboer echt niet boeien of Epic over 6 jaar nog bestaat. Als zijn/haar/hun dividend maar komt, en de aandelen met winst verkocht kunnen worden voor het schip zinkt.

Mijns inziens wordt de wereld mooier als we enige vorm van inhoudelijke deelname en/of belangen gaan verplichten voor investeerders. Complex om op te handhaven, maar de moeite waard om over na te denken.

[loki504]

Epic brengt ons UR engine? Maakt vele duizenden al niet miljioenen mensen blij met hun Fortnite?

Gamers hebben ook veel aan Epic te danken. Alleen niets aan hun Store. Maar
Alle extra die je noemt komen ook niet door de Store zelf(wel het geld wat de store verdient).

[SomerenV]

Voor de mensen die zich afvragen waarom dat mensen positief zijn over valve (en niet over Epic). Zie hier hoe valve zich blijft inzetten voor een betere wereld voor gamers. De enige gamestores die dat doen zijn GoG en steam.

Wat De reden dat mensen negatief zijn over Epic is vanwege de aggressive manier van het platform pushen door middel van third party exclusives. Valve is ook gewoon een bedrijf dat winst wil maken en hoewel ze op dit moment meer doen dan Epic heeft dat weinig te maken met 'inzetten voor een betere wereld voor gamers'. Het is geen liefdadigheidsinstelling

Prima dat Valve zich inzet voor gamen op Linux natuurlijk, maar je hebt het dan over een vrij klein groepje gamers. Het overgrote deel zal het een rotzorg zijn of een game wel of niet op Linux werkt.

[Ramobo]

Valve heeft met steam heeft dan ook al jaren een monopoly.
En het is in hun eigen voordeel om meer gamers op Linux te houden als ze de enkele store zijn die daar degelijk op werkt.

Wat brengt Epic ons? Exclusives

Daarover gesproken, ik speelde Dauntless in de beta voor MHW uit kwam en zag Sp4zie het streamen en dacht dat wil ik nog eens spelen, open de launcher van Dauntless en krijg de message download the Epic store to continue your adventure. Dus ze smijten zelfs geld naar free games.

[TheVivaldi]

Ze zijn niet de enige gamestore op Linux die degelijk werkt, maar wel de enige met veel grote titels.

[CaiGil]

Even inhakend daarop, Dauntless is van Epic dus ergens begrijpelijk dat deze in hun eigen store staat..

Geen idee hoe dit idee als feit in mijn hoofd zat... is dus niet zo.

[Reactie gewijzigd door CaiGil op 23 juli 2024 02:56]

[Ramobo]

Ik ga uiteindelijk moeten plooien en de Epic store downloaden...
Ik zat in de closed beta van Dauntless met hun eigen launcher om het dan te spelen tot open beta en nu na 6 maanden te horen dat het ook in die crappy store staat frustreert mij wel, ik ben grote AC fan en launch die ook al via Steam, nu moet ik daarvoor weer een store downloaden die ik nooit ga gebruiken.
Hetzelfde met Borderlands 3, exclusive van Epic, maar het beste aan Borderlands 2 op Steam was het insta joinen van friends.

[Sissors]

Tja en ik zou juist willen dat ik bij een winkel gewoon een spel kan kopen zonder al dat gedoe eromheen. Als ik een spel bij de Bart Smit koop zie ik het ook niet als minpunt dat de Bart Smit zich niet bezig houdt met de Linux kernel.

Overigens is het wel heel creatief te stellen dat Steam/Valve ons Vive heeft gebracht. Ja, ze hebben meegewerkt aan de tracking van Vive. Maar laten we wel wezen, ook het VR gedeelte van HTC gaat het niet redden met dat ze van Valve de kruimeltjes van hardware verkopen mogen krijgen, terwijl Valve lekker 30% naarbinnen harkt van alle software verkopen van die Vive headsets.

Mijn probleem met Epic is dat de interface van hun webshop ruk is. Toen ik eens wilde kijken hoeveel Anno kostte bij hun, was hij niet te vinden via hun homepage. Dan maar erop zoeken: nul resultaten. Zoeken via Google en ik kreeg direct de juiste pagina. Maar verder heb ik nul problemen met Epic Store. Of nou ja, één probleem en dat is dat ze nog steeds een launcher door je strot duwen die altijd moet draaien als je een spel speelt die je daar gekocht hebt.

[StefanJanssen]

HTC verdient ook gewoon aan zijn eigen store die ook door bedrijven gebruikt wordt en directe integratie met steamVR heeft. Ook hebben ze een abonnements dienst.
Dat het niet loopt komt niet vanwege Valve maar omdat ze hun headsets te duur in de markt zetten om ook daadwerkelijk software te kunnen verkopen.

[Sandor_Clegane]

Epic heeft net 1.2 miljoen aan Blender gegeven. Niet alles is slecht.

[SuperDre]

Oh please get your head out of your ass...

Nee, jouw haat voor epic en EGS zit zo diep, en juist JIJ bent degene die overloopt van fanboyism..

Je vergeet even dat Epic ook hun UnrealEngine heeft en daar ook heel veel geld mee ophaalt, en die UnrealEngine is wel degelijk een vooruitgang voor gamers, namelijk dat deze engine ook multiplatform is en het voor developers makkelijker maakt om dus simpel voor meerdere platformen te kunnen releasen (ik zeg niet dat het zo simpel is als 1 druk op de knop).

Het is juist de blinde haat van mensen zoals jij die mij tegen de borst stuit, puur alleen maar omdat je niet je game kunt kopen in jouw favoriete store (maar ook alleen maar vanwege je eigen koppigheid dus ook niet kunt spelen op de PC). En je doet net alsof de Steam client/store zo geweldig is, het heeft wel zo'n 15 jaar geduurd voordat steam is wat het nu is, waarvan jij en je kornuiten vinden dat Epic dat ook even in 1 keer maar zo moet hebben. JA, er zijn zeker dingen bij EGS waarbij je vraagtekens zet (zoals zoiets simpels als geen winkelkarretje), maar ook Steam is verre van perfect (komende van iemand die een gigantische library in steam heeft, en een behoorlijke in Gog).

En dat van spyware is al helemaal bullshit, in dat opzicht was steam vroeger vele VELE malen erger, enige wat Epic deed was een bestand dat vrij op de harddisk te benaderen is inlezen, maar pas gebruik van maken wanneer de gebruiker er werkelijk om vroeg (dus niets werd al naar hun servers gestuurd voordat de gebruiker iets deed)..

En vergeet niet dat het bij Valve ook maar om 1 ding draait, alles wat ze doen is om meer mensen naar steam te krijgen en zo nog meer geld binnen te krijgen.. (en ik neem ze het ook niet kwalijk, het is immers een bedrijf en geen sociale instelling) Dus doe nou niet net alsof Valve zo filantropisch is, ook bij hun gaat het om het geld.

[Ayporos]

Er is altijd iets ergers... G2A bijvoorbeeld is toch nog echt stukken erger dan Epic ooit zal zijn.

[loki504]

[Sarcasme mode on]Maar die zet zich toch ook in voor een goedkopere game wereld. En dat is toch ook goed? [sarcasme mode off].

/edit nu beter?

[Reactie gewijzigd door loki504 op 23 juli 2024 02:56]

[StefanJanssen]

Dit zet zich voor in meer illegale praktijken en kosten voor ontwikkelaars.

[loki504]

Het was sarcasties bedoeld. Maar dat kwam blijkbaar niet helemaal over

[Noppie1991]

Met keys van dubieuse afkomst. Veel keys die daar op staan zijn verkregen met gestolen creditcards. Uitgevens / ontwikkelaars verdienen hier helemaal niets op omdat het geld vaak wordt teruggevorderd door de rechtmatige eigenaar van de creditcard.

[sprankel]

Uitgevens / ontwikkelaars hebben daar geen last van tenzij ze de codes zelf via een webshop aanbieden en dus zelf verkopende partij zijn en zelf de credit cards authoriseren.

Indien je een winkelier bent en er word betaald met een gestolen kredietkaart of een gestolen bankkaart dan is de vraag wie de autorisatie heeft uitgevoerd.

Voor een bankkaart bij draadloos betalen is dat het simpelste, de bank authoriseert.

Bij oplichting via telefoon en je geeft codes door is de eigenaar van de rekening diegene die authoriseert en dus verantwoordelijk, al kan het zijn dat een bank/verzekering tussenkomt, ze zijn dit niet verplicht.

Als je een bankkaart kwijt speelt en iemand "kraakt" ze, de bank authoriseert en is verantwoordelijk. Echter de bank kan claimen dat jij een te eenvoudige pincode gekozen hebt, de pincode genoteerd hebt op een papier bij de kaart, etc waardoor de bank de schuld naar de eigenaar van de kaart kan afschuiven.

Voor een credit card,
-Bij gebruik van de magneet streep zonder code => verkoper authoriseert (tenzij de kaart enkel magneet heeft maar die bestaan niet meer denk ik)
-Bij gebruik van de kaart geen pin code vragen => verkoper autoriseert tenzij de kaart geen pincode ondersteund
-Bij online betalen zonder 3D secure => verkoper autoriseert tenzij de kaart geen 3D secure of andere verificatie ondersteund.

Als je echter fysiek altijd een code vraagt en bij online 3D secure of andere verplicht ben je als verkoper nooit diegene die autoriseert en dus kan er ook geen geld terug gevraagd worden.

Voor een tolweg in Frankrijk is het wel zo handig als men geen pin code vraagt, er zijn dus wel cases voor maar voor online is er geen reden om als verkoper geen bijkomende verificatie te vragen.

Echter zijn ze in de US allergisch voor pin codes en verificaties, online bankkieren kennen ze daar ook niet (laatste wat ik gehoord heb is dat je nu online kunt zien hoeveel er op je rekening staat, that's it).
Verkopers blijven daar zelf opdraaien voor fraude omdat ze schrik hebben dat hun klanten gaan lopen als ze een pincode gaan vragen. Wat je dan wel weer hebt, als je ooit betrapt bent op fraude dan krijg je nooit nog een kredietkaart terwijl alles daar met een kredietkaart betaald word, zonder kredietkaart word je als crimineel aanzien, met kredietkaart ben je een normale burger en met een American Express Centurion ben je VIP, het is daar echt een status symbool dat bepaald in welke sociale klasse je zit.

[Reactie gewijzigd door sprankel op 23 juli 2024 02:56]

[Mirved]

Net als junks die gestolen fietsen verkopen een goeie daad verrichten voor de fietsenmarkt

[RoamingZombie]

Leer eens een keer dat sarcasme zo goed als niet overkomt in geschreven tekst.

[Ayporos]

Sarcasme komt prima over... mits je correct een emoticon gebruikt.

[dmantione]

Natuurlijk doet Valve dit om hun afhankelijkheid van Microsoft te verminderen en daarmee hun geldmachine dominant houden. Dat betekent niet dat de plannen Microsoft automatisch in het belang van de spelfanaat zijn. Dat is het verschil tussen Epic en Valve: Brian Reynolds loopt alleen maar in de pers te klagen hoe slecht Microsoft is met hun Windows-store en het uitfaseren van Win32/64. Geen enkele spelspeler heeft daar iets aan gehad. Valve klaagt weinig, maar pakt het probleem bij de bron aan. Dat is in het belang van de speler. Vanzelfsprekend is de echte lachende de Linuxgebruiker geweest, die langzaam maar zeker een eersteklas spelplatform heeft gekregen. Ook vanuit de Linuxgebruiker gezien is er nog al een verschil tussen Valve en Epic.

[batjes]

Valve klaagt weinig? Google voor de gein even rond. Ze zeiken Microsoft al tig jaar af. Enorme rants van "Computergod" Gabe.... Ze hebben opzicht ook wel een punt, ik zie liever ook niet dat Microsoft met hun store zo dominant wordt als Valve met die van hun. Maar daar ligt de cringe een beetje.

nieuws: Valve-directeur: Windows 8 is een ramp Deze hele hetze vergeten?

Brian Reynolds werkt niet voor EPIC of Valve, maar voor Big Huge Games... die enkel mobiele games ontwikkelen vandaag de dag, snap niet helemaal waarom je hem aanhaalt in deze discussie.

EPIC valt andere bedrijven/stores niet af, en dat siert ze wel. Microsoft valt anderen ook niet af.

Het vervangen van Win32 door UWP is niet slecht. Ik speel ondertussen genoeg UWP games zonder problemen. Draait vaak een stuk lichter ook nog eens. Win32 stamt nog uit het vorige millenium. Wordt hoog tijd dat die puinhoop vervangen wordt. Hier hebben wij ook als gamers heel veel aan. Of is veiligheid en minder resourceverbruik niet iets wat je graag ziet?

[todhoward]

Ik denk dat hij Tim Sweeney bedoelde, die zat al een tijdje bezig hoe slecht Windows 8 en 10 is en hoe UWP een "closed platform" ging creëren.

Destijds kon je alleen UWP installeren via de Windows Store, en Microsoft had al plannen voor een UWP only OS (Windows 10 S). Ergens ironisch sinds Gears Of War 4 een van de betere UWP games waren op de store. Er waren ook een aantal problemen met UWP zoals locked framerate, forced fullscreen, geen raw input etc etc Meeste hiervan zijn ondertussen al verholpen.

Terwijl Tim Sweeney dus zwaar van zijn neus aan het maken was op Twitter enzo, was Valve al druk bezig met Steam op Linux te krijgen (inclusief hun gefaalde Steam Machines, een poging die misschien meer succes had als ze Proton ervoor hadden ontwikkeld). Timmetje zijn responds op Linux was "the equivalent of moving to Canada when one doesn't like US political trends".

Vreem genoeg is de Epic GameStore geschreven in Electron, een handig framework om multiplatform apps te ontwikkelen, maar toch is EGS niet op Linux te krijgen (ook al hebben ze wat games in de store toegevoegd die dat wel zijn, via Steam dan). Overigens support Unreal Engine niet alleen Linux porting maar kan je ook developen op Linux. Toch is geen enkel van Epic hun eigen games verkrijgbaar op Linux zonder Wine of dergelijke te draaien.
Het is duidelijk dat Epic even hard als Valve vreest dat Windows een gesloten platform word met alleen de Windows Store als toegang, maar ondertussen gaan ze niet 'all in' zoals Valve.

Er is duidelijk nood aan competite voor Windows, Direct3D was bijna dood als het niet was voor Valve en hun OpenGL optimalisatie die hun games beter deed draaien op Linux. Ze zien het niet als "moving to Canada" maar eerder "like a club held over MS's heads", misschien word het tijd dat Epic het ook zo begint te zien.