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

First of all, if you leave affinity mask out of FSX.cfg, the OS will decide which cores to let FSX (or P3d) use. All the widely hyped four core FSX.cfg Affinity Mask setting does is to prevent FSX from using Core 0, which is sort of lame these days, since the newer Windows OSes are much better at juggling the system resources. Under 32 bit XP, the OS tended to pile up threads on core 0, but Win 7 and 8 tend not to be that dumb.

 

All that has absolutely nothing to do with Hyperthreading. Let's say in your case you have 6 physical cores and therefor 12 virtual cores. Even in that case, you still are better off letting the OS manage CPU resources. Now if all 12 cores are being used (even if it is sporadically), then the 4 cores that FSX tries to use (if indeed that is a real limit) might end up being shared with some other concurrent thread that has nothing to do with FSX. What process that might be, is somewhat of a mystery, because, if you observe what else is using CPU time while FSX is running, it is a miniscule amount, unless of course you are explicitly trying to run apps in the background.

 

Even FSX weather injectors, TrackIR and your joystick/yoke use very little in the way of CPU time while FSX is running. FSX pretty much hogs everything, since it makes such poor use of your GPU. If you really want to fine tune FSX, then give TrackIR, FSX and any other add-ons that run in their own memory space, non-overlapping affinity masks. You are better off using either the alternate Windows Task manager , Process Explorer or FSXAssist to do this. You can also assign affinity masks by launching programs with the Windows Start command, which looks something like this:

C:\Windows\System32\cmd.exe /C start "FSGRW" /high /affinity FF0000 "D:\Program Files (x86)\FSGRW\FS Global Real Weather.exe"

But I digress. If in fact there are a bunch of non-FSX threads using up all 6 physical cores, with HT on the OS will start spilling over and doubling up threads on physical cores. That's great for concurrency, but obviously FSX will get less CPU time. But what sane FSX user runs a bunch of apps in the background? My advice (and also that which is in Nick's "Bible") is to let to OS worry about assigning CPU resources. Do you want to know more?

 

http://forum.avsim.net/topic/395504-affinity-mask-revisited/

Here is what the dev had to say about "LOD radius":

 

"To help organize and manage the terrain data at run time, we subdivide the surface of the Earth into cells organized into a quad tree.  To minimize scale distortion where most of our customers live and fly, we designed our quad tree so the ratio of north-south to east-west extent of the cells is nearly 1:1 at +/- 45 degrees of latitude. This was done by designating six root cells, three north of the equator and three south of it. Each root cell covers 90 degrees of latitude and 120 degrees of longitude.

 

"Explicit links between quad tree cells are only used where necessary for speed but otherwise we save on link storage and maintenance by using the cell identifiers as implicit links. This type of implicit quad tree design is sometimes called a linear quad tree.

 

"The terrain scene graph is designed for rendering with as much fidelity as possible but without having to load more data than necessary. Therefore, we only want to use the data with the highest level of detail (LOD) near the viewpoint and use progressively less detail as distance from the viewpoint increases. Small cells deep in the tree contain data with the highest LOD so we want to concentrate them near the viewpoint. The larger cells near the root of the tree hold data with low LOD so we want them to be visible from greater distances than the smaller cells. To accomplish this, we cache cells from all levels of the tree in the scene graph but we use a geometrically decreasing geographic radius as the depth of the cells increases.  Because the cache radius decreases at about the same rate as cell size, the number of cells cached in each level of the scene graph remains relatively constant at all levels.

 

"Ideally, the scene graph radius for each level of the quad tree would be determined by screen resolution, with higher resolutions requiring larger radii, but we leave the choice up to the individual user so they can find a balance between view quality and the capabilities of their machine. In practice, we allow a user-selectable radius of between 2.5 and 4.5 cells, which seems to be a good balance between keeping the total number of cells low, while still allowing enough granularity for streaming in new content as the viewpoint moves through the world.

"To support the requirement for multiple independent views, we create a separate scene graph for each viewpoint. When the scene graphs for multiple views overlap spatially, they share as much view-independent data as possible such as textures and raw, untriangulated elevation data."

 

scott s.

.

The terrain scene graph is designed for rendering with as much fidelity as possible but without having to load more data than necessary.

 

 

