LOD_RADIUS=15 but it's NOT about distance

[boez 85]

Here are some more images at LOD=9.5 following requests in the thread. They are of Newcastle, Plockton and Boston (the location of Robains original pictures). I've taken some from the pilot view at height too.

 

Again note that its a law of diminishing returns in regards memory useage versus inner (here coloured white and higher detail) ring size as even at 9.5 the inner most 1024x1024 ring hardly seems to have increased compared to the overall circle and thats a lot of bitmaps to load! See Boston examples.

 

Newcastle:

 

 

 

 

 

Plockton:

 

 

 

 

Boston

 

 

 

[odourboy 1,290]

Oh My! That is a lot of tiles at a very long (and I imagine, pretty useless) distance to be loading. Boez - are you using an Nvidia GPU? I would be very interested to see if a negative LOD Bias you can access for the FSX Nvidia profile with Inspector can increase the radius of the white circle radius without expanding our entire LOD radius.

[boez 85]

That's the exact reason I originally did these tests :-)

Sadly the answer is that the rings stay exactly the same with bias=-3 all the way to +3 in NI. Everything else including the menus blur (with positive bias) but the size of the rings is unchanged.

It would have been great if they had.

Sent from my HTC One S using Tapatalk now Free
 

[Noel 4,529]

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

 

I keep a shortcut to fsx.fsg on my desktop and vary LOD & autogen density according to where I'm flying and in what aircraft.

 

Another area I've played with is a little counter intuitive and that is setting fiber_frame_fraction_time to a higher value than default (.33) to see if I can trade in frame rate for texture update rate as it were.  Jury's still out but may hold some promise.

 

 

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

 

Rob what is the logic behind that, the 14 value for your 6 core/12 thread?  Somehow I deduced 62 is the equivalent value for 6 core as 14 would be for 4 core.  

 

Also, I've forgotten exactly how fiber_frame_fraction_time functions but I recall the higher the value the more time allocated to texture loading at potentially lower frame rate, is that correct?  I know if I set it at .01 it blurry big time, but at a high value like 1.0 frame rate is still quite decent.

[boez 85]

Of course we shouldn't lose sight of the fact that mipmaps are there for a very good reason. Without them we'd be complaining of sparkly or crawling pixel effect in the distance! There'd be great detailed static screenshots but awful side effect when flying. Simulations are always a compromise :-)

 

Sent from my HTC One S using Tapatalk now Free

 

 

[odourboy 1,290]

That's the exact reason I originally did these tests :-)

 

Sadly the answer is that the rings stay exactly the same with bias=-3 all the way to +3 in NI. Everything else including the menus blur (with positive bias) but the size of the rings is unchanged.

 

It would have been great if they had.

 

Sent from my HTC One S using Tapatalk now Free

 

 

Yes, it's too bad... and supports what I thought was happening in my own testing but without the benefit of your scenery mip rings to be certain. Oh well.

[Bert Pieke 7,585]

We've come all the way around - I believe... it is exactly about distance... B)

[jabloomf1230 2,445]

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 really don't want to derail this thread, as you made very good points about LOD radius and the thread is not about affinity mask. That's really why I posted a link above to the thread that covers affinity mask in more detail. But since you brought up weather injectors and FRAPS, I feel obligated to respond just to that. Weather injectors do not consistently use CPU resources. They only add weather to the sim at regular time or distance intervals. Unless you have the interval set at an exceedingly short setting, the weather app only needs CPU time infrequently. As to FRAPS, if it used a lot of CPU resources, really what good would it be, as the app itself would reduce frame rates in FSX? BTW, the OS does know the difference between a real and HT core. It only adds additional threads to a physical core if is there is a demand to do so. In any case, whether one has HT on or off, it should make very little difference in FSX. On the other hand, LM has stated that in P3d 2.0, having more virtual cores will make a difference.

[Guest]

 

 

But since you brought up weather injectors and FRAPS, I feel obligated to respond just to that. Weather injectors do not consistently use CPU resources

 

FSGRW with Dynamic does uses some resources, especially a 160mi cloud draw distances (which is what I use).   As far as Fraps, recording at 30 fps 2560 x 1600 RGB lossess is a HUGE amount of data the system has to move -- it's not just about CPU, it's bus bandwidth.

 

 

BTW, the OS does know the difference between a real and HT core. It only adds additional threads to a physical core if is there is a demand to do so.

 

