Elvas Tower: f5 display and the rendering thread data - Elvas Tower

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

f5 display and the rendering thread data Rate Topic: -----

#1 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,308
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 02 November 2018 - 10:08 AM

On the principle of you cannot manage what you do not measure, would the OR team please expand the display of render primitives data on the last "page" of the f5 display from one to three lines, specifically, Near Terrain Primitives, Shape Primitives, and Distant Mountain primitives?

In the ideal going a bit further to show road and track primitives vs. static shapes vs. rolling stock could be useful too but IMO not as important as seeing what's going on w/ near and far terrain rendering.

Doing so would reveal the "price paid" by different choices made in the viewing distance options.
=================

A somewhat related question: If the OR software was dual GPU capable would that allow a second rendering thread -- one for each GPU? If yes, would that suggest a possibility of substantially increasing fps on PC's with two GPU's?

#2 User is offline   Hamza97 

  • Engineer
  • Group: Status: Contributing Member
  • Posts: 606
  • Joined: 01-March 15
  • Gender:Male
  • Simulator:Open Rails
  • Country:

Posted 04 November 2018 - 08:59 PM

Yeah I would agree with Dave.., having additional info in "Performance Debug" window would be helpful especially for routes and rolling stock developer to assess performance of their routes and/or rolling stocks...

#3 User is offline   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,488
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 05 November 2018 - 12:50 PM

View PostGenma Saotome, on 02 November 2018 - 10:08 AM, said:

On the principle of you cannot manage what you do not measure, would the OR team please expand the display of render primitives data on the last "page" of the f5 display from one to three lines, specifically, Near Terrain Primitives, Shape Primitives, and Distant Mountain primitives?

You can press Alt-F12 to trigger the Debug Log Render Frame command, which will spit out (into the normal log file) full details on every single primitive rendered in the next frame. It is split into three sections: shadows, distant mountains, and everything else. The shadows section is split by the shadow map distances (four unless configured to be less), while the distant mountains and everything else are split by the rendering order "group". Inside all these groups is a list of primitives grouped by material (type + texture), e.g. TerrainSharedMaterial vs SceneryMaterial vs ForestMaterial.

Here is the skeleton, with no primitives except for some lights to show what it looks like:

Draw {
  DrawShadows {
    0 {}
    1 {}
    2 {}
    3 {}
  }
  DrawSimple (Distant Mountains) {
    CabOpaque {}
    Sky {}
    WorldOpaque {}
    WorldBlended {}
    Lights {}
    Precipitation {}
    Particles {}
    InteriorOpaque {}
    InteriorBlended {}
    Labels {}
    CabBlended {}
    OverlayOpaque {}
    OverlayBlended {}
  }
  DrawSimple {
    CabOpaque {}
    Sky {}
    WorldOpaque {}
    WorldBlended {}
    Lights {
      7     * SignalLightMaterial(c:\program files (x86)\microsoft games\train simulator testing\routes\japan2\textures\siglight.ace)
      7     * SignalLightGlowMaterial
      12    * LightGlowMaterial
    }
    Precipitation {}
    Particles {}
    InteriorOpaque {}
    InteriorBlended {}
    Labels {}
    CabBlended {}
    OverlayOpaque {}
    OverlayBlended {}
  }
}


View PostGenma Saotome, on 02 November 2018 - 10:08 AM, said:

In the ideal going a bit further to show road and track primitives vs. static shapes vs. rolling stock could be useful too but IMO not as important as seeing what's going on w/ near and far terrain rendering.

The code has no idea after loading what is a road or track primitive, or what is static vs rolling stock, although using the texture file names the above data might allow you to manually figure it out.

View PostGenma Saotome, on 02 November 2018 - 10:08 AM, said:

A somewhat related question: If the OR software was dual GPU capable would that allow a second rendering thread -- one for each GPU? If yes, would that suggest a possibility of substantially increasing fps on PC's with two GPU's?

Probably not; I don't think DirectX 9 itself is very amenable to multiple threads (and XNA is certainly not). I have a feeling dual-GPU rendering is the same for the game (e.g. still single threaded or not as it would be for single-GPU) and the dual part comes into play in the actual rendering part only, although I don't know much about dual-GPU rendering.

#4 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,308
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 05 November 2018 - 01:19 PM

Is there a pre-requisite to the alt-f12 keystroke? My log didn't include anything different from other times.


Shame about not being able to detect track and roads... I suspect in many places they are the leading cost in reducing fps. I suppose instancing would help a lot there.

