2023-02-06 snapshot

[jlv]

Changes:

• Decals now use static vertex arrays instead of dynamic.
• Terrain textures are now updated incrementally.
• Terrain textures now copy any overlapping area instead of redrawing it when moving coverage area.
• Terrain texture presets are now 1024x1024 for high fps, 2048x2048 for normal and 4096x4096 for high.

Update 2023-02-13:

• Clear terrain textures on load to work around slow first renders on Nvidia cards.

Windows users: https://mxsimulator.com/snapshots/mx-2023-02-13-1644.exe
Linux users: https://mxsimulator.com/snapshots/mxbin-2023-02-13-1644

[crotty103]

whats this supposed to help? or change

[Jakob Hubbard]

Only thing I've noticed is that /toggledecals seems to be broken, other than that works solid so far. Ideally it would be nice to get the terrain texture drawing at the beginning to not drop fps but not sure if that's something worth looking into. Just weird to get used to compared to the old terrain engine.

[jlv]

Only thing I've noticed is that /toggledecals seems to be broken, other than that works solid so far. Ideally it would be nice to get the terrain texture drawing at the beginning to not drop fps but not sure if that's something worth looking into. Just weird to get used to compared to the old terrain engine.

Bad performance is not acceptable so let me know exactly where it's doing badly.

I was actually pretty happy with how it was doing in my benchmarks. Here's a histogram of frametimes for the first 4000 frames on alcrest, 4096x4096, prev version vs this version. First column is number of frames, second column is the frame time. This is with the integrated graphics on a 2400g.

2022-12-23-1637:

Code: Select all

   3895 0.008
      5 0.009
      1 0.010
      2 0.011
      1 0.014
      1 0.015
      2 0.017
     11 0.018
      8 0.019
      6 0.020
      3 0.021
      2 0.022
      4 0.023
      3 0.024
      2 0.025
      1 0.026
      2 0.027
      1 0.028
      2 0.029
      6 0.030
     10 0.031
     11 0.032
      6 0.033
      4 0.034
      4 0.035
      3 0.036
      1 0.037
      1 0.038
      1 0.041
      1 0.127

2023-02-06-1643:

Code: Select all

   3999 0.008
      1 0.118

Aside from the very first frame where it needs to draw everything from scratch the slow frames are completely eliminated! Could be doing badly on other tracks or graphics cards though. For fun I mostly just time trial on the SX tracks and those went from basically unplayable at 4096x4096 to perfectly smooth with this version. So again, let me know what I should be testing.

[Jakob Hubbard]

2023-02-06-1643:

Code: Select all

   3999 0.008
      1 0.118

Is there a way in the game I can time my frames like that so it's easier for you to see exactly what my PC is doing? I can show you a /fpshist of first loading into a 2023 sx track and give you my specs but other than that I'm not really sure how to help.

Loading in on 2023 Houston at medium res and 4096x4096 textures

Code: Select all

128=2503 64=3 32=14 16=2 8=9 4=0 2=0 1=1

Specs:
i9-9900k 8-core 16-thread at 3.6GHz
32gb ddr4 2667MHz
rtx 2070 Super

[jlv]

Is there a way in the game I can time my frames like that so it's easier for you to see exactly what my PC is doing? I can show you a /fpshist of first loading into a 2023 sx track and give you my specs but other than that I'm not really sure how to help.

Use "/saveframetimes". It'll save the frame times in "%localappdata%\MX Simulator\frametimes.txt". I made the histograms like this but you need Linux or maybe cygwin for it:

Code: Select all

head -4000 ~/.mxsimulator/frametimes.txt | awk '{printf("%.3f\n", $1)}' | sort -n | uniq -c

Loading in on 2023 Houston at medium res and 4096x4096 textures

Code: Select all

128=2503 64=3 32=14 16=2 8=9 4=0 2=0 1=1

Specs:
i9-9900k 8-core 16-thread at 3.6GHz
32gb ddr4 2667MHz
rtx 2070 Super

I get this just riding around a little on Houston. This is on the ultra low version though. Could be why I'm getting better performance with a much slower system.

Code: Select all

   3975 0.008
     15 0.009
      3 0.010
      3 0.011
      1 0.013
      1 0.014
      1 0.016
      1 5.143

That 5 second first frame is a brutal but pretty OK after that. There's a lot of overdraw in those decals which is hard on integrated graphics. Should probably delete the blueprint decal since it does nothing. Ideally you want to avoid having lots of layers of stuff. When I did the decals on my tracks I'd go in reverse order, first the track, then cover the areas where the plywood shows, then finish with the concrete decals. Then put them in the right order with a text editor.

[Jakob Hubbard]

That 5 second first frame is a brutal but pretty OK after that. There's a lot of overdraw in those decals which is hard on integrated graphics. Should probably delete the blueprint decal since it does nothing. Ideally you want to avoid having lots of layers of stuff. When I did the decals on my tracks I'd go in reverse order, first the track, then cover the areas where the plywood shows, then finish with the concrete decals. Then put them in the right order with a text editor.

This data is confusing to me because even testing on a track I'm currently building with just only 2 decals, one being an overlay and the other being a blueprint I'm still getting horrible times on 1 frame.