I'll need a source for this information, from a programming perspective there is nothing I know about that can determine HT vs. real.  All we can determine is a physical CPU and logical CPUs.  Logical CPUs can comprise of HT or real, the physical is just that, one CPU.  For example a 3960X with HT reports as 1 physical CPU and 12 logical CPUs -- with HT OFF a 3960X reports as 1 physical with 6 logical CPUs.  

 

So if the OS does, I'm surprised that there is nothing available to a programmer (as in guaranteed this CPU ID = HT CPU).  I'm not saying it's impossible, just saying I would be surprised.  And if it's not available to a programmer, then it's unlikely Aces would distinguish either.

 

 

 

Rob what is the logic behind that, the 14 value for your 6 core/12 thread?  Somehow I deduced 62 is the equivalent value for 6 core as 14 would be for 4 core.

 

No logic, just trial and error ... I have used 62 (1364 and many other values) and also ... both work well, 62 will have a tendancy to stall texture loading (black squares) but will effective load the textures faster while in motion.  14 reduces the black squares but is slower at loading textures.  In all cases my Fiber frame is at 0.99.

 

 

Of course we shouldn't lose sight of the fact that mipmaps are there for a very good reason.

 

For a very good reason in 2006.  Not so sure about today's high end multi-GPUs.  It's a compromise process and as hardware progresses the need for compromises will be overcome (I hope).   Is this you Boez?  http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter28.html 

[boez 85]

Hmm not unless mathematics and sampling theory has changed since 2006! Downsample a large bitmap into a smaller one which must be done as the tile is used to fill in an area further away from the viewpoint and noise or aliasing (seen as crawling pixels) is inevitable. Okay anisotropic filtering can be (and is generally) used to reduce this crawling but that causes blurring which we are trying to remove. Again compromise!

 

The one true saviour will be massive screen/gfx card resolution which will end the need for antialiasing too!

 

Lol no that's nothing I've seen before but interesting!

 

Sent from my HTC One S using Tapatalk now Free

 

 

[TheFamilyMan 280]

I'll need a source for this information, from a programming perspective there is nothing I know about that can determine HT vs. real. All we can determine is a physical CPU and logical CPUs. Logical CPUs can comprise of HT or real, the physical is just that, one CPU. For example a 3960X with HT reports as 1 physical CPU and 12 logical CPUs -- with HT OFF a 3960X reports as 1 physical with 6 logical CPUs.

 

 

 

So if the OS does, I'm surprised that there is nothing available to a programmer (as in guaranteed this CPU ID = HT CPU). I'm not saying it's impossible, just saying I would be surprised. And if it's not available to a programmer, then it's unlikely Aces would distinguish either.

 

 

So what makes you an authority of what the Aces team, or for that any professional software engineer (such as myself), can or can't do/know about the computer on which their software operates?  I get so tired of reading software related stuff like this from people stating "well I think so, so believe me: that's the way it is".  So with that out of the way, here's proof that, yes, ANY windows app CAN know EXACTLY the processor resources which are available to it:

http://msdn.microsoft.com/en-us/library/ms683194

And not only that, a process can tell the OS to run its threads and subprocess on specific cores which the process identifies and the OS will comply to this 100%.  If this is not case the OS will do its best to utilize the available compute resources on your behalf, along with all the other processes executing on the system, and it does all this quite well. BTW I professionally develop, for the aerospace industry, realtime multi-threaded, multi-process applications executing on multicore computers, and have used this sort of stuff in software I've written so I do consider myself an actual authority on this subject.

 

As for FSX and HT, this is my take on its behavior.  I admit it's 100% speculation, but speculation based on what I can see in the execution behavior of FSX.  So here it is:  When no affinity mask is specified, FSX will query the OS about what CPU (i.e. core) resources are available and then construct and launch its threads to best utilize the discovered resources for its execution.  But if an affinity mask is specified, FSX will use that mask as given and run its threads on ALL the cores specified by the mask.  Why can I assert these statements?  Consider this: the default affinity setting for any process is "all cores", which in fsx.cnfg speak is 255 for 4 core HT processor (and 1023 for a 6 core HT processor).  Yet in this default affinity state (i.e. no fsx.cng affinity setting), FSX will discover and create 1 main thread and 3 texture loader threads (5 texture theads for a 6 core processor), plus there seem to be a few minor threads outside of these "heaver lifters" which do drift onto the "virtual cores" whose compute task is considerably less than these "heavy lifters".  So if FSX is blind to knowing about HT cores, how can it successfully guess to make just enough "heavy lifter" threads to utiliize the "actual cores"?  If it really is so lame to think "well, the OS says there are 8 cores, so 4 of these must be HT cores", then why doesn't do the same with ANY environment, e.g. "I see 4 cores (say for an i7 4670), so two must be HT, so I'll only start the main thead and one texture loader".  Now moving to when affinity is specified in fsx.cfg, fsx will load each core specified with a "heavy lifter" thread, such that a setting of 255 will start one main thread and 7 texture loaders (which creates a stutter fest).  For grins, I've tried about every imaginable affinity setting, and IMO NONE were any better than what FSX does all on its own without any fsx.cfg help.  BTW, I do run HT off (at least for FSX) not because it helps smoothness, but because I get a better OC with lower temps and because running (using default affinity settings) with HT enabled is no better, nor no worse, FSX performance wise, so I go with the better OC.  Thanks for baring with me on this, your comments are appreciated.