Thanks for the information Scott.  This information seems to correlate to what I'm suggesting about LOD_RADIUS ... in order to not load more data than necessary there must be some calculation applied to define the "quadtree" which is exactly what we see in Boez images.  Clearly Aces were very aware of the limitations of a 32bit address space and hardware performance of the day and how to try to make best use of that.

 

For those not familiar with a quadtree: http://en.wikipedia.org/wiki/Quadtree

 

Each level down in the quadtree increase memory allocation by 4X.  I found a very good read on how D3D 11 (component of DirectX 11) that I'm gonna quote here as it pertains to quadtree design ... it's also probably why P3D (LM) are very keen to move ESP code to D3D 11.  Here is an excellent and easy to understand paper by James P Reid:

 

 

 

 

 

Rob.

 

 

But what sane FSX user runs a bunch of apps in the background? My advice (and also that which is in Nick's "Bible") is to let to OS worry about assigning CPU resources.

 

I do, specifically Fraps and a weather engine.  AffinityMask value does make a difference to FSX - my point about AffinityMask is that from a coding perspective there is no way to determine a HT processor vs. a "real" processor.  

 

I know a lot folks keep quoting Nick, I don't know Nick personally but from what I've read of his "bible" ... it's just that.  I'm not seeing any concrete demonstration of a scientific method being applied?  Nor does Nick have access to the source code.  Maybe I missed something?  It just seems odd that someone who doesn't have access to the source code and isn't a programmer and didn't work for Aces, is telling everyone "how it works"?  Doesn't that seem odd to you?

 

Rob

I do, specifically Fraps and a weather engine.  AffinityMask value does make a difference to FSX - my point about AffinityMask is that from a coding perspective there is no way to determine a HT processor vs. a "real" processor.  

 

I know a lot folks keep quoting Nick, I don't know Nick personally but from what I've read of his "bible" ... it's just that.  I'm not seeing any concrete demonstration of a scientific method being applied?  Nor does Nick have access to the source code.  Maybe I missed something?  It just seems odd that someone who doesn't have access to the source code and isn't a programmer and didn't work for Aces, is telling everyone "how it works"?  Doesn't that seem odd to you?

 

Rob

 

No more or less odd than all the other people who are quoted that didn't write the original FSX code either

 

Let's face it, there's more voodoo to FSX than any other game I know of. Miracle tweaks, tuning tools and what not. Very few do the math so to speak.

 

This thread has been an interesting read, although I'm still in the mist

No more or less odd than all the other people who are quoted that didn't write the original FSX code either

 

It was a team of developers that maintain the FS series code that changed over the years.  

 

Boez work was/is impressive, that's real demonstration of the scientific method being applied.  Scott's quote from "the dev" about quadtree makes A LOT of sense ... how Scott got that information I have no idea, I don't know Scott personally either and I don't know "the dev" he quoted.  But given that the information makes sense and isn't based on Voodoo, but real established (1974 was when Quadtree method came about) programming techniques, I'll certainly catalog that information accordingly.

 

No Voodoo in FSX ... it's the assumptions made that has given FSX a voodoo like quality.  Computers can only arrange states of On/Off (at least today's computers anyway).  Hopefully people understand context from which they get information.  I've done my fair share of trail and error testing with results that don't make sense ... but hopefully I'm clear when I present those results ... i have no desire to be a bible

 

It's all in the method and presentation of information.

 

Rob

There's a lot of info out there for those who bother to google it I've got a pretty large collection of white papers and blog posts about the FS tech dating back to the FS9 days. I just can't make sense of most of it since I haven't written any code since the early 1990s (higly irrelevant turbo pascal coding).

 

Boez illustrations do make some things pretty clear though, so I'm in complete agreement with you: Impressive work!

 

As for the voodoo comment, it was a general statement, not aimed at info in this thread, although you hitting the pause key and being cursed by an OOM was pretty fitting in that respect .

A   H U G E   T H A N K S  to all those taking part in this thread.  Not only has it been enormously informative, but its also *mostly* written in a way that us mere mortals can partially understand :lol:

It's all in the method and presentation of information.

Rob

It sure is. Brilliant work, observations and presentations.

 

What all the work above has proved to me, is how darned good FSX is, considering what the original dev's had to work with.

 

 

