Performance drop on dGPU after running openBVE on integrated graphics

[mc0406]

Description

Performance drop on dGPU after running openBVE on integrated graphics. For example ~50fps drop to ~24fps in the same route section and train.
Reinstalling openBVE and restarting pc do not help.
However, clear the openBVE folder in Appdata\Roaming and setup the setting again may solve the issue.

Occuring in latest daily build.

Reproduction

Play openBVE with integrated graphics > Close it > Play openBVE with dedicated GPU (No openBVE setting is altered).

I tried the process twice and both result performance drop.

Related information

• Operating system: Windows 11
• Method of control: Keyboard
• GPUs: AMD Radeon 780M, RTX 5060 Laptop GPU

[leezer3]

That's very odd.

There's nothing in the code which will do this directly- My best guess from the limited information is that there's a setting which is only taking effect after a restart of the game, but this shouldn't be the case.

[adfriz]

AFAIK, nvidia app or nvidia control panel have a feature for setting the app what gpu it should use, maybe you can set that?

it should also have an option to show "use nvidia gpu for this app" in right click menu if im not mistaken, so it force to use the dedicated gpu

[mc0406]

I always use the MUX switch to link Nvidia GPU and the laptop monitor directly when playing openBVE with Nvidia GPU. openBVE is forced to use Nvidia GPU under this mode. Also shown in Nvidia GPU activity indicator.

[mc0406]

P.S. @leezer3 I really find a setting which is only taking effect after a restart of the game during the first startup of openBVE after installation.
It is the level of anisotropic filitering. Idk this is intentional or a bug.

[soyachoin104]

Hi, I noticed I was also getting a big performance drop in the recent builds and I would like to comment here as this seems to be very similar to what I was experiencing. This occurs for me in latest stable but even when switching to 28th August nightly build I still experience this.

For me, despite using an RTX 3070 with 16GB RAM and an i7-12700H, I have noticed with certain high detail routes and trains, the performance when I switch to exterior view drops to single fps in some sections. This was the experience I used to get several years ago when I had a much lower spec computer but I am surprised that the fps drops so much on routes and trains that I thought were fairly decent performing in versions of the game from early this year and now run like I still use my old potato.

I've attached one of the trains for replication purposes. This train used to run fairly decently before but now barely cracks 5fps in the external view.

Route: I used the animated object demo route

Train: https://haesangang-0317.tistory.com/253 it is a fairly detailed train.

I'm curious what could have caused the massive performance drop in the recent builds. If you need anymore information, please let me know

[leezer3]

OK, I see what's going on.

It's the object optimisation settings. Specifically, the BVE5 parser and the Hmmsim handling code set this to a much lower threshold, as they tend to have insane sized objects, and running full optimisation on these (vertex culling etc.) absolutely kills loading time.

The train in question's optimisation is terrible by default- 111,000 odd faces. Running optimisation on it gets this down to 800 odd.

To fix the issue on a tempoary basis, open the OpenBVE settings file in appdata, and set the ObjectOptimization ==> basicThreshold value to 10,000.

#1381 this PR made some improvements to the optimization process.
It may be better to remove the threshold setting altogether? @adfriz any thoughts?

[adfriz]

Yeah i think better remove it.

But maybe only in the main openbve?

Obj and route viewer may still need threshold so every reload not entirely got slowed by the optimizer.

[adfriz]

@leezer3

i have a quick look at the code, it seems the full threshold is an unused code?

[leezer3]

Looking at it, seems to be.

From the original source, if face count below the full threshold, things were de-composited into polygons / tris as opposed to quads.
GL4 in forwards compatible mode requires tris though.

Way too much legacy junk floating around...

[adfriz]

@leezer3
A bit off topic, i have test that korean train above in obj viewer. The 280 train type, only the 0.animated loaded.

it use more than 6gb ram...

By the looks of it, obviously the texture is the cause... most of it 2K and 4K and some multi object state cycle tricks for video LCD, do you think implementing texture limit is ok for this?

idk how should approach this, one way is a global setting in main game or a separate settings as usual in options cfg so viewers can set separately. But this really hit the runtime cost or at load.

[leezer3]

Basically, I'm not sure exactly how much you can do when you're dealing with something that's so badly optimised....

There is the unload unused textures option in the main game itself which I think is essentially what you mean, but that's got it's own set of problems, especially with something like this. The classic case would be switching to exterior after a time in the cab- With this, you'll get nasty stutters...

[leezer3]

Looking at this, I think there's a serious optimisation to be had in the GIF decoder.

Our two GIF files are eating approximately 4gb of memory. This is because they're being upconverted from 256 colors as stored in the GIF to full 32-bit color.