[copperpen]

Have just updated via SVN and now find that in all views I have five coloured bands running across the lower third of the screen when in debug mode. Is this supposed to be the additional debug data introduced in X1684?. If yes, how is the data used?.

When in debug I see that the GPU line now has P95 and P99 values. I am wondering what these are showing because my P99 hits 230% occasionally, when the tile shape/texture load process activates.

[engmod]

http://www.elvastowe...toring-in-game/

[copperpen]

Sorry but that link returns an error, unable to locate.

[roeter]

Here is the info :

Quote

In X.1682 and X.1684 I have updated and expanded the in-game UI for performance data shown on the DEBUG page of the HUD (F5) popup window. There are two key features:

1. The HUD DEBUG text now includes data about P-95 and P-99 statistical percentiles for frame time (measuring FPS). It shows how much slower the P-95 and P-99 frame times are to the P-50 (mode) frame time, which is shown as well. Data is collected and kept for 10 seconds.

To give you some idea what these values mean, a P-95 display of "25%" means that 5% of frames (in the last 10 seconds) were 25% or more slower than the mode (middle value). Similarly, for P-99 and 1% of frames. What this does is allow you to see how consistent the game is being at rendering frames - lower P-95 and P-99 percentages are better.

2. When the HUD DEBUG page is active, 5 live graphs are drawn in the bottom-right of the screen. These are, from top to bottom, frame time, render process, updater process, loader process and sound process. The graphs are updated every frame, though the four process graphs only have new data every 250ms (for performance reasons). The frame time graph is accurate to the frame.

These graphs will allow you to see exactly when and how much the processes doing work affects the frame time, both in overall FPS and in terms of variation (jitter, stutter, etc.).

James Ross
Open Rails 3D & Environment Lead Developer

Regards,

Rob Roeterdink

[copperpen]

Thanks Rob. Now I understand the figures and exactly what the moving graphs are showing. The load process is taking up far too much processor time to give a smooth experience. Just like MSTS.

[James Ross]

copperpen, on 22 July 2013 - 11:54 AM, said:

Thanks Rob. Now I understand the figures and exactly what the moving graphs are showing. The load process is taking up far too much processor time to give a smooth experience. Just like MSTS.

Not true, the loader is meant to use the processor it does and its CPU usage is completely unrelated to any non-smooth experience you have. It is people making such statements that make me hesitant to show any data live in OR, so you can expect these graphs to be hidden in the future.

[copperpen]

No need to get defensive. If it is not the usage of processor time, what then would the cause of not getting a smooth ride. As it stands when the load process peaks, and the processor unloads at the same time, it very briefly affects the physics model and generates wheelslip. The actual numbers of shapes and textures held in memory does not actually vary by much, but at tile load, the load process hits 90 to 100%, the processor load drops from 57 to 25%, I get a few judders, a short freeze, a few more judders then the load process drops to 0%, the processor runs back up to 57% until the next big load sequence. The FPS on this route ( Surfliner 2 ) are between 35 and 50 in built up areas.

[James Ross]

copperpen, on 22 July 2013 - 01:17 PM, said:

No need to get defensive.

Oh, that's a good one.

copperpen, on 22 July 2013 - 01:17 PM, said:

If it is not the usage of processor time, what then would the cause of not getting a smooth ride.

It is a combination of at least two things, that I've seen so far, but it obviously varies somewhat by PC and route. The main issue is the GPU stalling unnecessarily, due to the poor design of the graphics drivers (at least for NVIDIA). The drivers return from creating and setting up a resource when its data is only in RAM, not VRAM, and then when you try and draw using the new resource (e.g. new texture, vertex buffer, etc.) the GPU stalls (waits idle) while the driver slowly copies it from RAM to VRAM. This is infuriating behaviour to watch as there appears to be no good solution except to simply "wait" between a resource finishing loading, and trying to actually use it (see experimental feature 'loading delay').

The other issues I have seen is generation 2 garbage collections. These are much more unpredictable, and during normal running sometimes occur without any visible pause at all, and other times cause a single frame to be delayed by 100ms. There are many, many factors in this; we could try to not create as much garbage during loading of data, or even just generally, or (my preference) we can try newer versions of .NET (4.0 in particular has some good GC improvements). This is, however, not as easy as in most apps due to the complex libraries we use.

[roeter]

Hello,

now we're one this subject, there's something that's been bothering me for quite some time.
When the system has to load a 'new' sound (i.e. one that's not been played before in this session), the whole display freezes while the sound is loaded.
I would assume that with multithreading etc., display would be independent from sound, but apparantly that is not so.
Are we one thread short - should sound have it's own thread? Or is there something else going on in the background that's causing this?

Thanks,

Rob Roeterdink

[Lindsayts]

James Ross, on 22 July 2013 - 01:04 PM, said:

Not true, the loader is meant to use the processor it does and its CPU usage is completely unrelated to any non-smooth experience you have.



It is people making such statements that make me hesitant to show any data live in OR, so you can expect these graphs to be hidden in the future.

A minor comment on the last sentence :rotfl:,

Thats the exact reason why most cars do not have numerals on any temp or pressure gauges (if they have them). This goes back to at least the 1960's when car manufacturers started getting many complaints of fault cooling systems not long after the introduction of high cooling system pressures. These pressures allowing a higher coolant temperature and allowed the engine to run more effiecently and also the heater performed better. The solution adopted was to remove the numbers and provide a out of range colour coding on the scale.

Lindsay