Boez work was/is impressive, that's real demonstration of the scientific method being applied.  Scott's quote from "the dev" about quadtree makes A LOT of sense ... how Scott got that information I have no idea, I don't know Scott personally either and I don't know "the dev" he quoted.  But given that the information makes sense and isn't based on Voodoo, but real established (1974 was when Quadtree method came about) programming techniques, I'll certainly catalog that information accordingly.

 

The info is from Adam Szofran who created the terrain system.  It is in a paper he presented at GDC 2006 entitled "Global Terrain Technology for Flight Simulation".  It used to available from fsinsider but no idea where you can get it these days.

 

I think there is a lot of carry over from fs9.  A German user/site wrote what might be called a book on how fs9 terrain works entitled "Terrain Dokumentation für Flight Simulator 2004".  This was based on extensive testing.  It is available here:  http://www.germany-vfr.de/Jobia/lcdokupdf/lcdokupdf.zip

 

scott s.

.

This all sounds great but... so what should I set my radius to? After reading it all I am still confused.

It's still there: http://www.microsoft.com/Products/Games/FSInsider/developers/Pages/GlobalTerrain.aspx

This all sounds great but... so what should I set my radius to? After reading it all I am still confused.

It's just another variable you can play with.  It implies a maximum amount of texture pixel density/resolution [may not be technically correct but sufficient to make the point] which, because density varies in different areas, the radius will vary.  When you set LOD to 4.5 for example, you will get X amount of pixel density and therefore the perimeter will vary from moment to moment as you move thru the simulated environment according to some scheme.  The LOD value, or texture pixel density will remain the same, unless you change the variable.  As one person said above, when you go up a notch in LOD, say from 4.5 to 5.5 you will likely need to reduce autogen a notch to compensate.  Also, LOD value is known to increase VAS use such that risk for OOM errors goes up.  It's not so clear though exactly what the, for example, frame rate impact is.  Or effects no smoothness.

It's just another variable you can play with.  It implies a maximum amount of texture pixel density/resolution [may not be technically correct but sufficient to make the point] which, because density varies in different areas, the radius will vary.  When you set LOD to 4.5 for example, you will get X amount of pixel density and therefore the perimeter will vary from moment to moment as you move thru the simulated environment according to some scheme.  The LOD value, or texture pixel density will remain the same, unless you change the variable.  As one person said above, when you go up a notch in LOD, say from 4.5 to 5.5 you will likely need to reduce autogen a notch to compensate.  Also, LOD value is known to increase VAS use such that risk for OOM errors goes up.  It's not so clear though exactly what the, for example, frame rate impact is.  Or effects no smoothness.

 

Thanks, that makes sense. I will keep adjusting until I get it perfect, 9.5 with affinity mask seems to work best for me, my x64 win7 doesn't know how to properly manage cores. Massive blurries unless I run affinity of 62 for my core 6. Of course since I'm running megascenery right now, and no autogen, 9.5 isn't too much of a problem.

This all sounds great but... so what should I set my radius to?

 

If you're in the middle of the pacific ocean, set it to 30

 

I suppose technically, someone (and or group of developers) could code an application that would take into account your flight plan, weather, add-ons, aircraft, textures, terrain mesh, and formulate an optimal LOD_RADIUS.

 

Sorry, but there is no magic "optimal" setting ... if you want to be relatively "safe" don't exceed 4.5 assuming your are setup with 4GB VAS limit and not 3GB.  I typically setup a FSX.CFG (and EXE.XML and DLL.XML) for each Aircraft I own allowing for FSDT type airports and worst case weather ... for example all my RealAir Duke's I'll run LOD_RADIUS 9.5, PMDG 777 = 6.5, PA38 or any Default FSX Aircraft = 11.0.

 

 

It's not so clear though exactly what the, for example, frame rate impact is.  Or effects no smoothness.

 

I was just flying around Scotland Oban with Horizon scenery with FSGRW in PA38 at LOD_RADIUS 11 -- I limited to 30 fps, stayed at 30 fps and was very smooth, even in a 140 mph dive and runway flyby (DX10).

 

 

Massive blurries unless I run affinity of 62 for my core 6

 

I'm running 14 on my 6 core (3960X) with HT enabled.