LOD_RADIUS=15 but it's NOT about distance

[Guest]

 

 

Each of those tiles that are loaded have a certain number of autogen that load with them,

 

No, AutoGen is an entirely different class and not related to LOD_RADIUS and hence why the LOD_RADIUS value is in [TERRAIN] section of FSX.CFG.  This topic is NOT about OOM avoidance, it's about what LOD_RADIUS really means and it's relationship to photo scenery textures.  For example, if I have photo scenery that comes with AutoGen (like the original MSE CA), my AutoGen visibility radius will NOT be the same as my photo scenery HiRes (best MIP) visibility radius ... at least in my testing I'm not seeing any relationship between them.

 

 

 

I thought LOD_radius was changed by editing the fsx.cfg only.

 

No, if you go into the FSX configuration screens it will change this value to a max of 4.5 pending how you move the slider.

 

 

 

I also wonder if this would lead to big-time stutters if the sim is struggling to load distant terrain maps at the higher LOD settings.

 

That will depend on your hardware and how you have your system configured (DX10, AffinityMask, etc. etc.).  On my setup LOD_RADIUS 15 is smooth, 30 fps (limited in FSX) ... don't take this as a recommendation, just letting you know.

 

If anything can be pulled from the performance aspect of this testing, the hardware is clearly able to process more than is available in our 32bit address space limit of FSX.  Perhaps another justification to move to a 64bit code path (hint hint LM).

[simmerhead 885]

That will depend on your hardware and how you have your system configured (DX10, AffinityMask, etc. etc.).  On my setup LOD_RADIUS 15 is smooth, 30 fps (limited in FSX) ... don't take this as a recommendation, just letting you know.

 

That is if you run photoscenery with no autogen yes? I can't fly for very long with values of 8 and higher in "normal" scenery with lots of autogen and AI.

[Guest]

 

 

Finally, and this was noted by Boez, Rob's first set of images showed no visible change on autogen features. I had always thought LOD was related to autogen "popping", but apparently not.

 

Those city buildings you see are NOT AutoGen class objects.  AutoGen "popping" is an unfortunate part of FSX (you can mitigate it somewhat via FSX.CFG settings, but never completely remove it) ... I believe P3D V2.0 has "solved" that problem.  But you are correct, AutoGen is not related to LOD_RADIUS.

[Bert Pieke 7,585]

I believe that the differences you see with photoscenery are indeed due to the way photoscenery bgl files are constructed, vs traditional FSX scenery which comes with autogen baked in.

 

You would have to figure out what resolution levels are contained within the scenery files to equate the two..

 

The key variables that I see in the explanations are distance and mip levels.

[Guest]

 

 

That is if you run photoscenery with no autogen yes?

 

In my case I have AutoGen=5, but the photoscenery has no associated AutoGen.  So yes.  However, you lead me to another observation regarding LOD_RADIUS ... if I run LOD_RADIUS=15 and Map to the same coordinates (which is what I was doing in my testing) and do nothing -- keep the FSX paused (at the same viewpoint and do nothing at all) -- after about 10-15 minutes it will OOM.

 

This has me puzzled and I'm going to guess it's some type of memory allocation bug inherent in FSX ... but I honestly don't know.  In theory, when paused and all the tiles are loaded with appropriate MIPS, I shouldn't really be using any more memory, yet it gets consumed if I wait long enough (remember FSX is paused).  And this seems to ONLY happen with LOD_RADIUS values above 6.5.  Since the simulation is paused, I don't think it has anything to do with available contiguous memory.

[boez 85]

I'm more than happy to make the bitmap files available so that you can try out your own LOD tests (but collectively they may be too big for the avsim library?). I'll check thier size later. Of course all the usual warnings about backing up the terrain texture folder, at own risk etc. would apply. You'd just need to start a flight in spring time as they are the only ones I did and you'd have to unload any texture enhancement packages as these are replacement for the default ones.

 

Also its a really, really bizzare experince flying over the ringed terrain, a bit of a 'trip' you might say! However, on a serious side it explains why we see the terrain tiles 'pop' into view as you fly as its clearly seen as a new ring or mipmap being drawn, i.e. the concentric circles reorganising themselves. It really happens very late or close up to the viewpoint. It also shows that perhaps the ACES crew missed a trick as the LOD in front is the same as the LOD to the rear, i.e. you are in the centre and it may have been more effective to place the viewpoint toward the back of a circle looking forward.

