Steam

10304 readers

2 users here now

Steam is a video game digital distribution service by Valve.

Steam News | Steam Beta Client news

Useful tools:
SteamDB
SteamCharts
Issue tracker for Linux version of Steam

founded 3 years ago

MODERATORS

testman@lemmy.ml

1265

What do you think of this prediction? (programming.dev)

submitted 5 months ago by federino@programming.dev to c/steam@lemmy.ml

376 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] ulterno@lemmy.kde.social 0 points 5 months ago (1 children)

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?

[–] Lets_Eat_Grandma@lemm.ee 1 points 5 months ago (1 children)

I mean if you're german you could try working for them lol

[–] ulterno@lemmy.kde.social 1 points 5 months ago* (last edited 5 months ago) (1 children)

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.

[–] Lets_Eat_Grandma@lemm.ee 2 points 5 months ago (1 children)

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.

[–] ulterno@lemmy.kde.social 0 points 5 months ago

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.