f5 display and the rendering thread data
#1
Posted 02 November 2018 - 10:08 AM
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
Posted 04 November 2018 - 08:59 PM
#3
Posted 05 November 2018 - 12:50 PM
Genma Saotome, on 02 November 2018 - 10:08 AM, said:
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 {} } }
Genma Saotome, on 02 November 2018 - 10:08 AM, said:
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.
Genma Saotome, on 02 November 2018 - 10:08 AM, 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.
#4
Posted 05 November 2018 - 01:19 PM
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
Posted 06 November 2018 - 12:17 PM
Genma Saotome, on 05 November 2018 - 01:19 PM, said:
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.
Genma Saotome, on 05 November 2018 - 01:19 PM, said:
Yes, instancing will help with any static shapes including roads and tracks.
Genma Saotome, on 05 November 2018 - 01:19 PM, said:
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
Posted 06 November 2018 - 02:07 PM
James Ross, on 06 November 2018 - 12:17 PM, said:
Genma Saotome, on 05 November 2018 - 01:19 PM, said:
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
Posted 09 November 2018 - 11:17 PM
James 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
Posted 12 November 2018 - 01:29 PM
Genma Saotome, on 06 November 2018 - 02:07 PM, said:
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. :(