[Noel 4,499]

 

 

If anything can be pulled from the performance aspect of this testing, the hardware is clearly able to process more than is available in our 32bit address space limit of FSX.  Perhaps another justification to move to a 64bit code path (hint hint LM).

 

Rob,

Do we have a sense of how much high LOD affects CPU processing load?  This discussion seems to imply the primary issue is VAS.   So if we had 64 bit code and set LOD to 17 or what have you, what sort of impact would that have on FPS/CPU processing demand?  If it's primarily VAS that's at stake then conceivably we could have MUCH higher resolution textures out to a MUCH higher radius and then my 32Gb of ram might actually have something to do besides sit on the sidelines.  It's so blithering cheap nowadays (I paid $299 for 32Gb of 2400Mhz quad channel kit, and in 1991 paid $400 for 8mb of ram!!) it's sad we aren't able to take advantage of this!  I have to think loading tiles into memory is not a hugely CPU intensive process...

[Bert Pieke 7,585]

In my case I have AutoGen=5, but the photoscenery has no associated AutoGen.  So yes.  However, you lead me to another observation regarding LOD_RADIUS ... if I run LOD_RADIUS=15 and Map to the same coordinates (which is what I was doing in my testing) and do nothing -- keep the FSX paused (at the same viewpoint and do nothing at all) -- after about 10-15 minutes it will OOM.

 

This has me puzzled and I'm going to guess it's some type of memory allocation bug inherent in FSX ... but I honestly don't know.  In theory, when paused and all the tiles are loaded with appropriate MIPS, I shouldn't really be using any more memory, yet it gets consumed if I wait long enough (remember FSX is paused).  And this seems to ONLY happen with LOD_RADIUS values above 6.5.  Since the simulation is paused, I don't think it has anything to do with available contiguous memory.

 

I would not be surprised if FSX were to continue loading far away scenery with very high LOD settings, long after you see a stable picture.

 

You would have to run Procmon or such to know for sure..

[Boeing or not going 578]

To get these images I changed the mipmap of every single spring texture in my texture folder to a different solid color. Where White = full 1024x1024 mipmap down to Dark Red = 64x64(IIRC). This allowed me to accurately tell just what mipmap is loaded and how far away from plane it is loaded.

 

These pictures below are from my Top Down view during spring at EGNT. As you will see from the attached images changing the LOD slider proportionately increases the diameter of each LOD ring which means that the area of the mipmap coverage gets larger at the outer rings (square law). In fact its hard to see in the zoomed out images just what effect the slider has on the inner rings so I've attached two more at a higher zoom level.

 

The conclusion is that 1024x1024 mipmaps (White) are only visible from the cockpit for a severely limited range.

 

Here's what LOD does: slider at Small

 

 

Large:

 

 

And zooming in on the center:

 

Small:

 

 

Large:

 

 

 

Very interesting. Thank you for all this.

 

One question, what does lod slider small and large equate to in the fsx numerical entry? I am running 6.5 now after buying MSE Hawaii.

 

This is my first time using photo scenery. I am worried about using this tweak in other areas though, I bet UTX Europe with FTX Global will cause me use problems. I guess it's a photoscenery only tweak.

[Guest]

 

 

So if we had 64 bit code and set LOD to 17 or what have you, what sort of impact would that have on FPS/CPU processing demand?

 

That's difficult to answer ... there are obviously going to be limits in terms of system data thru-put but we really want the textures in the GPU as that memory is considerably faster.  Take an extreme example, on a 64bit path and say we have four Tital 6GB GPUs, we could map 24GB VRAM (which in the case of MSE Boston Ultra that's the entire city fully loaded with room to spare at the best possible MIP) ... under DX11, I don't know enough about DX9 to comment.  But I'm not sure that should be a goal either, you don't necessarily need that ... there will be a point where higher MIPs just waste space as they have no visual impact in the frame (too small too distant) ... what that point is will depend on other factors such as screen resolution.  But these are the resource limits of D3D 11 http://msdn.microsoft.com/en-us/library/windows/desktop/ff819065(v=vs.85).aspx

 

