but its also *mostly* written in a way that us mere mortals can partially understand  :lol:

 

Really???.... :lol:  :lol:  :lol:

 

Dave

I tried adding and adjusting the mipbias parameter in the cfg file and it appears to have no effect on the size of the rings. Actually it appeared to have no effect at all in so much as it didn't blur the menus in the same way as adjusting lod in NI does (i.e. when lod is set at extreme positive values).

 

This is not a tweak I've ever used so I cannot comment further on its general effect or whether it's a placebo.

Here are images I did from testing MipBias and LOD_RADIUS - make your own conclusions.

 

LOD 15 - 10,000 ft - MipBias entry removed from FSX.CFG

http://www.robainscough.com/images/065b77538b59b7b78eea0c44de0e4b87.jpg

 

LOD 15 - 10,000 ft - MipBias=6

http://www.robainscough.com/images/4be8eb6cbd8a5f1ddb1cdce6d56ae861.jpg

 

LOD 15 - 10,000 ft - MipBias=10

http://www.robainscough.com/images/a119343c09664e326773276e09cb3e9f.jpg

 

LOD 4.5 - 10,000 ft - Boston Ultra

http://www.robainscough.com/images/20c3b16ad563b0512a9ccf00fede0ecc.jpg

 

LOD 4.5 - 10,000 ft - Boston 

http://www.robainscough.com/images/247811d512210b1f49e380d3a47af8a9.jpg

 

As always, do not use Windows OS Preview (if you download images to local HD) to view these images, and be aware that different Browsers will present the images differently.  Source is 2560 x 1600 Max quality JPEG (file size is large to expect slow loading).

 

Rob.

Please explain the rational for this conclusion of yours:

 

But your information would contradict what Phil Taylor suggests here: http://blogs.msdn.co...aks-in-sp1.aspx -- I can't think why Phil would publish this info if it were meaningless or useless?

 

So why does my statement here (or any other part of my original post):

 

 

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.

 

contradict your linked Phil Taylor's blog post (reprinted here):

 

In fsx.cfg

 

---
 

There is a tweak to control scheduling of threads on cores.

 

It is not recommended to change these settings unless you have a performance reduction and/or maxed out CPU loads in the PerfMonitor. The tweak is

Edit:Fixed a typo here
 [JOBSCHEDULER]
AffinityMask=n
where
 n      num of cores scheduled
1  = 1 core           0001
3  = 2 cores         0011
7  = 3 cores         0111
15= 4 cores         1111

 

----

(snipped since nothing beyond this speaks to affinity settings)

 

There is additional code to reduce blurries. If you get random texture tiles that appear in a solid color this may help.

 

In some cases, the textures generated from this code can get throttled and will be timed out.  The time out config value is

[TERRAIN]

 

If anything, I see nothing but complete compliance between my statement and Phil Taylor's post.

 

As for the info on programatically discovering HT info, I failed to link extended version of the call, which does provide this info; these calls are nothing more than a front end for the CPUID assembly instruction.

Seems pretty conclusive to me - MipBias doesn't do diddly poo.

And straight from the horses mouth regarding Hyper Threading:

 

There is no need to disable HT, we detect physical vs logical cores and do the right thing.

 

- Phil Taylor

 

http://blogs.msdn.com/b/ptaylor/archive/2007/04/14/fsx-sp1-beta2-posted.aspx

 

I think you miss understand, or Phil made a mistake (it happens).  Logical cores comprise of both HT and real cores.  A physical core is the actual physical CPU.  For example a single 3960X CPU = 1 Physical CPU and 12 Logical cores (with HT enabled) OR 3960X = 1 Physical CPU and 6 cores (with HT disabled).

I think you miss understand, or Phil made a mistake (it happens).  Logical cores comprise of both HT and real cores.  A physical core is the actual physical CPU.  For example a single 3960X CPU = 1 Physical CPU and 12 Logical cores (with HT enabled) OR 3960X = 1 Physical CPU and 6 cores (with HT disabled).

 