[Noel 4,529]

 

 

BTW, I do run HT off (at least for FSX) not because it helps smoothness, but because I get a better OC with lower temps and because running (using default affinity settings) with HT enabled is no better, nor no worse, FSX performance wise, so I go with the better OC. 

 

It seems the common belief is that HT enabled means higher temps all else being equal.  This, to me, makes no sense UNLESS HT is actually increasing the processing execution involved, and unless there are huge inefficiencies in how this is accomplished in an HT enabled OS running FSX, this should equate to higher performance in FSX, yet this is not corroborated.  Why should temps be higher if no more processing is occurring?  And this is the case with my own system which shows IDENTICAL temps when HT is enabled versus not enabled.  I have a 3930K processor running at 4.4Ghz, and I have absolutely confirmed enabling HT in the BIOS enables it in Win 7.  I would think higher temps would be a very good thing because it would clearly imply more work is being done.

 

While you're here:  what sort of % CPU utilization for each core are you all seeing?  It seems like I never see anywhere near 100% in Core1 or any other.

[Boeing or not going 578]

Noel, so you have HT enabled on your 3930k?

[Guest]

 

 

Downsample a large bitmap into a smaller one which must be done as the tile is used to fill in an area further away from the viewpoint and noise or aliasing (seen as crawling pixels) is inevitable.

 

Yes, but you're assuming MIPS will always be around.  I think they eventually will go away as hardware evolves.  No AA is close to reality with 4K monitors ... just a matter of time (less than a decade is my prediction).

 

 

 

So what makes you an authority of what the Aces team, or for that any professional software engineer (such as myself), can or can't do/know about the computer on which their software operates? 

 

I'm not -- I made no such claim, I claimed I could not find a way to determine an HT vs. real.  The article you've pointed to does not return information about whether or not that processor is HT or real ... a logical processor that shares resources doesn't implicitly mean it's an HT core.  But to test I just ran that sample code thru VS and stepped thru it, I'm not seeing a positive ID on HT core?  The cache count and relationship core didn't vary, I would have expect that to change if I were able to ID an HT core?

 

 

 

I admit it's 100% speculation, but speculation based on what I can see in the execution behavior of FSX.

 

Exactly, and I've been very clear about my speculation also.  Like I said, when one sets an processor affinity to a thread you have to also identify that as the ideal affinity or else it will get moved around from processor to processor which results in a reload of the cache which is not optimal.  

 

No need to get into a credentials debate or make this personal, unnecessary ... I can list mine off also but I don't think it's relevant?  Is it?  I'm not beating a drum, just sharing my information just like everyone else.

 

 

 

For grins, I've tried about every imaginable affinity setting, and IMO NONE were any better than what FSX does all on its own without any fsx.cfg help.

 

They do make a difference on my 3960X with HT on.  I haven't tried every single possible combination nor taken the time to log data from each an every combination (probably take me a few months to do that on a 12 core and then 6 core configuration).  But your information would contradict what Phil Taylor suggests here: http://blogs.msdn.com/b/ptaylor/archive/2007/05/15/new-tweaks-in-sp1.aspx -- I can't think why Phil would publish this info if it were meaningless or useless?

 

Intel has evolved HT with each new iteration of their processors, there certainly were some less than desirable situations that could make HT ON worse.  Which unfortunately just adds mud to the HT waters.    

 

Your information (as with everyone else's) is much appreciated and is certainly cataloged appropriately.

 

Rob.

[Noel 4,529]

Noel, so you have HT enabled on your 3930k?

I've tried both and so far can't discern anything different performance-wise.  Though I see that when FSX runs Process Monitor says 67 threads are operating.