Here's some data from a little test run I had on the track I'm building with only 2 decals.

Code: Select all

11800 0.008
75 0.009
1 0.011
1 0.014
1 0.015
5 0.017
1 0.019
1 0.021
1 0.022
1 0.027
1 0.039
1 0.042
1 0.046
1 0.048
1 0.049
1 0.053
1 0.060
1 0.079
1 0.085
1 0.087
1 0.091
1 0.098
2 0.099
1 0.101
1 0.104
1 0.105
1 7.824

Here's a run on Houston 2023

Code: Select all

9688 0.008
29 0.009
2 0.011
1 0.013
2 0.016
4 0.017
2 0.019
3 0.020
1 0.026
1 0.034
1 0.041
1 0.042
1 0.078
1 0.079
1 0.088
1 0.090
2 0.091
1 0.095
1 0.097
1 0.103
1 0.104
1 9.460

[jlv]

This data is confusing to me because even testing on a track I'm currently building with just only 2 decals, one being an overlay and the other being a blueprint I'm still getting horrible times on 1 frame.

I was being an idiot. I ran the alcrest test directly from the command line but ran the 2023 houston test from a time trial, which means one frame will count the loading time. I just re-ran 2023 houston from the command line and got this:

Code: Select all

   3951 0.008
     22 0.009
     13 0.010
      6 0.011
      4 0.012
      3 0.013
      1 0.190

I'm a little bit worried about those .1 second frames you're getting but I guess it's only a handful out of 9,000 frames.

[Jakob Hubbard]

I'm a little bit worried about those .1 second frames you're getting but I guess it's only a handful out of 9,000 frames.

I'm pretty sure it's happening on load in and after moving out of the gate for a second when it redraws to center around the rider because I get huge frame drops at those times. Performance wise for me it acts exactly the same as the previous snapshot.

[jlv]

I'm pretty sure it's happening on load in and after moving out of the gate for a second when it redraws to center around the rider because I get huge frame drops at those times. Performance wise for me it acts exactly the same as the previous snapshot.

With it doing incremental updates now it doesn't do nearly as much work per frame as before. Even on my potato tier system it's not dropping any frames. I'm thinking it might be something else. Does it change if you lower the terrain texture resolution?

[Jakob Hubbard]

With it doing incremental updates now it doesn't do nearly as much work per frame as before. Even on my potato tier system it's not dropping any frames. I'm thinking it might be something else. Does it change if you lower the terrain texture resolution?

Lowering my texture resolution to 2048x2048 and I got zero lag spikes, makes me wonder why the initial draw at 4096x4096 is so hard, it's almost as if it doesn't even incrementally update at 4096x4096. The draw at 2048x2048 was incredibly smooth and I noticed the incremental update, but going back to 4096x4096 I couldn't notice it. Possibly a bug or maybe 4096x4096 just is too hard of a draw even with the incremental updating and I just can't see it?

2048x2048 on Tampa 2023

Code: Select all

   3971 0.008
      7 0.009
      1 0.013
      1 0.014
      5 0.015
      1 0.016
      3 0.017
      1 0.018
      2 0.019
      2 0.020
      2 0.021
      1 0.058

[jlv]

Lowering my texture resolution to 2048x2048 and I got zero lag spikes, makes me wonder why the initial draw at 4096x4096 is so hard, it's almost as if it doesn't even incrementally update at 4096x4096. The draw at 2048x2048 was incredibly smooth and I noticed the incremental update, but going back to 4096x4096 I couldn't notice it. Possibly a bug or maybe 4096x4096 just is too hard of a draw even with the incremental updating and I just can't see it?

It looks like you're getting around 1/4 of the performance of my 2400g's Vega 11 graphics. That's suspiciously close to what I'd expect from UHD 630 graphics. Are you sure there isn't some kind of power management shenanigans putting you on the integrated graphics?

[Jakob Hubbard]

It looks like you're getting around 1/4 of the performance of my 2400g's Vega 11 graphics. That's suspiciously close to what I'd expect from UHD 630 graphics. Are you sure there isn't some kind of power management shenanigans putting you on the integrated graphics?

Shouldn't be, looks like the game's driver info is detecting my 2070. Maybe need to update drivers? I have a relatively recent driver. Not a clue why it would be performing like that.

[Jakob Hubbard]

DP but here's my NVIDIA settings related to the GPU that I use

[jlv]

Shouldn't be, looks like the game's driver info is detecting my 2070. Maybe need to update drivers? I have a relatively recent driver. Not a clue why it would be performing like that.

I don't think that actually tells you since the Nvidia driver is still handling the OpenGL calls and passing them through to the Intel driver.

I have this in my code to try to force it to use the right GPU but I don't have high hopes that it actually works.

Code: Select all

#ifdef _WIN32
/* Use discrete GPU by default. */

/* http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/OptimusRenderingPolicies.pdf */
__declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001;

/* http://developer.amd.com/community/blog/2015/10/02/amd-enduro-system-for-developers/ */
__declspec(dllexport) int AmdPowerXpressRequestHighPerformance = 1;
#endif

I think disabling the Intel graphics in device manager will guarantee it isn't used.