Now THIS is really DENSE: it's you that does not understand. Since Phil Taylor doesn't agree with what your are saying, he's now WRONG and you are right?  And you jumped a crucial point in this reply which you've cleverly word smithed to your advantage, and this is how it really goes:

 

A 4770k package (as you say a CPU) has 4 physical cores and 8 logical cores.  This is exactly what Mr. Taylor is talking about!  If you don't agree with this, I'll dig this info straight out of the "genuine intel" technical documentation and post it here with a link.

 

 

As for the info on programatically discovering HT info, I failed to link extended version of the call, which does provide this info; these calls are nothing more than a front end for the CPUID assembly instruction.

 

I'll take a look to see if I can find what you're talking about ... but to be clear, I never said it was impossible to determine, I said I've NOT discovered a method to determine HT vs. real.  The code snippet you linked to (originally) didn't do it for me either ... so I'll keep digging.  The real reason this issue is so important me is that I'm working on a project (nothing to do with FSX) in which I do need to be able to distinguish an HT vs. real core (it's a nightly process that I'm running on our servers that needs to scale and distribute threads appropriately avoiding HT cores and aiming at real cores first ... our servers have anywhere from 32-64 cores (real).  We can turn HT off, but we've found that's a bad idea as it impacts other areas of the OS and services running.

 

So if I seem overly interested it goes beyond FSX.

 

Cheers, Rob.

I think you miss understand, or Phil made a mistake (it happens).  Logical cores comprise of both HT and real cores.  A physical core is the actual physical CPU.  For example a single 3960X CPU = 1 Physical CPU and 12 Logical cores (with HT enabled) OR 3960X = 1 Physical CPU and 6 cores (with HT disabled).

 

 

That might very well be (me misunderstanding - happens quite often ), but in response to you saying "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".  

 

As for Phil's response, he either had it wrong - not impossible - or he actually knows that FSX code can separate bewteen a logical core and a physical core. Sounds strange, but that's what he said, and as of this time I've found no offical source claiming otherwise. The only guys who might know this is the P3D team.

 

As for the AffinityMask tweak I've never tried it. My FSX runs OK, and I don't tweak unless I have to. FSX might be retired soon anyway - if Saitek peripherals and TrackIR can be made to work in P3D 2.0.

Now THIS is really DENSE: it's you that does not understand.

 

Enlighten me with some code ... like I said, I entered the sample you linked to before and it came out exactly as I've listed.

 

 

I'll dig this info straight out of the "genuine intel" technical documentation and post it here with a link.

 

I'd rather you just post the code that demonstrates your conviction.  What documentation says vs. what actually happens with code are not always the same or "as expected" -- I'm sure you know that being a developer?

I couldn't find anything on Intel's website on how to detect hyper-threading on a specific logical processor. There's a bit returned in one of the registers for the CPUID instruction which returns the hyper-threading "capability" of the entire processor, but I couldn't find anything for querying an individual logical core. To my understanding, the processors (virtual or otherwise) are exposed opaquely from the BIOS to the OS as logical processing units. From a design standpoint, it would seem like an OS would want to be agnostic about internal differences of the silicon (i.e. Intel vs AMD vs ARM). Hyper-threading is an Intel architecture device.

 

Anyway, I don't want to step into the middle of anyone's pissing contest here, but I seem to recall reading somewhere that the processors are enumerated in alternating fashion as CPUn and CPUn' (where n is the core # and prime denotes a HT core). I don't know if this is an Intel BIOS standard, a convention, or just rubbish that was handed down through the blog-o-spheres. But it seems to be borne out by the evidence - an affinity mask of 84(01010100) (cores 2, 4, 6 on my HT quad) yields notably marked improved performance (vs 14 (00001110) or 255 (11111111)). I have not yet tried 168(10101000) (cores 3, 5, 7) but I might try it just for giggles. In either case, I can't say definitively which cores are hyper-threaded. My guess is that the performance win has more to do with distributing the texture processing evenly across multiple - but fewer - cores (excluding the primary one which windows uses heavily) for better caching performance and less resource contention. In the domain of parallel programming, less is oftentimes more.

 

Interesting stuff.

 

J

 

 

From a design standpoint, it would seem like an OS would want to be agnostic about internal differences of the silicon (i.e. Intel vs AMD vs ARM). Hyper-threading is an Intel architecture device.

 

That's my understanding also.

 

 

 

Anyway, I don't want to step into the middle of anyone's pissing contest here

 

Unfortunate that this communication with Rod diverged in such away, but for the record I have not participated in the name calling "DENSE" (I believe was Rod's verbage) as that's just not an effective process of communication.  I still hope Rod will provide a code sample that proves his understanding (and yes for my own work related benefit).

 

 

 

My guess is that the performance win has more to do with distributing the texturing evenly across multiple cores (excluding the primary one which windows uses heavily) for better caching performance and less resource contention.

 

Could very well be the case, but as I understand it, the thread's affinity needs to also be set to "ideal" or else the thread can migrate across cores (HT or real) which forces a CPU cache reload which introduces a less than optimal performance scenario.  This "might" explain why the AffinityMask may not always be a benefit on some systems vs. others ... again, speculation.

 

Rob

Enlighten me with some code ... like I said, I entered the sample you linked to before and it came out exactly as I've listed.

 

Well, you're the one who gets paid for this, so chew a bit on this:

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

 

GetLogicalProcessorInformationEx( RelationProcessorCore, ... );

 

To learn more RTFM.

 

BTW, I still can't believe you question the technical intrigity of Phil Taylor in regards to FSX.  Amazingly brash, and now your reputation has now been firmly established.  Also CPUID will yield your desired info though its returned cache info (weird but true); again the road to wisdom starts when you RTFM.  So I now am done with this thread...enjoy.

BTW, I still can't believe you question the technical intrigity of Phil Taylor in regards to FSX. Amazingly brash, and now your reputation has now been firmly established.

 

I didn't realize I was establishing a reputation ... I've done my best to keep this civil, you however seem to be on a mission?  Humans make mistakes, yes even Project Managers and developers - I believe we're all human here.  

 

But that function you linked is named "GetLogicalProcessorInformationEx" ... enumerates thru the results of "Logical" Processors, the Ex provides information about each "Logical Processor" which once again can be an HT core or a real core. 

 

But anyway, beside that ... perhaps you need to read the part in the usage of this method that you linked to -- not sure how Aces could have used this approach give Windows 7 wasn't around when FSX shipped.  Also, note the comments ... low level calls like this often produce inconsistent behavior across hardware.

 

 

 

I'm not sure where all the "RTFM" stuff is coming from ... really no need for all the emotional content.

 

Rob

I'm going to try and render an impartial verdict This is about as definitive of a reference as I could find on this API:

 

http://msdn.microsoft.com/en-us/library/windows/desktop/ms683194%28v=vs.85%29.aspx

 

I could find nothing in the Win32 documentation which allows you to identify if a logical processor is hyper-threaded or not - only if they exist or or do not exist. In fact, the code sample above simply counts the bits in the processor mask (see SYSTEM_LOGICAL_PROCESSOR_INFORMATION block) to determine the number of logical processors per core - it does nothing to determine which is which. The processor mask bits seem to support my earlier observation that real cores and their hyper-threaded counterparts are grouped together and alternate (i.e. 0,1 share a core, 2,3 share a core, and so on...), but again this is likely by convention. The BIOS or chipset most likely enumerates them in this order when presenting them to the OS. I can't find any evidence to support the claim that Windows actively detects what's a "real" core and what isn't (and I still *really* like and respect Phil Taylor!).

 

Hate to see this thread devolving into a mud-slinging contest. This is one of the better technical threads on FSX performance in a while.