In the case of FSX, texture loading (assuming one uses AffinityMask) is done on separate threads which means FSX should continue processing (flying on the main thread) while the textures load in there own time and one shouldn't introduce stutters - at least at the scenery level anyway.  Other class objects, such as Airports, AI traffic, Buildings, etc. -- I don't "think" those run on a separate threads - again, not sure.

 

Probably should try to avoid getting into 64bit and multi-GPU support, from my perspective both of these are key to solving all the problems associated with "world" simulations.

 

Ironically XP10 doesn't utilize multi-GPUs but has a 64bit code path (see: http://developer.x-plane.com/2011/10/x-plane-sli-and-crossfire/)

 

P3D V2.1 might utilize multi-GPUs but doesn't have a 64bit code path (see: http://www.prepar3d.com/forum-5/?mingleforumaction=viewtopic&t=3372.1 - page 2 response to my question)

 

 

I would not be surprised if FSX were to continue loading far away scenery with very high LOD settings, long after you see a stable picture.

 

Possible, but in some cases I've let it sit for 30+ minutes (on pause) and it will OOM.  (keeping my DLL.XML and EXE.XML) clean.

[Noel 4,499]

 

 

In the case of FSX, texture loading (assuming one uses AffinityMask) is done on separate threads which means FSX should continue processing (flying on the main thread) while the textures load in there own time and one shouldn't introduce stutters - at least at the scenery level anyway.

 

That being the case why isn't HT supported?  What would be the correct AffinityMask value to use for an HT enabled hexacore?

[boez 85]

@Gear Up and Off

 

From memory and without checking:

 

Small is 2.5

Large is 4.5

 

 

 

 

 

 

 

[Boeing or not going 578]

@Gear Up and Off

 

From memory and without checking:

 

Small is 2.5

Large is 4.5

 

So what about numbers like the op used, or 6.5 and 9.5. Can you do tests using that? I'm trying to tweak photo scenery with very little autogen to slow down the system. I am running 9.5 now

[Guest]

 

 

I'm more than happy to make the bitmap files available so that you can try out your own LOD tests (but collectively they may be too big for the avsim library?).

 

No need, I was just curious, your work has been very helpful.

[Guest]

Noel, on 11 Oct 2013 - 12:26 PM, said:

That being the case why isn't HT supported?

How do you know it isn't?

Noel, on 11 Oct 2013 - 12:26 PM, said:

What would be the correct AffinityMask value to use for an HT enabled hexacore?

Without source code on how FSX determines an HT core -- or more likely I should say "IF" it determines an HT core -- it would be impossible to know the correct AffinityMask. I've read folks suggesting Core 0 = real, Core 1 = HT, Core 2 = real, Core 3 = HT ... etc, on down the CPU line. In routines I've coded that are threaded to a specific processor affinity, I've never made that assumption ... all I see from the OS is a (from a HexCore with HT on) is 12 processors. I still don't know how someone can determine a HT core from a actual core when it comes to assigning affinity to a thread?

To specify what threads work on the available processors, you want to use SetThreadIdealProcessor and SetThreadAffinityMask ... NOTE: it's VERY important to use the SetThreadIdealProcessor -- this basically "locks" the thread to run on a specific processor. If a developer uses just the SetThreadAffinityMask alone, the thread can and will migrate across processors (HT or real) and each time it does that will reload the processor cache which is slow (relatively speaking) ... stutters.

But to be clear, I don't know exactly how threading and the AffinityMask settings are implemented in FSX. Based on the testing I've done with the various values of the AffinityMask, I don't agree with the current thinking/belief that bitwise operations are to be added resulting in the correct selection of CPUs to run threads on.

From a coding POV, the processor cores are indistinguishable ... the best I can do is determine if hyper-threading is turned On/Off and how many Logical Processors are available (and Physical). Bare in mine that a Hexacore (like a 3960X) is reported to the OS as 1 physical processor and 12 logical processors with HT on or 6 logical processors with HT off. I think this is why some folks suggest turning HT OFF in the BIOS (I would warn against this on the newer processors from Intel, HT has been much improved and doesn't stall the CPU like it used to).

 

Rob