Oh, BTW, speaking of instancing do you recall that problem I reported a couple years back about jumping rip rap? Couldn't tell if it was due to too many shapes or something else. I made 5 additional copies of each rip rap shape, appending a unique letter to make each unique. I then hand edited all 1100 file names in multiple world files to go from one unique name to 6 per unique shape file. Problem solved. In total the same number of placed shapes are present but the load per act of instancing is now 1/6th what it was before. 6X the draw calls per original shape file but at least the damn rocks are inert.

#5 User is offline   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,488
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 06 November 2018 - 12:17 PM

View PostGenma Saotome, on 05 November 2018 - 01:19 PM, said:

Is there a pre-requisite to the alt-f12 keystroke? My log didn't include anything different from other times.

No, if the key is pressed when it starts rendering, you get the extra log entry. You will need to hold it down for long enough for a frame to start rendering (e.g. 1/10th of a second at 10 FPS) but that's the only requirement.

View PostGenma Saotome, on 05 November 2018 - 01:19 PM, said:

Shame about not being able to detect track and roads... I suspect in many places they are the leading cost in reducing fps. I suppose instancing would help a lot there.

Yes, instancing will help with any static shapes including roads and tracks.

View PostGenma Saotome, on 05 November 2018 - 01:19 PM, said:

Oh, BTW, speaking of instancing do you recall that problem I reported a couple years back about jumping rip rap? Couldn't tell if it was due to too many shapes or something else. I made 5 additional copies of each rip rap shape, appending a unique letter to make each unique. I then hand edited all 1100 file names in multiple world files to go from one unique name to 6 per unique shape file. Problem solved. In total the same number of placed shapes are present but the load per act of instancing is now 1/6th what it was before. 6X the draw calls per original shape file but at least the damn rocks are inert.

Yes, I very much remember that. It was something to do with the number of shapes being instanced - they're grouped by tile IIRC and if any group is "too big" it goes a bit crazy. The problem was that I could never get to the bottom of the number - it was different for different shapes and no pattern could be found. (There almost certainly is a pattern, though.)

#6 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,308
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 06 November 2018 - 02:07 PM

View PostJames Ross, on 06 November 2018 - 12:17 PM, said:

View PostGenma Saotome, on 05 November 2018 - 01:19 PM, said:

Is there a pre-requisite to the alt-f12 keystroke? My log didn't include anything different from other times.

No, if the key is pressed when it starts rendering, you get the extra log entry. You will need to hold it down for long enough for a frame to start rendering (e.g. 1/10th of a second at 10 FPS) but that's the only requirement.


No joy. Held alt-f12 down for a couple of seconds, just to force the issue... nothing in the OR log.

You did say append to the ordinary OR log... or did I misunderstand where to look?

#7 User is offline   Lindsayts 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,849
  • Joined: 25-November 11
  • Gender:Male
  • Country:

Posted 09 November 2018 - 11:17 PM

View PostJames Ross, on 05 November 2018 - 12:50 PM, said:



Probably not; I don't think DirectX 9 itself is very amenable to multiple threads (and XNA is certainly not). I have a feeling dual-GPU rendering is the same for the game (e.g. still single threaded or not as it would be for single-GPU) and the dual part comes into play in the actual rendering part only, although I don't know much about dual-GPU rendering.


With rendering is that the current GPU's are massively parrallel and as a consequence VERY fast. The amount of data both shape and texture's to render a single scene is massive and it takes MORE than 1 cpu to get the data bandwidthe required by a single GPU. The two most common ways of getting two data streams to the GPU, One: split the data in an obvious fashion, with a train sim, a thread handling terrain and another thread handling all the objects. The second way is have one thread handling all the shapes and a second handling all the textures. Either of these methods will result in a speed up of rendering in the 50 to 80% range. For two gpu's one assumes 4 CPU's would be required, then one is running into memory bandwidth issues.

This information comes from an AMD GPU hardware developer, a year or so back. He did not specificly know what NVidia was doing but did know they were running into the same problems.

Lindsay

#8 User is offline   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,488
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 12 November 2018 - 01:29 PM

View PostGenma Saotome, on 06 November 2018 - 02:07 PM, said:

No joy. Held alt-f12 down for a couple of seconds, just to force the issue... nothing in the OR log.

You did say append to the ordinary OR log... or did I misunderstand where to look?

No, you understood fine. It's in OpenRailsLog.txt on the desktop (by default).

Things to check would be the Open Rails options, in keyboard, check Debug > Log Render Frame is assigned Alt + F12, and make sure you don't have anything like f-lock on the keyboard interfering. If in doubt, click on the item in the options to edit it, and then press Alt + F12 and see what it says. We use the same code for both so it should label what it thought you pressed. After that I'm not sure. :(

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users