Yeah, and lots of new popular indie games. Some recent oneish I’ve got are DREDGE, Rimworld and Stardew Valley. OK not super recent but not all the games are 20 years old or more. Even Skyrim Anniversary is on there.
Yeah, I recently bought X4, which is so badly implemented (at least on Linux) that it gives the same FPS (in the 30s) on Low settings as it does on Ultra.
I even went ahead and bought a new GPU just for that and hardly see a difference, even being suspicious of there being a miner in it.
I mean if you’re german you could try working for them lol
That seems to be the main barrier, yeah.
But I checked htop while running the game and it doesn’t seem to be doing all single core stuff as you said.
Unless it is that the bottlenecking thread is not even using the available core to the full extent.
I checked it out with both linux and linux-zen kernels.
Usually, when a program is loading on a single thread, you tend to see a single core go to 100% for a few seconds, which then jumps around as the OS switches the core provided to the thread. That was not happening here.
Also, the new GPU is sometimes at ~60-70% while the FPS is dropping to 30.
This part was weird.
All I know is what many have said time and time again. There is one main thread that everything else depends on, so no matter how much horsepower you throw at it you are constrained by whatever logic or calculation that one thread is doing.
For all I know it’s a memory bandwidth thing or even a disk access thing pertaining to that one thread which makes everything else wait. They use their own homegrown engine and there’s a bottleneck in the code somewhere, obviously.
I’m kind of surprised they don’t have something that’s more scalable because they built a new engine for X:Rebirth which came out in 2013. Maybe they started the engine rebuild before dual core and quad core cpus were mainstream in the late 2000s.
Well, when you make a multithreaded application, usually there is one main thread, which controls everything else, timings and all.
The alternative
is to have all threads know how to sync with whichever other thread they need to sync with, whenever they need to. This way tends to be more difficult (and I am yet to think of a use case and application methodology for this method).
Now usually you make sure not to have any blocking function (large calculation or file R/W requiring HDD fetching) on the main thread.
Maybe they made some mistakes in this regard in their previous games and did better this time.
From what I see, it seems like they didn’t use the graphics API (seems to be Vulkan) properly enough, for which I can’t do anything, given my lack of exp with it.
Perhaps a god time for me to delve into Vulkan.
And of course the ones they (i.e. CD Projekt Red) make themselves. The Witcher series, including Gwent spinoffs, and Cyberpunk 2077
Yeah, and lots of new popular indie games. Some recent oneish I’ve got are DREDGE, Rimworld and Stardew Valley. OK not super recent but not all the games are 20 years old or more. Even Skyrim Anniversary is on there.
Yeah, I recently bought X4, which is so badly implemented (at least on Linux) that it gives the same FPS (in the 30s) on Low settings as it does on Ultra.
I even went ahead and bought a new GPU just for that and hardly see a difference, even being suspicious of there being a miner in it.
Fun game nonetheless.
x series has largely been cpu limited by single main thread as long as it’s existed fwiw
Wait, so all I had to do was disable my underclock and I would have gotten the same marginal perf gains that I got by upgrading both my CPU and GPU?
Will Egosoft hire me if I offer to refactor their code into something multithread friendly?
I mean if you’re german you could try working for them lol
That seems to be the main barrier, yeah.
But I checked
htopwhile running the game and it doesn’t seem to be doing all single core stuff as you said. Unless it is that the bottlenecking thread is not even using the available core to the full extent.I checked it out with both linux and linux-zen kernels.
Usually, when a program is loading on a single thread, you tend to see a single core go to 100% for a few seconds, which then jumps around as the OS switches the core provided to the thread. That was not happening here.
Also, the new GPU is sometimes at ~60-70% while the FPS is dropping to 30. This part was weird.
All I know is what many have said time and time again. There is one main thread that everything else depends on, so no matter how much horsepower you throw at it you are constrained by whatever logic or calculation that one thread is doing.
For all I know it’s a memory bandwidth thing or even a disk access thing pertaining to that one thread which makes everything else wait. They use their own homegrown engine and there’s a bottleneck in the code somewhere, obviously.
I’m kind of surprised they don’t have something that’s more scalable because they built a new engine for X:Rebirth which came out in 2013. Maybe they started the engine rebuild before dual core and quad core cpus were mainstream in the late 2000s.
Well, when you make a multithreaded application, usually there is one main thread, which controls everything else, timings and all.
The alternative
is to have all threads know how to sync with whichever other thread they need to sync with, whenever they need to. This way tends to be more difficult (and I am yet to think of a use case and application methodology for this method).
Now usually you make sure not to have any blocking function (large calculation or file R/W requiring HDD fetching) on the main thread. Maybe they made some mistakes in this regard in their previous games and did better this time.
From what I see, it seems like they didn’t use the graphics API (seems to be Vulkan) properly enough, for which I can’t do anything, given my lack of exp with it. Perhaps a god time for me to delve into Vulkan.