fxs.cfg tweaks

Do you believe in miracles?

Yeah I know.. I'm a nobody you don't know who I am, I'm not known in the community, so probably you won't take me seriously... but, just assume for a second, i'm right and I

know what I'm talking about would you at least give a shot at 'proof reading' it? is the idea clear, confusing? I want to make it public for 'general use' you are of course invited

to try

************************************************** *************

DISCLAIMER:

What you are about to read CAN PRODUCE UNFAVORABLE RESULTS depending on your particular setup and slider settings, so this is NOT a 'solution' to any problem, this is simply a hidden, undocumented tweak that can be applied to Flight Simulator X to obtain aproximately a 30% performance improvement.

Before I begin, a little background.. I've used this tweak personally, for more than a year, second, I have dedicated considerable time 'understanding' the tweak, its purpose, and specially the 'reasons' why there is such a 'dramatic' performance increase. So please... DO NOT TRY if you have 'issues' or problems in your current setup, only try it *IF* you are absolutely certain that you have a fairly stable setup and that you UNDERSTAND what I'm explaining in the following lines:

Lets first discuss 'how' applications, 'particularly' FSX works (I will keep it simple)When you 'fly' in FSX, each 'frame' its like a 'photo' it contains certain objects and textures that need to be 'drawn' for EACH 'photo'. When you play this 'photos' in rapid succesion, say, for example 25 'photos' per second, the perceived sensation is that you are 'moving' FPS = Frames per Second, each 'frame' is the 'photo' I'm talking about.

In FSX, the 'rendering' or 'drawing' of this objects, occurs, on a per 'frame' basis.. the higher the frames per second, the higher the number of objects that need 'drawing' This 'drawing' works by having the 'CPU' instruct your 'video card' what to 'draw' on screen. Each 'instruction' the CPU sends to the video card is 'queued' in a 'buffer' FSX, then 'determines' the 'threshold' where that buffer is 'filled' to flush all the commands to 'another' buffer, this one is called the Command 'ring' buffer.

This happens, so FSX can syncronize the CPU and the GPU in terms of instructions proccesed. If this 'buffer' the one created by the application, didn't exist, then you could 'under certain conditions' COMPLETELY CRASH FSX. The reason for this 'crash' is that FSX would have to send the intructions 'directly' to the 'Command Buffer', which is the one that the Video card reads to 'draw' the objects on screen.

If the video card is not fast enough to process the INCREDIBLY high number of 'draw calls' sent by the CPU per each frame (photo), then STALLING occurs. Stalling, means that the CPU 'writes' into the command buffer FASTER than what the video card is capable of proccesing (the command buffer its a ring) its finite it can hold 'certain' number of instructions at a given time, if the video card doesn't read it fast enough it gets overwritten and video corruption occurs (you'll know this because spikes come out from the AUTOGEN)

If you understand the above correctly, then you also must understand that 'application managed' buffers (aka BufferPools) 'cost' some CPU usage, and particularly in FSX this usage is MASSIVE! however, this is NOT a bad thing, its a 'safety' mechanism that the application uses so its almost imposible that it will 'fill' the command buffer with instructions. The 'Aplication managed' buffer, is like a 'middle man' it coordinates what goes into the command buffer and 'how' to keep things in sync so you don't batch an exessive ammount of objects for the video card to process.

So, why does Microsoft includes an 'application managed' Buffer (also called Explicit Vertex Buffers)? they did so, so ANY ONE could use FSX regardless of setup and ensure 'up to a point' that this will perform reliably indepently of hardware. So, DONT BLAME MICROSOFT!! they did the right thing and this is NOT a bug.

So, what happens when you tell FSX to 'bypass' this 'application managed' buffer and send all the 'draw' instructions DIRECTLY to the command buffer for the video card to process? (instructions are really sent to the D3D API, I'm just keeping the explanation simple for our sarcastic folks out there) well.. what happens is that FSX doesn't need the middleman anymore, what happens is that FSX doesn't need to control what to draw or when to draw it. Now, it simply pumps all the information as fast as it can to the Video Card, and by doing so you FREE a massive ammount of resources that are now allocated to your current flying session!! Now.. Do you understand why this tweak is SO powerfull, but at the same time, EXTREMELY dangerous for stability? It is because you need to have an INTIMATE knowledge of WHAT is going on in your computer!! you need to know 'exactly' how much is 'too' much for the GPU to process.. and this is, where things get interesting.

How can you be 'sure' that your video card is in TOP shape and able to process ANY and EVEYTHING you throw at it? remember... this is NOT about 'raw' power... this is about the card ability to 'process' the commands sent by the CPU, FASTER than the CPU ability to 'send' those commands.. its like a 'race' and the GPU needs to be faster! so, this holds specially true for folks using overclocked i7's @ 4.2 and DONT BELIEVE your GPU % Usage meter! it only shows USER SPACE... it doesn't tell you how much the 'kernel' (system) is using to process commands in the queue.. AND don't compare FSX to Crysis please... those are games OPTIMIZED to make full usage of hardware programable shaders! they are perfectly balanced!

well, you need to start forgeting EVERYTHING you have learned in the past 4 years.. specially things like:

(AntiAliasing) but only when it is controlled by nHancer(Anisotripic Filtering) again, ONLY if controlled by nHancervSync set to ON (this is a KILLER)Multiple Monitor setups (even clone mode)The ENBSeries mod

the above, KILL the card ability to process commands 'but not the ability to RENDER or

DRAW the objects' so if you absolutely NEED the above, you can stop reading now

So, if you want to give this tweak a try, you need to start by using the application controlled AntiaAlias and Anisotropic filters, you need to also force vSync to OFF, and make sure you are running a single monitor setup. this will ENSURE, that the card is in top shape to process commands 'as quick' as it can... specially, if using nVidia cards (ATI's dont have this problem, more on that later)

One side note: ATI's 5870 vs nVidias GTX 285 they are both EXCELENT cards... but they have completely different architectures, the ATI's have LOTS of tiny 'slow running' shader processors, the nVidias have fewer shader processors (a lot less) but they are TWICE as fast... so, how does this affects the cards ability to 'process' and 'render' draw commands?

well.. its up to you to decide: the ATI's have 1600 small processors, they are called 'shader processors' the more processors you have, the better the card ability to 'multitask' and do parallel processing so, the ATI's are FANTASTIC reading the command buffer faster than ANY card on the planet (even the new nVidias GTX 480, also called by their codename Fermi) so with an ATI you could practically have FSX nirvana if FSX were to send all draw instructions to the command buffer bypassing the BufferPools.. however, THERE IS A CATCH. Since ATI's have more shader processors, they need to run 'slower'

(they run at 700Mhz) same as the core clock. so, complex scenery, clouds, add-on aircraft will considerably LOWER your total average FPS. so, again, its up to you to decide... if you only fly default planes, and want EVERY SINGLE SLIDER MAXED out, vsync, nHancer, ENBSeries mode etc. then the ATI is for you, ITS IMPOSSIBLE TO CRASH IT! I could crash mine (I only owned it for like 2 days) no matter what I tried, but I lost 6FPS! to me thats unnaceptable.

Now.. the nVidias, particularly the GTX 285, have exactly 240 Shader processors, they run at 1476Mhz (and some can be overclocked even higher) this card, is a monster... and even though the ATI's (in raw speed) are faster, the nVidias can render 'complex' scenes much quicker (specially things that relay on shaders such as clouds, high water settings, buildings etc.), so the CPU doesn't have to wait for a particular scene to be rendered. Remember, the FASTER the card 'renders' a scene, the faster the 'frames' will be processed and the CPU will keep producing them! so, as you see, there needs to be 'BALANCE'. remember, that any complex system will be limited by the speed of the slowest running member on the system. Now, back to video card comparisons: The downside to the nVidias?? THEY SUCK at reading instructions from the command buffer fast enough, so they can be stalled by the CPU IF you are running high frame rates and using complex autogen (which is what fills the command buffer quicker, specially after SP2 where there is massive object batching per frame) so when using nVidias LIMITING your framerate to 25-30FPS and lowering autogen is paramaunt. (including the steps I have already mentioned) like vsync OFF, single monitor setup, No ENBSeries and

application controlled AA and AF. but don't worry.. The GTX 480's will change all that

they have 480 shader processors still much less than the ATI's but enough to give you Flightsim nirvana and turn FSX into a whole new ball game. So, IT IS completely possible to achieve what everyone though was a dream. FULL MAXED sliders and fluidity (I don't include car traffic) MAX 2.0 Water (which is a killer) or bloom (the other killer) but you can still have pretty descent AI traffic and easily achieve 20-25 FPS under the most demanding conceivable situation, thats quite good.

So... IF you understand the above information COMPLETELY and you are a competent guy that knows how to tweak your fsx.cfg file, then by all means, give this a go.. otherwise, don't even think about trying it, and please, don't private message me because I'll not respond. I'm providing all this information for the benefit of the community.

The tweaks that you need to add to the fsx.cfg file are:

[BufferPools]UsePools=0 // (note that PoolSize is ignored if UsePools equals 0. Use 1 if you experience crashes )When you see 'toggle' values (1 or 0) it means ON/OFF - UsePools its an ON / OFF value (1 or 0)PoolSize its a 'size' value (in bytes) If you 'DISABLE' the pools, you will get increasedperformance, AND ALSO, instability if you don't 'balance' your components and sliders apropiately, in case of instability, then simply DO use pools by changing the value of UsePools to 1 and 'adjust' PoolSize. BE CAREFUL (and forget everything you have been told about this value)it does NOT use video memory, PERIOD. it uses SYSTEM memory, because its a special type of poolcalled Explicit Vertex buffer which DOESN'T GO INTO VIDEO MEMORY unless they have A VERY SPECIFIC FLAG(and they don't) more info here: http://msdn.microsof...y/ff539490.aspx you can also do your own tests and see how 'increasing' PoolSize affects the size of the fsx.exe process proportionally.

[GRAPHICS]HIGHMEMFIX=1 // Fixes errors with texture addressing modes in WDDM1.0 and 1.1 when using a lot of video memory

The HIGHMEMFIX=1 you see above, fixes a bug in the FSX engine on how it handles texture addressing modes (Wrap,Clamp) and initial render states on single pass shaders,

http://msdn.microsoft.com/en-us/library/ff539490.aspx

it will completely prevent textures, buildings and entire cockpits from dissapearing! this

'bug' is triggered when there is a high video memory usage situation. so, enjoy this is my way of giving to a community that has given me so much over the years.

OPTIONAL[GRAPHICS]SHADER_CACHE_VERSION=1 // Increment this number EVERYTIME you change fsx.cfg (it simply rebuilds the shader cache)[DISPLAY]TextureMaxLoad=9 // Carefull. CAN induce stutters on LOW END systems! use multiples of 3 *ONLY* (3, 6, 9 etc) perfect for PhotoRealistic scenery and PNWThe formula on how to determine your 'optimal' TextureMaxLoad goes like this (credit to Steve Lacey here http://www.steve-lac...blurries.shtml)If UPPER_FRAMERATE_LIMIT exists, then:MAX_TEXTURE_DATA = (TEXTURE_MAX_LOAD * (TextureMaxLoad * TEXTURE_BANDWIDTH_MULTIPLIER)) / UPPER_FRAMERATE_LIMITIf UPPER_FRAMERATE_LIMIT doesn't exist (UNLIMITED FRAMES) then:MAX_TEXTURE_DATA = TextureMaxLoad * TEXTURE_MAX_LOADAs you can see above, TEXTURE_BANDWIDTH_MULTIPLIER its just that, a multiplier. Evidently, changing it DOES change things, however,when running UNLIMITED frames, it is USELESS, so you are better of playing with TextureMaxLoad directly. be VERY CAREFULL, the 'resulting'value of this formula (MAX_TEXTURE_DATA) corresponds to the MAXIMUM number of bytes the TEXTURE MANAGER is allowed to 'upload' perframe. If the resulting value (in bytes) for MAX_TEXTURE_DATA is TOO HIGH you will spike your GPU! (and cause a stutter), so this is a 'test and see' value. Ideally, you'll see an impact on COMPLEX high resolution textures sceneries like PNW and/or PhotoReal scenery. It is important to mention that THIS value does NOT have an impact on CPU if you are running a Multiple core setup, due to the texture manager threads running in the cores responsible for texture loading and object batching. (which are the last 3 if you have 4 cores)Now, the following requires a careful explanation... please, READ. This 'assumes', you have an i7 With Hyperthreading OFF.. so, it goes like this;CORE0 CORE1 CORE2 CORE3CORE0 is responsible for: Fibers and main schedulerCORE1, CORE2 and CORE3 are responsible for the Texture Manager AND Object Batching (Autogen)'Fibers' are like small processes that do 'things' cooperatively with other 'processeses' (sorry, I know this is not I high tech explanation)I'm just trying to cater for everyone. In FSX. Fibers are responsible for the 'loading' of the terrain system. They need to communicate with themain scheduler (which also RUNS on CORE0) to 'coordinate' and cooperatively multitask on terrain rendering every time a 'frame' is rendered.Those two, the fibers AND the main scheduler are running on the SAME CORE... now, here's a trick. Fibers are STUCK to CORE0, you can not move themout of there, however, YOU CAN move the main scheduler to run on another core!! so, if you do this:[JOBSCHEDULER]AffinityMask=14you are telling FSX to use only CORE1, CORE2 and CORE3.. so, what about CORE0? it STILL runs the FIBERS! because they are not bound to the AffinityMasksetting. so, what you are doing is making things now much more efficent. So now, FSX will run like this:CORE0 CORE1 CORE2 CORE3CORE0 is responsible for: FibersCORE1 is responsible for: main schedulerCORE2 and CORE3 are responsible for the Texture Manager AND Object Batching (Autogen)thats great balance! (and a little increase in performance too!) thats why so many people say FIBER_FRAME_TIME_FRACTION affects their performancewhen they lower it! of course it does, we'll talk about that now :)Now, lets micro manage the 'fibers' and the terrain loading system. Consider this:[MAIN]FIBER_FRAME_TIME_FRACTION=0.25the above value means that 0.25 (which means 25%) percentage! is the % ammount of 'time' that the 'fibers' will 'cooperate' with the main schedulerto 'render' the terrain system. So, assume you run you sim LOCKED to 25 FPS... thats 25 Frames EACH second, correct? 1 second is the same as1000 miliseconds. So, if you divide 1000 miliseconds / 25 frames what do you have? you have Miliseconds PER frame. That number is 40 Milisecond.so, now we KNOW that EACH frame,

http://www.steve-lacey.com/blogarchives/2005/11/the_blurries.shtml)

http://www.steve-lacey.com/blogarchives/2005/11/the_blurries.shtml)

takes aproximately 40 Miliseconds to render (if running frames locked at 25). Now, out of those 40 millisecondsPER frame, HOW MUCH time (or % of time) you want the fiber to cooperatively multitask with the main scheduler? well.. if you read re-read and analyzewhat Adam told Phil Taylor you'll see Adam hinted Taylor on 'what' the 'optimal' time is to do just that, Adam 'optimal' value required for the fiberto communicate with the thread is 10ms read here: (thats why they came up with the 0.33)http://blogs.msdn.co...-week-or-2.aspxSo, that value should be adjusted according to your frame rate. Of course, it REALLY doesn't have any IMPACT whatsoever UNLESS you are running a SINGLE core machine (so you can not offload the scheduler) or you run tileproxy or something VERY heavy. For cases like tile proxy or VERY complex terrain I assume 10ms is simply not enough so you need to give the fiber MORE TIMEotherwise, the blurries are going to be TERRIBLE!And talking about blurries, terrain and fiber time... :) we have: [TERRAIN]SWAP_WAIT_TIMEOUT=30 This variable is the number of frames that the terrain engine will wait for terrain textures to be loaded into video memory before forcing new tiles of terrain triangles to be rendered. This is because terrain triangles are bound to a specific texture resolution by the texture coordinates contained in each vertex. When the terrain engine wants to increase the texture resolution on a tile of terrain, for example when you fly closer to the tile, the texture coordinates must be updated to reference the higher resolution texture. However, the new tile can't be rendered successfully unless the new texture is available in video memory. The terrain engine will wait for some number of frames determined by SWAP_WAIT_TIMEOUT for the new texture to be loaded into video memory. If after SWAP_WAIT_TIMEOUT frames the texture still isn't available, the terrain engine starts using the new triangles anyway. This usually results in a tile of terrain that is either missing or textured strangely/incorrectly for a few frames until the texture finally shows up in video memory.(A warm thanks to Adam Szofran, a Microsoft ACES team member and well known community member for his clear definition :-))Now... lets talk about 'frame locking'You need to understand the following:When you 'fly' in FSX, each 'frame' its like a 'photo' it contains certain objects and textures that need to be 'drawn' for EACH 'photo'. When you play this 'photos' in rapid succesion, say, for example 25 'photos' per second, the perceived sensation is that you are 'moving' at 25 frames per second. FPS = Frames per Second, each 'frame' is the 'photo' I'm talking about.So, the above is VERY important to take into account, because in FSX, all operations! terrain rendering, object batching etc occur at the single 'frame' level... what does that mean to you? I means, the HIGHER the frames, the MORE work FSX needs to do.. so, say for example, that you run your SIM at 30 FPS and you like it.. but, then someone got into your head the idea that if its not 60 FPS then it is NOT real, well.. from 30 to 60 FSX will DOUBLE the ammount of things that it needs to do! so, don't be surprised when you start seening a christmas tree and strange spikes coming from the ground :).. I won't get into the 'FPS eye perceived thing' that has plaged our forums since day 1. run the sim at the FPS you like! I personally, got USED to run at 25, and let me tell you its perfectly fine to me.. because I got USED TO IT.. I hated it, but after a week, you simply 'adjust' your eyes to it.So, should you use the FPS limiter or run to UNLIMITED? well it depends on your flying style... if you run default planes or non CPU intensive planes or only 2-D cockpits, then your CPU is NOT going to be overworked.. in that case, simply go for the frame lock inside FSX.. period.Now, if you fly COMPLEX a/c specially using the VC you NEED to set it to unlimited! however... there is a problem ;) what happens with what I just told you about the sim working HARDER the higher the frames? what happens if frames start jumping from 30 to 60 then to 25 and again to 60? where is the 'balance' here?? what if you have UsePools=0? what do you expect will happen when you get a 'sudden' jump to 70 FPS? CRASH! ;) besides... the 'perceived' sensation (because is not real) when frames 'jump' is a 'stutter' so you need 'smoothness' consistency... and thats were the EXTERNAL frame

http://blogs.msdn.com/ptaylor/archive/2007/06/01/fsx-tweak-of-the-week-or-2.aspx

rate limiter can help you ;) capiche?Now... use this as a REFERENCE... specially if using a HIGH SPEED CPU, and simply increase the Scenery Complexity and Autogen on at at time, and run your frames locked either in FSX or with the external limiter and setting the option to unlimited inside the sim. you want to find your 'sweet' spot, or the point where the GPU is not being overworked, I suggest, as 'reference' you use a GPU monitoring tool.. again, as reference, because what you see there is NOT 100% accurate.[attachment=16518:1.jpg][attachment=16519:2.jpg][attachment=16520:3.jpg][attachment=16521:4.jpg][attachment=16522:5.jpg]

SPECIAL THANKS:

To all the guys at Avsim, specially Ryan (from PMDG), David Roch, Stephen, Mitch, David Alexander, J van E, Jjjallen, PingPong, DJJose and all those who supported me since DAY 1, trying stuff, reporting back and being extremely supportive, despite the Party Poopers that tried to (using stupid baseless technical explanations) to discredit me. and guys... I

REALLY need a break, so don't freak out if I take a long one! (also excuse any mispellings, english is not my mother tongue)

Last edited by bojote; 07 Apr 2010 at 08:38.

What does Nick have to say?

Posted by bojote on 08 April 2010 - 02:44 AM in MS FSX Forum

FalconAF, on Apr 7 2010, 10:32 PM, said:

any "naysayers" near the Fold.

Funny.. this 'naysayers' you mention. They all seem to be the same person with different nicks

Graphics corruption in FSX - (UPDATE: possible solution found!)

Posted by bojote on 08 April 2010 - 06:59 PM in PMDG General Forum

corkyo4, on Apr 8 2010, 02:52 PM, said:

http://forum.avsim.net/forum/351-pmdg-general-forum/

http://forum.avsim.net/user/101517-bojote/

http://forum.avsim.net/topic/280688-graphics-corruption-in-fsx-update-possible-solution-found/

http://forum.avsim.net/forum/121-ms-fsx-forum/


http://forum.avsim.net/topic/281597-what-does-nick-have-to-say/

http://forum.avsim.net/index.php?app=forums&module=forums&section=findpost&pid=1747686


The only thing im not sure about is the texture max load bitIf UPPER_FRAMERATE_LIMIT exists, then:MAX_TEXTURE_DATA = (TEXTURE_MAX_LOAD * (TextureMaxLoad * TEXTURE_BANDWIDTH_MULTIPLIER)) / UPPER_FRAMERATE_LIMITIf UPPER_FRAMERATE_LIMIT doesn't exist (UNLIMITED FRAMES) then:MAX_TEXTURE_DATA = TextureMaxLoad * TEXTURE_MAX_LOADHow do we know what the max texture data can be?? i realise you can work it out. But if there is a limit, what is it?ThanksTom

the limit (MAX_TEXTURE_DATA) is measured in 'bytes' that is, BYTES of 'Textures' transfered every single frame, so, if you are running, at, say 25 Frames per second, then one frame is redered in aproximately 40 Milliseconds, correct? what is the CAP, the MAX you want to let the texture manager upload, in BYTES during that '40' milliseconds? Yes, I know its confusing.. but, if you do the Math, you'll see that the resulting values (in bytes) are between 3000 and 6000 bytes PER FRAME.When you INCREASE TextureMaxLoad you are simply letting the texture manager transfer MORE without discarding textures for a next pass, hence, making things more efficient.So, what is a good value? well.. it DEPENDS on your BUS, Video Card, CPU.. its a test and see value, start with 6, then 9.. when you see it doesn't have any more impact, then you have reach the limit. But, if you see that setting it to 9, induces a quick stutter, then you know you are transfering TOO much... so, keep it down. Every hardware, will have it's sweetspot.. mine is 9.And no, the is no 'limit' ;) 30 years from now, if you ran FSX in Ultra fast hardware, with PNW with 1mm ground textures then 9 would be too low ;) this is a value that increases proportionally to the overall size of the textures being used and hardware capabities. Thats why the 'default' is obsolete.

BufferPool tweek clarification

Posted by bojote on 08 April 2010 - 09:31 PM in MS FSX Forum

Great Ozzie, on Apr 8 2010, 05:15 PM, said:

Yes, I will try to watch Taskmgr, but thought I wouldn't really be able to see much in the way of shifting the main scheduler to another core

You can, just go to an irregular terrain area in FSX, and fly around it with the frames set to unlimited an Vsync OFF and you'll see the fiber (CPU0) and Main scheduler in action ;) and, if you want the 'real' actual CPU usage in the main scheduler, get an external frame rate limiter, and see what happens when FSX is set to unlimited, BUT, LIMITED externally to say 25, 30 .. check how the cores behave :) this is a great way to 'balance' things, so you know whats really going on. The only thing that you REALLY need to know, is that the fibers don't care about AffinityMask, they will always run on CORE0. So, thats why it is a good idea to take the main scheduler out of there! now, this cheduler runs on a SINGLE CORE, the 'rest' of the excess horse power, FSX will use it for texture



http://forum.avsim.net/topic/281599-bufferpool-tweek-clarification/


manager/terrain/batching, which, again.. just ONE CORE is more than enough, the more you have, the more (pre-batching) happens in the background and with BP=0 this might no be a good idea. It's a balancing act ;) besides.. I don't know exactly how Adam manage to handle fibers and so many threads (if you have lots of them) running, syncrozing stuff... must be a nightmare.. so, you better off not using so many cores ;) to me, the 'ideal' FSX setup should run, Fibers (Core0) Main Scheduler (Core1) and texman (core3) you don't need more than that.

I thought BP=0/HIGHMEMFIX=1 was my silver bullet


CaptKornDog, on Apr 9 2010, 01:24 AM, said:

Didn't seem to have much of an effect; my clouds look a bit different possibly (or maybe that's just power of suggestion) but still some graphics spikes and FPS hits (going from 30 FPS locked to about 4-5 when looking at a cloud) in full screen mode. Windowed mode removes the graphics spikes but doesn't get higher than 6-7 FPS.

Hmm.. those ATI's are really a problem with clouds... try to experiment reducing the sprites in [DISPLAY][DISPLAY]MaxSprites=1MaxSpriteSize=8play with those, what you are trying to do is see what affects clould performance (also make sure you are using DETAILED clouds for all this tests) ATI's are known for this problem (before the 5000 series) but probably there is a workaround.You can also (because I'm going to be now) check the display.cfg file in the fsx folder.That file, is meant to 'reduce' or disable some extended features on non-compliant cards.Check WHICH options, are common to ATI's cards. you'll see (in that file) things such as:RenderToTexture. DisableAGP, PanelAsTexure etc etc.. those, you can experiment with. they go in the [Display.YouCardHere] portion of your fsx.cfg file.Now, to bed.

I thought BP=0/HIGHMEMFIX=1 was my silver bullet


CaptKornDog, on Apr 9 2010, 10:23 AM, said:



http://forum.avsim.net/topic/281702-i-thought-bp0highmemfix1-was-my-silver-bullet/



http://forum.avsim.net/topic/281702-i-thought-bp0highmemfix1-was-my-silver-bullet/



No real difference with Sprites, should I be adjusting these numbers up or down? FPS sticks around 12 when looking at a cloud but it stutters hard, freezing for about 2 seconds.I'll have a look at the display.cfg next.

By the way, you don't need to modify the 'actual' display.cfg file!! you are just using it as reference to determine 'what' flags FSX recognize when disabling specific hardware/video features. All this 'flags' you find on the display.cfg file, will work in your fsx.cfg file, under the section that corresponds to your video card. [Display.Video Card Name] section. You'll see there things such as MipBias, FogTable, RenderToTexutre etc etc..I would play the the ones related to 'fog', remember, what you want is to 'disable' features, one by one, you want to know what the ATI is having problems with.

To Jesus aka Bojote..this is your high octane gas....


superjew887, on Apr 9 2010, 04:32 PM, said:

TEXTURE_BANDWIDTH_MULT=400 <--- I thought NickN concluded that this does nothing at 100-400 after SP2/Acceleration (or even non-single core processors...i think).

That value is part of a formula, it 'affects' the texture manager 'cap' on bytes to transfer per frame. When nick concluded that, there were probably no add ons transfering so much texture and data, such as PNW.. so, there was no way to observe any positive effects going past 100. Do, its important to understand the difference between a 'cap' and 'enforced' texture transfer

Is there a single variable for texture flashing w/ UsePools=0?


Noel, on Apr 11 2010, 10:46 AM, said:



http://forum.avsim.net/topic/281902-is-there-a-single-variable-for-texture-flashing-w-usepools0/



http://forum.avsim.net/topic/281664-to-jesus-aka-bojotethis-is-your-high-octane-gas/



Howdy,Thanks to Bejote and others FSX is virtual perfection. Fairly rarely, I'll get a single white flashed texture. Almost not worth discussing . . . but I'm wondering which particular variable might be most likely involved. If the answer is a massive overview of all variables then I'll probably leave it be, but if someone knows with any certainly where to look without a major reconfigure it would be great to hear.Thanks in advance!Noel

Hi Noel,sure.. it was discussed! ;) it was 'Water' it need to be se to HIGH 2.0 (not MAX 2.0) HIGH 2.0 double check. and check the long BP thread for the explanation... its related to shaders, two passes, CPU, draw calls etc etc..

HIGHMEMFIX


Cruachan, on Apr 12 2010, 12:30 PM, said:

Hi,Is Bojote's HIGHMEMFIX=1 tweak relevant for those, like me, who are still diehard XP 32 fans?I suspect the answer will be no as it "Fixes errors with texture addressing modes in WDDM1.0 and 1.1 when using a lot of video memory"From Wikipedia: "Windows Display Driver Model (WDDM, also WVDDM during the Vista time-frame) is the graphic driver architecture for video card drivers running Microsoft Windows versions beginning with Windows Vista."Have I just answered my own question..LOL!Mike

Mike, you are correct :)XP does not have this problems :) besides, when FSX was released there was no 'Vista' yet :) so, the MS team was 'aware' that there was something needed to 'fix' problems under WDDM. SO, you have two options... you keep flying under XP.. or, you can finally without worry make the move to Win7



dazz, on Apr 12 2010, 04:35 PM, said:






http://forum.avsim.net/topic/282006-highmemfix/



I also use poolsize=0 and the sim is stable even though my VGA is not that good (see sig).What I don't understand is that when I try to overload it by increasing AG or some settings in ATI's CCC (antialiasing, etc...) I only see FPS dropping, no crashes or graphic corruption (I'm also using HIGHMEMFIX=1)

Dario, you have an ATI ;) in the BP Conclusions thread, you'll see that I said the ATI (because of its architecture) is almost the perfect match for BP=0 (any card on the 5000 series) because of the increased shader processors and DDR5 memory they are able to read commands sent by the CPU extremely fast, so the GTX 480 will be a dream come true with BP=0 ;) I'm just waiting for newegg to get mine!

Tabs, on Apr 12 2010, 03:35 PM, said:

I think we're gonna have to see what happens with the GTX 4 series cards before this tweak really becomes stable and usable at normal FSX slider settings.

I agree... this could potencially create more problems, so unless you have ATI's (5000 series) or a Fermi, use this tweak for experimentation only and wait for users with Fermi's to report on its stability with BP=0 if you want to use FULL sliders. Currently, BP=0 will work ONLY if you sacrifice (lower) Autogen and FPS in order to make it stable.

Question for Bojote (Jesus) re: ATI 5870


Dazzlercee23, on Apr 13 2010, 04:44 PM, said:

However, I want more. I was considering an Nvidia GTX 4xx card but it seems supplies are rare. I read on another forum your comments regarding the ATI 5870, particularly regarding the performance drop with complex scenery and mdl objects. What level of performance impact are we talking?

Not much... 4-6 FPS, and ONLY under a very heavy/intesive/weather area. Now. the ATI has faster DDR5 memory AND much more shader cores, so, altough the card is not as 'fast' in terms of 'object rendering' it is EXTREMELY fast doing 'command processing'. BP=0 bypasses a software managed vertex buffer, making this 'commands' go directly to the card, so ATI's LOVE BP=0 and they will be 100% stable. Nvidias do not like BP=0 very much, unless you LOWER autogen and scenery complexity. Of course, that will change with the new nVidias ;)



http://forum.avsim.net/topic/282130-question-for-bojote-jesus-re-ati-5870/



Question for Jesus


McCrash, on Apr 13 2010, 04:38 PM, said:

I have a GTX295 which eats games but I know it's not the best for FSX because it has two GPUs (micro-stuttering).

The short answer:I'm gettting a GTX 480 and selling my GTX 285 :)The GTX 285 works really good with BP=0 HOWEVER, you need to sacrifice Autogen and scenery complexity for 100% stability.. so, it all depends on your sliders :)



Paul J, on Apr 13 2010, 07:23 PM, said:

No - in fact - I should have kept the GTX until the Fermi 480 came out, but I was just a bit too impulsive. Now, of course - I want to try the 480!!

Well.. I overclocked my 5870 (it was the Vapor-X) to like 900/xxx i don't remember the xxx for memory ;) extremely stable, great with Ultra dense autogen and unlimited frames.. impossible to crash (I could not make it crash once) but.... it gave me 4-5 less FPS than my GTX 285.So, why a Fermi? (which hopefully arrives tomorrow) well... it has FASTER memory than the GTX 285 (DDR5) it has twice the number of cores and SAME shader clock speed. so, will it increase my 'FPS' considerably?? NO!! probably not even 0.1! however, I will allow me to run Extremely Dense autogen, ENBSEries, Multimonitor, without ANY kind of stability problems.Tomorrow, I'll write a short review... so stand by :)








http://forum.avsim.net/topic/282129-question-for-jesus/




Paul J, on Apr 13 2010, 08:12 PM, said:

Bye the way, *******.... I remember somewhere you said you were going on vacation, now

that FSX is fixed.......

Tweak vacation that is ;) no monster BP=0 thread to worry about.I'm still here, doing real work to pay the bills.

HIGHMEMFIX


Cruachan, on Apr 14 2010, 11:32 AM, said:

It has been established that the "HIGHMEMFIX=1" is irrelevant on XP based systems, so I've removed it.

So far, however I do believe 'some' XP users experience a 'cream screen of death' issue.. and I'm not sure if HIGHMEMFIX will fix those. So unless we hear back from MS, the only thing it fixes so far is WDDM (Vista/Win7) and yes, MS is 'aware' of this, you'll know more about this HIGHMMEFIX issue soon ;)

FSX + BP=0 + nVidia GTX 480


Ok, the conclusions now:Will this card allow you to run BP=0 + ENBSeries, nHancer, MultiMonitor, High resolution and ALL sliders to the right? (except Bloom/Water 2.0 Max/Car traffic) the short answer:YES!! it will ;) however.. there is a catch. after 50 FPS, you'll see spikes, they don't crash the



http://forum.avsim.net/topic/282230-fsx-bp0-nvidia-gtx-480/



http://forum.avsim.net/topic/282006-highmemfix/





sim, they don't make it unstable, it will not stutter, but you'll get those spikes after 50 FPS., the ATI, not even at 100 FPS will show a single spike, so the increased shader processors in the ATI DO help in that case, particularly, with Autogen.So.. who will most benefit from a GTX 480? someone who likes BP=0, flies COMPLEX aircraft, likes MAX sliders to the right, wants HIGH IQ but is ok flying with frames locked at 25/30 FPS.If you are the kind of person who thinks that the sim looks more 'realistic' when running it at 60FPS, don't waste your money. Get the ATI. You'll get reduced FPS on complex areas with heavy weather and complex aircraft, but you can virtually fly artifact free when you go over 60 FPS.Since I had the oportunity to test all, the GTX 285, the ATI 5870, and now this GTX 480 I can tell you that for my particular flying style (frames locked at 25) and FULL SLIDERS this card is absolute bliss. fantastic. Will it get better for FSX with new drivers? I don't think so.. I will get better on the next re-spin/revision (GTX 485) were it will have MORE shader processors (512) instead of 480.so.. up to you to decide. I'll do some flying now :)



UlfB, on Apr 14 2010, 06:16 PM, said:

Hi *******,You might try these tweaks: http://www.simforums...s.asp?TID=29041to get your FSX smooth!

Sorry, and your point is? I don't understand your comment. The above tweaks are like 2 years old, however they DO mention my recent HIGHMEMFIX=1 tweak/fix, so I still fail to see what is the point you are trying to make Ulf, you want me to go read my own discoveries?As for BP=0, with NEW hardware such as the GTX 480 and the ATI 5870 it works beatifully, and it was not 'guesswork' I concluded WELL in advance this was going to be the case ;)If you don't like BP=0 simply don't use it, there is nothing wrong with that. Once you get your own GTX 480, THEN you can make an objective comment.






http://www.simforums.com/forums/forum_posts.asp?TID=29041





bojote, on Apr 14 2010, 09:34 PM, said:

A 5870 @ 900 core is not bad at all, thats how I ran the Vapor-X... but, couldn't stand that 5 FPS loss ;) it was ONLY under heavy weather conditions though. so, just keep it.So far, I'm still testing and testing :) very happy with this thing!!! I do WANT to make it crash, as an excuse to keep tweaking, but.. it seems my tweaking days are over :)

I wil try:[TERRAIN]TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=6000TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=6000IMAGE_PIXELS_FOR_AUTOGEN_POLYGONS=2048in PNW :)



bojote, on Apr 14 2010, 09:50 PM, said:

I wil try:[TERRAIN]TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=6000TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=6000IMAGE_PIXELS_FOR_AUTOGEN_POLYGONS=2048in PNW :)

It is INSANELY cool how Seattle looks, GPU load won't even go past 30... there is simply no way to crash it with BP=0. I'm using Supersampling 8x, AA Enhanced 16XQ, Aniso 16, ENBSeries, vSync ON. there's not much else I can do to overload this

TextureMaxLoad - Formula Question for Bojote


Dazzlercee23, on Apr 15 2010, 08:28 AM, said:



http://forum.avsim.net/topic/282292-texturemaxload-formula-question-for-bojote/







This results in a MAX_TEXTURE_DATA value of 589,824 bytes per frame.Other than looking for visual artifacts is there a method to determine what sort of value we should be looking for?How many bytes per frame should a decent system be able to handle?Thanks,Daz.

Hi Daz,well.. if you apply the formula to the 'default' values, you'll see that according to MS 'that' number, should be between 3000 and 6000 bytes PER frame. now, remember, this is a HARD cap, a 'top' a 'limit' it does NOT mean the textures will transfer AT that speed :) it means the texture manager will transfer UP TO 'MAX_TEXTURE_DATA' per each frame. so, how much is 'good' or enough? is very system dependant! even your HDD can be a factor here, I have set TextureMaxLoad to 15, and there is NOTHING (not even PNW) that maxes it out, and I have the same hardware you have. Using TextureMaxLoad, the CPU nor the GPU will spike or show heavy usage, so here probably the limitation is the system PCI bus or the HDD. Don't know if I answered the question :) because there is really no 'right' answer :)

Question for Jesus: Bufferpools=0 with <1GB ATI?


honanhal, on Apr 14 2010, 11:10 PM, said:

I have a 512 MB ATI HD4850 card in my laptop--is there any point in even trying the tweak, do you think, or is that way too little video memory for it to do anything but crash my computer?

Hi James,sure.. go ahead, all 4000 & 5000 ATI's are capable on handling BP=0 you need at least 512MB and, of course, sensible slider settings.

Avg. Disk Queue Length > 10 for short periods (stress testing)

http://forum.avsim.net/topic/282470-avg-disk-queue-length-10-for-short-periods-stress-testing/



http://forum.avsim.net/topic/282257-question-for-jesus-bufferpools0-with-1gb-ati/


Posted by bojote on 17 April 2010 - 12:27 PM in MOBO, RAM, CPU's & Other Hardware

Hi,I'm doing some stress tests with ORBX PNW, Extremely Dense AutoGen and:TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=6000TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=6000I can see in the performance counter that the Avg. Disk Queue Length goes over 10 for short periods of time, the disk is a 300GB velociraptor (10K RPM) I understand that the 'test' is not realistic at all, I'm just curious to see how an SSD drive manages this monster load. My CPU/GPU (specs in my sig) are under 60% during this test. Would others (specially the ones with SSD drives) care to test? this is a realistic measure to determine if your disk is a limiting factor on your install.

5870 / BP=0 - Great fps improvement by lowering to 2xAA

Posted by bojote on 17 April 2010 - 11:55 PM in Monitors, Video Cards and Drivers

Zorg_DK, on Apr 17 2010, 06:36 PM, said:

Before I ran FSX with 4xAA or 8xAA box / 16xAF. I just tried 2xAA and the framerate is MUCH better with less stutters (very often 60 fps). I guess that since the BP=0 makes FSX rely more on the GPU it makes sense that AA would have such a big impact on fps (AA don't have much impact without BP=0 for me). I'm running an i7 @ 4.2ghz, ATI 5870, 6gb ram @ 1600 mhz 6-7-6-18, Crucial C300 256gb SSD, Win 7 x64. I'm using BP=0, unlimited frames and ATI tray tools to get vsync, 1920x1200. Give it a try with no AA or AAx2 and check if you see a big fps gain (or less stutter) with BP=0.

That would be great news for ATI users indeed.... would be nice to have someone confirm it.






http://forum.avsim.net/forum/327-monitors-video-cards-and-drivers/

http://forum.avsim.net/forum/327-monitors-video-cards-and-drivers/


http://forum.avsim.net/topic/282514-5870-bp0-great-fps-improvement-by-lowering-to-2xaa/

http://forum.avsim.net/forum/326-mobo-ram-cpus-other-hardware/




SpiritFlyer, on Apr 18 2010, 09:38 PM, said:

It never rains unless it pours. My last MSI GTX 470 with Newegg got cancelled because of an inventory miscount (or something like that). I found another MSI GTX 470 on Friday with

Stephen, I feel the pain :)I downloaded the Newegg iPhone app.. thats my secret :) I purchased my GTX 480 from the CAR!!! haha :) See ya!so far, this baby is GREAT!!, I was FINALLY able to make it crash (used the TERRAIN_MAX_CELL blah blah at 6000) for both buildings and trees, in Manhattan X + FSDT KJFK... however, I reduced the LOD radius to 3.5 and saw the crash no more :)And.. this was on the 'DAY" test.. at night UTX reduces the autogen, so I won't crash. So I would say, to be on the safe side when using EXTREMELY DENSE Autogen AND Scenery to reduce LOD to 3.5 (again, this is NOT necessary) you could probably run the sim without a single crash using 4.5, the 3.5 its simply a 'safe' measure for those using BP=0 + GTX 480's AND Extremely Dense sliders ALL full 100% and full IQ, Vsync ON and ENBSeries

Texture flashing when Water < High 2.0


Hi Guys,Quick question, I know that using High 2.0 Water will get rid of texture flashes, however I really like Water 1.0 Max MUCH better (it even looks more real) So far, i managed to almost completely reduce them by using an AffinityMask of 12, so I know the problem (flashes) are either caused by thread collisions or fiber swaping, the problem is completely nailed but I need your help, understanding 'what' has helped you, in the past, get rid of this flashes. was it FIBER_FRAME_FRACTION? SWAP_WAIT_TIMEOUT? TextureBandMulti? your help is appreciated :)





http://forum.avsim.net/topic/282802-texture-flashing-when-water-high-20/





napamule, on Apr 20 2010, 02:49 PM, said:

That's not water. That a MIRROR. Water is rough and you don't see cloud reflections in a large body of water like this. The wind and/or current will not show such a mirror reflection. Get real.CBNapamule

thats my point :) and yes, I meant Water High 1.0. While flying (real flying) you NEVER ever get to see cloud reflections on the water!! (specially at altitude) probably a bush flyer.. around the PNW area, yes... great lakes, specially around the Vancouver area, which LOOK like a mirror, but high flying?



ppo, on Apr 20 2010, 05:42 PM, said:

Tests Results:I cannot reproduce your problem. Sorry.I tried all water settings in the Trike with outside/VC panning 360 deg and NO flashing water textures.Setup here:Win7Ult 64bit. FSX SP2. Using PNW for this test. CPU C2D o<c 4.0, ram 1066, Rez 1920x1200x32 60hz. video driver 197.45. AF16, AA combined 4xS, Using BP=0 (works beautifully with PNW) & Highmenfix, also max trees/buildings 600.Pierre

Excelent Pierre, thanks... in fact, as I said. since I've been using Water 2.0 HIGH I do NEVER see this flashes.. they ONLY happen when you use anything below 2.0 HIGH.So far, the ONLY way I could stop the flashes was to set autogen to none, so I'm pretty sure the problem is about threads fighting each other specially when the texture manager is preparing an autogen batch. I have a laptop here with me, with SP1 installed.. tried several times, and I did not see the problem, installed SP2 and bingo.. it was there.. no big deal, really.. It's just that I'm like the pickiest guy in the world.. a single flash kills the inmersion and I really want Water 1.0 HIGH! (the above shots are pretty, but thats not how I see water from a Cessna 172 here in Miami)









jjjallen, on Apr 20 2010, 06:34 PM, said:

The white flashes (and any texture flashing) are gone for me after the latest driver - 197.45 WHQL great driver!jja

Hmm.. interesting, unfortunately, I'm not sure I can install those with the 480



Kosta, on Apr 21 2010, 01:45 AM, said:

*******, why don't you try the setting high flyer club from REX2? I think, apart for reflections, which can be turned off by low 2.0 setting, it looks much better than these sparkling and wavy waters...Though, I did some tests yesterday, flashing reappeared with ANYTHING else than high 2.0. Which is also a bit annoying, but I'm living with it for now. Previously I was never able to get rid of it, no matter what setting. Only when I set high 2.0, was it not flashing. Also when autogen turned off, it does not flash.

Well guys, I think Kosta nailed it. Finally one I like! so I'm staying with High 2.0.. Thank you sir!


Posted by bojote on 21 April 2010 - 11:16 AM in PMDG General Forum











The common denominator, for people having success with BP=0 is stable, fast well maintained systems. So, my suggestion, to people 'tweaking' is to first make sure they have a 100% roclk stable system, THEN start adding tweaks such as BP=0Removing the bufferpools (UsePools=0) will probably offer the most dramatic performance increase you'll ever see in FSX, but it comes at a price. STABILITY... however, if your machine was rock stable, then BP=0 will be the icing on the cake (like it is for many of us already)As for people having system crashes, remember always to include the module name, when a crash occurs you get a notification window, press the more info button to see 'WHAT" module caused the crash.Cheers,



ghutcheon, on Apr 22 2010, 05:58 PM, said:

I just tried Use BP=0 in my cfg. I have a GTX 295 with 1792 MB DDR3 Memory. Stock clocked GPU. I messed around in the J41 in detailed add on scenery flying circuits for about 45 mins (inside and outside, panning around) and then in the 744x in different add on scenery also flying circuits for about the same amount of time. Both near ocean and my water setting is High 2x. Sliders for Scenery Density at Max, Auto Gen at Normal, Traffic (Traffic X) 85%, Ships Max, Cars 20%, Mesh 100% etc. Sim did not crash - I really expected it to. I would say about only 6-10% FPS increase though and liquid smooth, even in turns.

Probably your CPU is not yet stalling the GPU... BP=0 becomes more and more unstable as the CPU speed increases. Because, if the CPU is faster it will prepare and send instructions to the video card at a rate the card will not be able to handle. BP=0 shines with i7's at 4.2 AND a GTX 480 but if you are running 4.2 with a 285.. then, it might work, but you will eventually have a crash.. the GTX 480 removes that posibility considerably, but not completely! the GTX 480 has twice as many cores, but if you run LOD_RADIUS=6.5 for example, the GTX 480 may still not be enough. Personally, I've found that the most significant stability 'tweak' for BP=0 is running the LOD_RADIUS at 3.5 it's ROCK stable under ALL conditions (and I've tried them all, trust me :) )The fact is, BP=0 is probably the most significant performance tweak for FSX, but it comes at a price :) stability....

bojote's fsx.cfg file

http://forum.avsim.net/topic/283061-bojotes-fsxcfg-file/






EDITED BY ADMINJESUS LATEST (Nov 13t) FSX.CFG FILE CAN BE FOUNT HERE Since you keep asking it via PM, its best to post it I guess...

//// FSX Config File By ******* Altuve (Bojote) // Last Revision April 23, 2010// *** This file has been tweaked to run maximum performance, looks and stability// *** ONLY TO BE USED ON i7's running > 3.8Ghz and a GTX 280/480's // *** Do not change ANY value, otherwise the achieved balance will be lost// *** Remember to LIMIT your frames using an external limiter @ 25 or 30 FPS// *** Tick AA and AnisoFiltering inside FSX, set driver to application controlled//[BufferPools]UsePools=0 // Setting this to 1 will turn the BufferPools ON (stability), setting it to 0 disables them (Performance).RejectThreshold=102400PoolSize=2097152[FSDREAMTEAM]AntiPopUp=100AltitudeCull=1[JOBSCHEDULER]AffinityMask=12[GRAPHICS]HIGHMEMFIX=1ALLOW_SHADER_30=1STALE_BUFFER_THRESHOLD=1024 // Valid values are 5-1024TEXTURE_MAX_LOAD=1024NUM_LIGHTS=8AIRCRAFT_SHADOWS=1AIRCRAFT_REFLECTIONS=1COCKPIT_HIGH_LOD=1LANDING_LIGHTS=1AC_SELF_SHADOW=0EFFECTS_QUALITY=2GROUND_SHADOWS=0TEXTURE_QUALITY=3See_Self=1Text_Scroll=0D3D10=0IMAGE_QUALITY=0SHADER_CACHE_PRIMED_10=1693458432SHADER_CACHE_PRIMED=1693458432[Display]UPPER_FRAMERATE_LIMIT=0TEXTURE_BANDWIDTH_MULT=40TextureMaxLoad=30ChangeTime=4.000000TransitionTime=4.000000ActiveWindowTitleTextColor=255,255,255ActiveWindowTitleBackGroundColor=0,28,140,64NonActiveWindowTitleTextColor=255,255,255NonActiveWindowTitleBackGroundColor=24,33,87,64InfoUpperRightTextColor=255,0,0InfoUpperRightBackGroundColor=0,0,0,0InfoLowerLeftTextColor=255,255,255InfoLowerLeftBackGroundColor=255,0,0,128InfoLowerRightTextColor=255,255,255InfoLowerRightBackGroundColor=255,0,0,128InfoBrakesEnable=FalseInfoParkingBrakesEnable=FalseInfoPauseEnable=TrueInfoSlewEnable=TrueInfoStallEnable=FalseInfoOverspeedEnable=FalseBLOOM_EFFECTS=0SKINNED_ANIMATIONS=1WideViewAspect=TrueForceFullScreenVSync=FalseForceVSync=False[TERRAIN]TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=6000TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=6000LOD_RADIUS=3.500000AUTOGEN_DENSITY=4MESH_COMPLEXITY=100MESH_RESOLUTION=22TEXTURE_RESOLUTION=29DETAIL_TEXTURE=1WATER_EFFECTS=6[Main]DisablePreload=1User Objects=Airplane, HelicopterSimObjectPaths.0=SimObjects\AirplanesSimObjectPaths.1=SimObjects\RotorcraftSimObjectPaths.2=SimObjects\GroundVehiclesSimObjectPaths.3=SimObjects\BoatsSimObjectPaths.4=SimObjects\AnimalsSimObjectPaths.5=SimObjects\MiscSimObjectPaths.6=SimObjects\AISimObjectPaths.7=SimObjects\UT2 AircraftMaximized=1HideMenuNormal=1HideMenuFullscreen=1PerfBucket=7ProcSpeed=14767[SCENERY]// MissingLibraryAlert=1// ShowMissingTextureAlert=1LENSFLARE=1DAWN_DUSK_SMOOTHING=1IMAGE_COMPLEXITY=5[Weather]WindshieldPrecipitationEffects=1MinGustTime=10MaxGustTime=500MinGustRampSpeed=1MaxGustRampSpeed=200MinVarTime=5MaxVarTime=50MinVarRampSpeed=10MaxVarRampSpeed=75TurbulenceScale=0.900000WeatherServerAddress=fs2k.zone.comWeatherServerPort=80WeatherGraphDataInDialog=0AdjustForMagVarInDialog=1DynamicWeather=0DownloadWindsAloft=0DisableTurbulence=0CLOUD_DRAW_DISTANCE=8DETAILED_CLOUDS=1CLOUD_COVERAGE_DENSITY=8THERMAL_VISUALS=1[SOUND]AmbientUIMusicVolume=-6.000000SOUND=1SOUND_QUALITY=2SOUND_LOD=1UISound=1AmbientUI=0PrimaryDevice={DEF00000-9C6D-47ED-AAF1-4DDA8F2B5C03}VoiceDevice={DEF00002-9C6D-47ED-AAF1-4DDA8F2B5C03}SOUND_FADER1=0.350000SOUND_FADER2=0.400000SOUND_FADER3=0.450000SOUND_FADER4=-0.400000AmbientUIMusic=FSX01[PANELS]VIRTUAL_COCKPIT_TEXTURES_SCALE=2.0IMAGE_QUALITY=1QUICKTIPS=0PANEL_OPACITY=100PANEL_MASKING=1PANEL_STRETCHING=1UNIT

http://forum.avsim.net/topic/283061-bojotes-fsxcfg-file/page__view__findpost__p__1874621



S_OF_MEASURE=0DEFAULT_VIEW=0[CONTROLS]Controls_Default=StandardControls_Current=StandardKBDAIL=64KBDELEV=64KBDRUD=64force_master_gain=10000force_stick_force_enabled=0force_stick_shaker_enabled=0force_gear_bump_enabled=0force_crash_enabled=0force_ground_bumps_enabled=0force_master_enabled=0[TextInfo.1]Latitude=1,1Longitude=1,2Altitude=1,3Heading=1,4AirSpeed=1,5WindDirectionAndSpeed=1,6[TextInfo.2]FrameRate=1,1LockedFrameRate=1,2GForce=1,3FuelPercentage=1,4[TextInfo.3]Latitude=1,1Longitude=1,2Altitude=1,3Heading=1,4AirSpeed=1,5WindDirectionAndSpeed=1,6FrameRate=2,1LockedFrameRate=2,2GForce=2,3FuelPercentage=2,4[SlewTextInfo.1]Latitude=1,1Longitude=1,2Altitude=1,3Heading=1,4AirSpeed=1,5[SlewTextInfo.2]FrameRate=1,1LockedFrameRate=1,2[SlewTextInfo.3]Latitude=1,1Longitude=1,2Altitude=1,3Heading=1,4AirSpeed=1,5FrameRate=2,1LockedFrameRate=2,2[DynamicHeadMovement]LonAccelOnHeadLon=0LonAccelOnHeadPitch=0RollAccelOnHeadLat=0YawAccelOnHeadLat=0RollAccelOnHeadRoll=0MaxHeadAngle=0MaxHeadOffset=0HeadMoveTimeConstant=0[VirtualCopilot]VirtualCopilotActive=0[USERINTERFACE]PageID=1OpenATCOnCreate=0SHOW_MISSION_CAPTIONS=0PAUSE_ON_LOST_FOCUS=0PROMPT_ON_EXIT=1Map_Orientation=0ShowAllACPaintSchemes=1SelectAircraftManufacturer=AllSelectAircraftPublisher=Level-D SimulationsSelectAircraftType=AllSITUATION=FLIGHTS\OTHER\FLTSIMDisplayFuelAsWeight=0[ATC]ShowATCText=0COMM_MSG_NONE_COLOR=FFFFFFFFCOMM_MSG_ATC_USER_COLOR=FFB6FFB6COMM_MSG_USER_ATC_COLOR=FFFFD21BCOMM_MSG_ATC_AI_COLOR=FF00FF00COMM_MSG_AI_ATC_COLOR=FFFF7840AutoOpenAirTrafficWindow=0UsePilotVoice=0PilotVoice=458752[PointOfInterestSystem]CycleSetting=2[TrafficManager]AirlineDensity=0GADensity=0FreewayDensity=0ShipsAndFerriesDensity=0LeisureBoatsDensity=0IFROnly=0AIRPORT_SCENERY_DENSITY=0[AContain]ShowLabels=0ShowUserLabel=0ShowLabelManufacturer=0ShowLabelModel=1ShowLabelTailNumber=0ShowLabelDistance=1ShowLabelAltitude=1ShowLabelAirline=1ShowLabelAirlineAndFlightNumber=0ShowLabelFlightPlan=0ShowLabelContainerId=0ShowLabelAirspeed=0ShowLabelHeading=0LabelDelay=1000LabelColor=FFFF0000[INTERNATIONAL]ASLAT=2ASLON=1MEASURE=0[REALISM]PFactor=1.000000Torque=1.000000GyroEffect=1.000000CrashTolerance=1.000000General=1.000000UnlimitedFuel=FalseTrueAirspeed=FalseAutoCoord=FalseRealMixture=TrueStressDamage=TrueGEffect=TrueManualLights=TrueGyroDrift=TrueCrashWithDyn=FalseCrashDetection=TrueAutoTrim=False[SIM]SYSCLOCK=1[STARTUP]DEMO=0SHOW_OPENING_SCREEN=1STARTUP_DEMO=LoadWindow=1[FACILITIES]COUNTRY=STATE=CITY=GTL_BUTTON=1396[Misc]Com_Rate=7[RWW_WEATHER_MAP]SHOW_AIRPORTS=0SHOW_VORS=0SHOW_NDBS=0SHOW_APPROACHES=0SHOW_INTERSECTIONS=0SHOW_VICTOR=0SHOW_JET=0SHOW_AIRSPACE=0SHOW_FLIGHTPLAN=1SHOW_WEATHERSTATIONS=1SHOW_WEATHERSYSTEMS=1SHOW_DATATAGS=1SHOW_TERRAIN=1[FlightPlanMap]LineWidth=2SHOW_AIRPORTS=1SHOW_VORS=1SHOW_NDBS=1SHOW_APPROACHES=1SHOW_INTERSECTIONS=1SHOW_VICTOR=0SHOW_JET=0SHOW_AIRSPACE=1SHOW_FLIGHTPLAN=1SHOW_WEATHERSTATIONS=1SHOW_WEATHERSYSTEMS=1SHOW_DATATAGS=1SHOW_TERRAIN=1show_waypoints=1show_airways=1show_markers=1show_volume_boundaries=1show_ac_twr=1[MAPVIEW_MAP]SHOW_AIRPORTS=1SHOW_VORS=1SHOW_NDBS=1SHOW_APPROACHES=1SHOW_INTERSECTIONS=0SHOW_VICTOR=0SHOW_JET=0SHOW_AIRSPACE=1SHOW_FLIGHTPLAN=1SHOW_WEATHERSTATIONS=1SHOW_WEATHERSYSTEMS=1SHOW_DATATAGS=1SHOW_TERRAIN=1show_flight_history=1[WeatherMap]SHOW_AIRPORTS=0SHOW_VORS=0SHOW_NDBS=0SHOW_APPROACHES=0SHOW_INTERSECTIONS=0SHOW_VICTOR=0SHOW_JET=0SHOW_AIRSPACE=0SHOW_FLIGHTPLAN=1SHOW_WEATHERSTATIONS=1SHOW_WEATHERSYSTEMS=1SHOW_DATATAGS=1SHOW_TERRAIN=1[MULTIPLAYER]AccoutUsername=bojotecondAccoutPassword=0DefaultLobby=Free FlightVoiceVolume=-0.800000






ALLOW_SHADER_30 simply allows FSX to make use of SM3.0 for Water Effects, because they are the only shaders compiled using SM3.0 everything else is either 2.0 or 1.1 This was a 'compatibility' or design decision I suppose. so, DONT USE if you have old hardware. SM3.0 is DX9c only.AffinityMask=12 yes, reduces thread collisions and FSX scales well up to 3 CPU. after that, you are wasting CPU cycles. There is no performance impact here, so don't worry. And remember, even though affinity mask=12 only makes two cores active (core2 and core3) you'll STILL have activity in CORE0 because the fiber system is NOT bound to the Affinity mask vale, so, even AffinityMask=12 will make use of 3 CORES's for FSXIn the 'BufferPools' section, I included ALL values for all situations, so the ONLY value you want to change there is UsePools (which is an ON/OFF switch)so, that way, you have the choice to either run with no BufferPools OR run with BufferPools, but using the most efficient way of doing so.As for what is RejectThrelshold, you'll need to search the forum for that to see my previous posts. Think of it as the 'Alternative' Holy Grail to BP=0

ppo, on Apr 23 2010, 12:26 PM, said:

I would assume that's for testing. Doing it myself.If Pools=0 it doesn't read PoolSize then if Pools=1 it reads the PoolSizePierre

UsePools=0 will IGNORE PoolSize and RejectThresholdUsePools=1 will use a BufferPool with the size you specify in PoolSize



ABE, on Apr 23 2010, 06:17 PM, said:

*******, thanks for your FSX.CFG.

No prob.And, the affinity mask will NOT make the CPU graphs go away ;) it justs instructs the application 'which' cores it is allowed to use. 12 tells FSX to use the last TWO cores, but a 'piece' of FSX remains in CORE0 regardless of the affinity mask you set, thats why it is recommended on QUAD CORE machines to use either 12 or 14 so you leave CORE0 free for the fiber system (terrain)You will also notice that either AffinityMask (12 or 14) will give your the exact same performance. Not even a single frame difference. Try running FSX with 8 cores and see what happens ;) it gets all choppy because there are too many threads working togheter, and they interact with fibers, which need to co-operatively multitask so the more COREs the more complexity and possiblity or 'stutters' or problems.








Noel, on Apr 23 2010, 10:09 PM, said:

Do you know of any differences between using affinity mask parameter and Ed Wilk's freeware applet versus Set Affinity II? This is what I use, and I dedicate cores 0,1,2 to FSX, and other apps run on core4. If it is equivalent in effect, then it would be most efficient to handle this issue with Set Aff since you can then assign other processes to different cores, all in one easy to config utility.

Hi Noel, well, yes there is a difference. the 'AffinityMask' setting in FSX is 'INTERNAL' to FSX. so, FSX 'knows' there are 4 CORES but you are instructing it to use 2 or 3. Ed Wilks app or anyother app will set the mask at runtime, meaning FSX will NOT be aware of how many cores you have, so this might be tricky.all in all, FSX will ALWAYS use the first CORE for running fibers (which interact with the terrain renderer/texture manager) IF you use an external Affinity mask app, then FSX will treat whatever CORE was set at first, as the one FSX runs the fibers, so, my recomendation, what I would do is to forget about external affinity tools and use the internal FSX one and set it to either 12 or 14.What you can do (specially if you set Affinity Mask to 12) is assign your apps to CORE1 which FSX will not use. (altough it seem it does) but thats beyond the scope of this reply :)



audiohavoc, on Apr 24 2010, 12:00 AM, said:

So setting things like FSInn, UT2, TrackIR, and FPS Limiter to run on CORE1, and FSX set via the AffinityMask=12 to run on CORE2/CORE3 would be the most efficient use of my i7's cores?

Exactly! however, remember that the fibers that run on CORE0 don't take much CPU anyway, BUT if UT2 maxes CORE0 then you could have some stutters/lagging, so better to go the sure route and have them run on CORE1









FSX vSync FIX


In [GRAPHICS] (not DISPLAY) add this:ForceFullScreenVSync=1And yes, its 1, not 'True'and set your driver to let the application manage vsync. just tested now with my nVidia card, and I can confirm it works. Can an ATI user test? I tested also in my laptop which uses a crappy intel card and it also worked... so either I'm completely dilusional or this is one of those 'miracle tweaks' (for ATI users) test and report.

[FSX] Wind Questions


Lrusso, on Apr 24 2010, 04:53 AM, said:

I'm considering buying FSUPIC but I am wondering how well this does the job. I don't care if the weather's perfect I just don't the aircraft to be destroyed.

Extremely well. FSUIPC is an 'essential' add-on to any simmer, wind control is just one of MANY features/enhaments.. particularly, I use it for controller assignments and mouse macros as well. You can't go wrong.



Noel, on Apr 25 2010, 01:04 AM, said:

Thank you for your reply & recommendation *******, which seems like an educated guess, versus something tested and proven? I like to try to separate friendly educated guesses from






http://forum.avsim.net/topic/283144-fsx-wind-questions/



http://forum.avsim.net/topic/283143-fsx-vsync-fix/



proven fact, if at all possible.What does FSX "think" when the AffinityMask setting is left out? When I use the applet I notice FSX is running nearly 100% on the 3 cores assigned, as if FSX was able to utilize the 3 assigned cores just fine, and quite heavily might reemphasize. Do you have any additional insight that sheds more light on the practical effects of this distinction?

FSX (when no affinity mask is present) simply uses all available processors. The affinity mask (its called mask because it MASKS cores for an app) simply serves as a way to tell FSX which 'cores' are 'usable' by the APP. again, this setting, when set on the FSX.CFG is not a 'hard mask' its an application mask, meaning FSX knows of the existence of all your available CORES's but is using only 'some of them' (based on the mask setting)A 'HARD' affinity mask, is the one set at the OS level, with it, your app DOESN'T EVEN KNOW of the existence of all your processors, but only the ones the hard mask is allowing.Now, lF you don't set ANY affinity mask in FSX.cfg, but you mask it via an external app, FSX will run on ALL the cores that the hard mask is allowing. So, for example:If you have an i7 with HT set to Off and you run FSX with a HARD mask of 14 set in the applet, then this is what the app will 'think' (assuming there is NO AffinityMask setting inside fsx.cfg)1) FSX will think, your computer only has 3 available cores2) Out the 3 cores FSX 'thinks' your computer has, it will use the First, for fibers an Main scheduler. and the rest will be texture managers.However, if you DO NOT run any 'applet' and you do NOT set any 'hard masks' but instead, set in fsx.cfg AffinityMask=14 then, this is what FSX will thing:1) FSX will think, your computer has 4 available cores2) Out of the 4 cores, FSX will use the last 3 like this: First core main scheduler, and the remaining two texture managers. so you ask, what about the 'fibers'? well they REMAIN in the first core because they are not bound to the AffinityMask setting inside fsx.cfgSo at the end, you'll have:CORE0 = Running Fibers (terrain system)CORE1 = Main SchedulerCORE2 = Texture ManagerCORE3 = Texture ManagerThe above, can ONLY be achieved with NO HARD MASK and using an AffinityMask value of 14 inside fsx.cfg Noel, no 'educated guesses' here. Thats how it works, and you can test it yourself, send me a PM and I'll make sure I clarify this further if you think its confusing or you still think I'm 'guessing' :)

413X3, on Apr 25 2010, 01:58 AM, said:

*******, the night lights for Ultimate Terrain are now flashing when I'm flying in clouds. How can I fix this? I'm using your entire fsx settings

Thats a known Ultimate Terrain problem... like ages old :) search the UT forums and you'll see. Probably the more 'lights' there is, it will be more evident.

FSX vSync FIX






bojote, on Apr 24 2010, 04:01 AM, said:

In [GRAPHICS] (not DISPLAY) add this:ForceFullScreenVSync=1And yes, its 1, not 'True'and set your driver to let the application manage vsync. just tested now with my nVidia card, and I can confirm it works. Can an ATI user test? I tested also in my laptop which uses a crappy intel card and it also worked... so either I'm completely dilusional or this is one of those 'miracle tweaks' (for ATI users) test and report.

In adition to ForceFullScreenVSync=1 there is also this one:ForceWindowedVSync=1 it also goes in the [GRAPHICS] section. Since I don't run window mode, I've not tested it.. but, guess someone will.

FSX vSync FIX


B777ER, on Apr 26 2010, 11:40 AM, said:

In a previous thread you had it: 'STALE_BUFFER_THRESHOLD=2147483647'.

I was 'corrected' later, Ryan from PMDG determined that the min-max values were 5 to 1024 and that setting it OVER 1024 will reset it to 60. so, 1024 is what you want to use. Ask Ryan (PMDG) he is the expert in video stuff.. that value (Stale Buffer) refers to a frame ahead buffer used by FSX.

My take on Bojote's tweaks


Longyear, on Apr 26 2010, 12:56 PM, said:

So my message is, yes, the messiah has undoubtedly brought us something magical! ....but keep your willingness to challenge, and try your own things.

It was because I CHALLENGED the state of things that brough you the tweaks I've published in the last weeks... so, who am I to tell others not to challenge my own advice!!! please do, now lets discuss it :)The Water settings on LOW 1.0 and HIGH 2.0 take the 'exact' same ammount of CPU cycles ;) it's GPU what they affect, because they rely heavily on hardware programable shaders :)



http://forum.avsim.net/topic/283351-my-take-on-bojotes-tweaks/







only water MAX 2.0 is the one that EATS your CPU completely.P.D (by the way, my config has no AI traffic because I fly VATSIM) So, I don't use AI, except for testing...thats the only two observations :)



413X3, on Apr 26 2010, 03:28 PM, said:

I run 6.5 lod radius

Thats a big 'No No' :)Specially with BP=0!!! do what I do, Just make it short, 3.5 and STUFF all the terrain with autogen :) that way it looks all 'covered'

#1757946 My take on Bojote's tweaks


McCrash, on Apr 26 2010, 04:51 PM, said:

What is FFTF? Thanks.

FFTF => FIBER_FRAME_TIME_FRACTION=0.50 ( under [MAIN] )it affects the % of time fibers 'render' terrain. 0.50 means thant 50% of the time it takes to render a frame the 'fibers' will try to 'load' terrain. It's simply a % for resource allocation.Adam explained this a long long time ago :) same as Phil Taylor, so nothing new here. Aditionally, and as I explained before this 'fibers' are 'stuck' to CORE0 and they ignore the affinity mask, thats why setting AffinityMask=14 'moves' the main scheduler OFF CORE0 to CORE1 leaving the fibers with lot of room, so the 0.50 won't affect your performance one bit but will make terrain tiles load faster.Evidently, the above ONLY APPLIES to quad cores... if you do this on a DUAL core you kill it.And if you are the 'curious' type, AffinityMask=14 means:(first, use the windows calculator, and see which is the BINARY representation of the decimal '14'it is:1110Now, turn that around... swap it, as if you were looking a mirror:0111Above you see the ones represent your 'active' cores. so, 14 Will make CORE1 2 and 3 active for FSX. CORE0 will stay free BUT since fibers IGNORE this AffinityMask then they will use CORE0 effectively (and efficiently) using ALL 4 CPU's so in short, if you have a QUAD or i7 your




http://forum.avsim.net/topic/283351-my-take-on-bojotes-tweaks/?view=findpost&p=1757946






AffinityMask should be 14 to make the most efficient use of resources.I know the answer is a bit too technical, but it allows others to grasp the concept and reply to this questions as well, so I'm not a single source of information and we all share and help others



Paul_Yorks, on Apr 26 2010, 05:31 PM, said:

JB - you say here 14 for AM if you have a Quad or i7; so why, with your i7, is your AM set to 12 in the .cfg you posted?

12 will make use of only ONE texture manager (instead of two) since fiber cooperatively multitask with this threads, the fewer the threads the less chance of thread collisions or 'stutters' 12 and 14 are both valid options, its just that telling people to use '12' will make them all crazy asking 'why' they need to reduce their number of CPU's when they can use all 4.Personally, I use 12. But again, could use 14 and probably won't notice a dif. performance wise is exactly the same.and to expand a little the reply.. the 'texture' managers do also async batching (autogen) you can fine tune this via:[SCENERY]MAX_ASYNC_BATCHING_JOBS=1 // Default is 1 (Should match the number of texture manager threads)by default, the above is '1' max is '4' if you want 'efficiency' then the above should match your number of texture managers. Since I usedefault (1) then, I simply set AffinityMask to 12. If I were to use Affinity Mask 14, then the above should be MAX_ASYNC_BATCHING_JOBS=2 but this 'aditional' batching can and WILL create instability IF you use BP=0This tweaks are all about 'balance' and efficient use of resources, not just 'raw' speed, and most definitely not guesswork as some like to suggest :)



Paul_Yorks, on Apr 26 2010, 06:23 PM, said:

Am I right in thinking (and I know I'm simplifying here) that part of your approach is to allow fast texture loading, to get rid of the stutters, but then to "hide" the blurry textures that this creates, by covering everything with autogen? That seems to be how this is working, and I'm pretty happy with it, but I'd like to know if that's the general idea behind it.









Correct, remember that the scenery LOD its a 'ring' around your A/C a LOD of 3.5 will 'batch' everything in that radius, while also decreasing the number of objects to load... anyway, the ground will be so covered with autogen (on final approach for example) that you won't notice any blurries. and if you are flying HIGH and FAST the FFTF will definitely help you! so in either case, it seems LOD 3.5 to be a very good compromise between looks and stability (when using BP=0)there is people using LOD of 6.5, 7.5 fine... but, with BP=0? forget it... it will simply not work.



audiohavoc, on Apr 26 2010, 07:02 PM, said:

Does the 3.5 radius help offset the performance impact of saturating the autogen?

it does, yes.. the autogen 'density' increases or decreases in proportion to the LOD radius. so, if you lower your LOD, then you can increase AG, and the other way around too, like Kosta. if you LOWER AG, then you'll probably able to use high LOD settings with no problem.

FPS Limited vs. Unlimited


Kosta, on Apr 28 2010, 04:04 PM, said:

Great *******! I see the exact picture here! Now I wonder... why is CPU usage dropping drastically? You think what I wrote two posts back might be right?Btw. if settings FFTF to 0, I achieve some FPS, actually so much what I lose through setting FPS vs. unlimited... maybe this is another small miracle tweak? Would be nice if someone confirmed! Still, gotta do some flight and smoothness testing.

Well... 'any' application, be it a 3d shooter, simulation, racing etc. is based on the rendering of single frames in rapid sucession. 'each' frame (which is rendered in aproximately 40ms) has some CPU usage component associated to it, remember, the GPU always LAGS behind the CPU in frame rendering, the CPU is the one who determines 'WHAT' to render, the GPU figures out HOW to do it.



http://forum.avsim.net/topic/283421-fps-limited-vs-unlimited/






now... picture the following:IF the CPU only needs to render 25 each second, the CPU usage will be somewhat low... because is not working that hard. if you UNLIMIT then the CPU has to work harder and harder to produce a high number of frames. FPS Limiter, LIMITS the number of frames the CPU is able to render because when it senses you reach 25, then it throttles down the frames, so the CPU is kept from scaling.My 'threory' and this is PURELY speculation, is that FSX does a terrible job doing frame limiting. I think its simply (in the background) allowing the sim to produce a HIGH number of frames so the CPU is 'preparing' them ahead, but ONLY sending 25 FPS for the GPU to render. I think of this as some kind of highly inneficient buffering that requires a large number of frame aheads which in turn kill your CPU. speculation, of course :) but consistent with my observations.Now, how 'THAT" explains 'stuttering' when using FPS Limiter? well... no frame aheads, means possible 'skipping' ;) or perceived stutters... but with a large frame buffer everything is rendered in advance, which also means more 'smoothness'I think you can control that with the STALE buffer tweak.. but I've not tested.

#1759079 FPS Limited vs. Unlimited



That still doesn't explain why the FSX is loading textures slower when CPU is throttled.

Ahh.. good point :) thats because, when using Limited frames, there are two hidden variables that come into play... :) they are:[MAIN]MIN_FIBER_TIME_SEC=MAX_FIBER_TIME_SEC=They change how the FIBERS interact for each frame rendered, instead of % allocation, with TIME allocation (in milliseconds) MIN and MAX play with those and see if you notice any change.One more thing.. IF running UNLIMITED frames, the best way to compensate for blurries IS increasing FFTF, however, thois also induces some stutters as you have probably noticed.

FPS Limited vs. Unlimited









http://forum.avsim.net/topic/283421-fps-limited-vs-unlimited/?view=findpost&p=1759079



I did play with high FFTF, as high as 0.99 and even tried 1.0, buuut... that didn't have any reasonable effect on texture loading, it would just *appear* they loaded a little quicker, but eventually, engine would run out of gas. When I would press Pause, I could observe highres textures loading...

Kosta, I'm as puzzled as you are when it comes to FSX performance limiting frames vs running unlimited+FPS Limiter and unless we have some official explanation from MS as why this is, the mistery will continue :)I'm happy running unlimited and using FPS Limiter... oh, and one more thing.. if you want to even out the load for the texture managers, you can add this:[SCENERY]MAX_ASYNC_BATCHING_JOBS=2 // (default is 1 MAX is 4)should match the number of texture/terrain managers

Now I'm confused...again!


cmpbellsjc, on Apr 30 2010, 09:58 AM, said:

ProcSpeed=11109PerfBucket=7

Also, no need to 'rebuild' the entire file. just removing ProcSpeed will calculate it again over and over :)I suggest you remove all your USB devices (for testing of course) and try again and see if procspeed improves.

If you get to the end of the road in tweaking FSX...

Posted by bojote on 04 May 2010 - 05:58 PM in MS FSX Forum

J van E, on May 4 2010, 12:57 PM, said:

no highmemfix

Careful there. HIGHMEMFIX is NOT a tweak, it IS an actual 'fix' Ryan, from PMDG can shed more 'official' light on it. I can not.



http://forum.avsim.net/topic/284127-if-you-get-to-the-end-of-the-road-in-tweaking-fsx/



http://forum.avsim.net/topic/283728-now-im-confusedagain/



BP=0 since 2007?


pipes123, on May 10 2010, 07:57 AM, said:

The BP=0 Tweak was out there for a long time (though not everyone knew about it).Bojote is not the discoverer of it, I thought that was known.His crazy work is all the really detailed explanations of what it actually does exactly and not to mention the other things not concerning BP=0.

in fact, those who closely followed the monster BP=0 thread probably remember that I also made a reference to the above URL.Some German sites also have info dating from 2008, so it seems europeans were the 'discoverers' (French to be exact) I

Distant Blurries


INFORIS, on May 11 2010, 03:57 PM, said:



http://forum.avsim.net/topic/284814-distant-blurries/



http://forum.avsim.net/topic/284670-bp0-since-2007/



Does the MipBias Tweak have any Effect on these Blurries?VideoCard= XFX ATI Radeon 4650 HD

Higher LODs will help in around the A/C but NOT distant blurries. However, The Shader Mod tweak (latest version yesterday) now includes a terrain specific negative LOD bias plus Aniso Filters to make the distant terrain a little bit more sharp.

Distant Blurries


Kosta, on May 12 2010, 01:51 PM, said:



http://forum.avsim.net/topic/284814-distant-blurries/


I must somewhat contradict this. Using higher LOD_RADIUS, eg. 9.5 vs default 4.5 (high setting) gives MUCH clearer and sharper textures both near aircraft and in distance. I made some comparison shots I believe at AS Madeira, where I was spot-looking towards a mountain in the background, and could clearly see changes between 4.5-5.5-6.5-7.5-9.5 setting, those I tested making for each one and the same shot (fixed spot saved). I could clearly see mountain textures clear up.Point is with higher LOD Nr, highres textures spread more widely around aircraft position. Lowerres textures are futher away. You don't recognize them at 9.5, since they are far enough. Both ground level and all up to 60,000ft. There is a big change you are going to get an OOM error at such high LOD. That is why a setting of 7.5 is a very good compromise.Keep in mind that some HP is needed, FPS ARE gonna drop a bit with higher LOD, of course...And, don't ask me why always .5. I just do it like that

Sure, by 'distant' we are talking about those 'beyond' the LOD_RADIUS coverage, those blurries can be controlled via negative LOD bias settings as long as Aniso filtering is also enabled (to avoid shimmering)The last update to the shader 3.0 mod has this 'feature' and you can clearly see WAY BEYOND your LOD_RADIUS coverage.

FSX on Win7_x64 with HighMem Fix


J van E, on May 12 2010, 04:37 PM, said:

Amazing indeed. is the first time I've heard that Highmemfix is a performance tweak... It's supposed to be a 'anti-lockup-tweak'... Do you really mean to say that when you remove the entry from the cfg your fps drops that much...?

I don't think HIGHMEMFIX improves performance AT ALL... nothing, nada... its simply a FIX! (not a performance tweak) it simply enables the LARGEADDRESSAWARE for the DX9 D3DEffects system which (for implementation reasons) was NOT enabled by default when FSX shipped. It made things worse with WDDM because of how memory is managed in Vista and Win7.

Micro stutters

Posted by bojote on 19 May 2010 - 09:39 AM in MS FSX Forum



http://forum.avsim.net/topic/285477-micro-stutters/



http://forum.avsim.net/topic/284866-fsx-on-win7-x64-with-highmem-fix/


Pegasus1, on May 19 2010, 05:27 AM, said:

Can you explain please, why u suggest him to lower the TBM to 10 ?

If the TBM is set LOWER than your frame rate lock IT IS completely ignored. As usual, you can ask Ryan from PMDG to give you the inside scoop :) so the suggestion is not 'crazy' at all. In fact, a very good suggestion to reduce microstutters considerably *IF* the GPU is being stressed.

980X HT Off & 3 Physical cores @ 5Ghz Possible?

Posted by bojote on 21 May 2010 - 05:41 AM in MOBO, RAM, CPU's & Other Hardware

w6kd, on May 19 2010, 01:49 AM, said:

I use affinity mask=12 right now in FSX...it seems smoother to me, where AM=14 produced a frame or two higher and marginally better AG fills, but with the occasional teeny tiny microstutter. I'm thinking that's due to less than perfect timing between the paralleled threads. So if a 980 could be run on 3 cores via BIOS with AM=12 and overclocked to near 5 GHz, that'd be a very interesting development...maybe the fastest configuration possible on current hardware short of very expensive/exotic phase change coolers and a need to run voltages beyond Intel's absolute max specs for the chip.

same here :) AM=12 provides MUCH more smoothness and less stutters, due to, fiber/thread interaction being simpler (fibers cooperatively multitask and need to be in perfect armony with the threads) the more threads, more possibility for problems. So, in my opinion a 980x + 3 Cores @ 5Ghz (if possible) is the perfect config for FSX.

FSX Video Capture (FRAPs style) but native to FSX!


Probably this is old news, but not to me. Did people know there is an FSX control to CAPTURE videos in AVI format? the control is NOT included by default, so it was probably added later (SP2 maybe?)Anyway, if you would like to capture videos in uncompressed AVI format (Yes, I know FRAPs does this, but this is a NATIVE FSX control) then add this entry to your controls mapping file



http://forum.avsim.net/topic/286224-fsx-video-capture-fraps-style-but-native-to-fsx/




http://forum.avsim.net/topic/285369-980x-ht-off-3-physical-cores-5ghz-possible/



(Standard.XML) videos are HUGE, so probably this is not something to use for extended periods, but is nice to know we have the functionality there for at least short videos. Recordings will be stored in your My Documents/Video folder in AVI format. <Entry> <Key>SHIFT+V</Key> <Down>VIDEO_RECORD_TOGGLE</Down> </Entry>

FSX Video Capture (FRAPs style) but native to FSX!


n4gix, on May 27 2010, 12:42 PM, said:

Files are H U G E... also, there's no sound recorded, unfortunately. From what I was told years ago while at the first ACES DevCon, they ran out of time to complete the internal recorder, so that's why it was left "undocumented..."As it turned out, it would have taken

more effort to strip out the incompleted code than it would to simply not mention it...

it would be nice to have this feature for FSNext ;) specially if sound can be recorded and files compressed on the fly to wmv/mp4 format. I also noticed there are two switches in [MAIN] called VIDEO_COMPRESSION and VIDEO_COMPRESION_LEVEL first one is an int (0/1) second a float ranging from 0.0 to 1.0 resulting files are tiny when using this compression, but the CODEC they seem to be using is messing up the video, so it was definitely not completed, oh well.

#1777897 question for Jesus on BP=0 tweak

Posted by bojote on 05 June 2010 - 01:19 PM in MS FSX Forum

Chapstick, on Jun 5 2010, 12:17 AM, said:

I have a question actually... what is the number in [BufferPools]RejectThreshold=98304 mean? Are those bytes?



http://forum.avsim.net/topic/286950-question-for-jesus-on-bp0-tweak/

http://forum.avsim.net/topic/286950-question-for-jesus-on-bp0-tweak/?view=findpost&p=1777897



http://forum.avsim.net/topic/286224-fsx-video-capture-fraps-style-but-native-to-fsx/



Yes, those are bytes.. they mean that, all vertex data ABOVE the 98304 bytes value will BYPASS the BufferPool and go 'directly' to the GPU.. and all the vertex data UNDER 98304 is send to the bufferpool.Size of the vertex data depends on the particular scenery/autogen/situation you are in any given moment, the size will change EVERY FRAME.The reason it performs so close to BP=0 is because your are using the bufferpools for really small chunks of data, which is what Dynamic Vertex Buffers are good for. Note I said 'close' to BP=0 performance, however not quite AS GOOD as BP=0Also, when you use RejectThreshold you might want to adjust the STALE_BUFFER_THRESHOLD under [GRAPHICS] to a value that MATCHES your average framerate. for example:[GRAPHICS]STALE_BUFFER_THRESHOLD=25The above controls how many 'frames' (not bytes as I initially suggested) are kept (and can lag behind) for BufferPool processing, the closest this value is to your current/average frame rate, the less 'old/expired' frames are batched by the dynamic buffers. The higher this value, the more time the sim will allocate to getting 'past' frames to be processed/batched so It can induce instability and stutters. The 'ideal' value is around 20-30 (default is 60)P.D The above have been previously discussed in the forum, they are not 'miracle' tweaks... so please, think twice before posting something like: 'OMG My frames went up 200% after this tweak!' kind of post :) use the above ONLY if you CAN NOT USE BP=0, if you are happy with BP=0 simply ignore the above (but you can still set STALE_BUFFER_THRESHOLD to your average framerate)


Posted by bojote on 27 July 2010 - 01:42 AM in MS FSX Forum

Limp, on Jul 25 2010, 02:10 PM, said:

All the textures load very quickly but I would like to solve that.

Thomas, texture loading can be tweaked changing the TextureMaxLoad value.. can you check you have it in your FSX.cfg? here is my latest fsx.cfg..

//// FSX Config File By ******* Altuve (Bojote) // Last Revision May 31, 2010// *** This file has been tweaked to run maximum performance, looks and stability// *** ONLY TO BE USED ON i7's running > 3.8Ghz and a GTX 280/480's // *** Do not change ANY value, otherwise the achieved balance will be lost// *** Remember to LIMIT your frames using an external limiter @ 25 or 30 FPS// *** Tick AA and AnisoFiltering inside FSX, set driver to application controlled//[BufferPools]UsePools=0 // Setting this to 1 will turn the BufferPools ON (stability), setting it to 0 disables them (Performance).RejectThreshold=98304 // Vertex data at or over 96KB does not get pooled and bypasses the bufferpoolPoolSize=2097152 // Defines a 2MB BufferPool[FSDREAMTEAM]AntiPopUp=100AltitudeCull=1[JOBSCHEDULER]AffinityMask=12[GRAPHICS]// DPUPBUFFERSIZE=500000HIGHMEMFIX=1ALLOW_SHADER_30=1STALE_BUFFER_THRESHOLD=20 // Valid values are 5-1024SHADER_OPTIMIZE=1SHADER_PARTIAL_PRECISION=1ForceFullScreenVSync=1ForceW





indowedVSync=1TEXTURE_MAX_LOAD=1024NUM_LIGHTS=8AIRCRAFT_SHADOWS=1AIRCRAFT_REFLECTIONS=0COCKPIT_HIGH_LOD=1LANDING_LIGHTS=1AC_SELF_SHADOW=0EFFECTS_QUALITY=2GROUND_SHADOWS=0TEXTURE_QUALITY=3See_Self=1Text_Scroll=0D3D10=0IMAGE_QUALITY=0SHADER_CACHE_PRIMED_10=1693458432SHADER_CACHE_PRIMED=1693458432[Display]// ForceVCShadowMap=1 // Default is 0UPPER_FRAMERATE_LIMIT=0TEXTURE_BANDWIDTH_MULT=10TextureMaxLoad=21ChangeTime=4.000000TransitionTime=4.000000ActiveWindowTitleTextColor=255,255,255ActiveWindowTitleBackGroundColor=0,28,140,64NonActiveWindowTitleTextColor=255,255,255NonActiveWindowTitleBackGroundColor=24,33,87,64InfoUpperRightTextColor=255,0,0InfoUpperRightBackGroundColor=0,0,0,0InfoLowerLeftTextColor=255,255,255InfoLowerLeftBackGroundColor=255,0,0,128InfoLowerRightTextColor=255,255,255InfoLowerRightBackGroundColor=255,0,0,128InfoBrakesEnable=FalseInfoParkingBrakesEnable=FalseInfoPauseEnable=TrueInfoSlewEnable=TrueInfoStallEnable=FalseInfoOverspeedEnable=FalseBLOOM_EFFECTS=0SKINNED_ANIMATIONS=1WideViewAspect=True[TERRAIN]// BATCH_AUTOGEN2=1 // Default is 0// TEXTURE_FORMAT=7 // Default is 7// TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=1000// TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=600MIN_DETAIL_TEXTURE_LEVEL=21 // Default is 15MAX_DETAIL_TEXTURE_LEVEL=21 // Default is 21TEXTURE_SIZE_EXP=10 // Default is 8SWAP_WAIT_TIMEOUT=20LOD_RADIUS=3.500000AUTOGEN_DENSITY=5MESH_COMPLEXITY=100MESH_RESOLUTION=22TEXTURE_RESOLUTION=29DETAIL_TEXTURE=1WATER_EFFECTS=6[Main]// FIBER_FRAME_TIME_FRACTION=0.50DisablePreload=0User Objects=Airplane, HelicopterSimObjectPaths.0=SimObjects\AirplanesSimObjectPaths.1=SimObjects\RotorcraftSimObjectPaths.2=SimObjects\GroundVehiclesSimObjectPaths.3=SimObjects\BoatsSimObjectPaths.4=SimObjects\AnimalsSimObjectPaths.5=SimObjects\MiscSimObjectPaths.6=SimObjects\MyTrafficXSimObjectPaths.7=Aircraft// SimObjectPaths.8=SimObjects\AI// SimObjectPaths.9=SimObjects\UT2 Aircraft// SimObjectPaths.10=SimObjects\AIComplex// SimObjectPaths.11=SimObjects\WOAIMaximized=1HideMenuNormal=1HideMenuFullscreen=1PerfBucket=7ProcSpeed=14767Location=0,0,1280,720,\\.\DISPLAY1[SCENERY]// MissingLibraryAlert=1// ShowMissingTextureAlert=1// MAX_ASYNC_BATCHING_JOBS=2 // Default is 1 (Should match the number of texture manager threads)// ObjectsToBatchPerFrame=30SmallPartRejectRadius=0.0LENSFLARE=0DAWN_DUSK_SMOOTHING=1IMAGE_COMPLEXITY=5[Weather]WindshieldPrecipitationEffects=0MinGustTime=10MaxGustTime=500MinGustRampSpeed=1MaxGustRampSpeed=200MinVarTime=5MaxVarTime=50MinVarRampSpeed=10MaxVarRampSpeed=75TurbulenceScale=0.750000WeatherServerAddress=fs2k.zone.comWeatherServerPort=80WeatherGraphDataInDialog=0AdjustForMagVarInDialog=1DynamicWeather=0DownloadWindsAloft=0DisableTurbulence=0CLOUD_DRAW_DISTANCE=6DETAILED_CLOUDS=1CLOUD_COVERAGE_DENSITY=8THERMAL_VISUALS=0[SOUND]AmbientUIMusicVolume=-6.000000SOUND=1SOUND_QUALITY=2SOUND_LOD=1UISound=1AmbientUI=0PrimaryDevice={DEF00000-9C6D-47ED-AAF1-4DDA8F2B5C03}VoiceDevice={DEF00002-9C6D-47ED-AAF1-4DDA8F2B5C03}SOUND_FADER1=0.100000SOUND_FADER2=0.400000SOUND_FADER3=0.450000SOUND_FADER4=-0.400000AmbientUIMusic=FSX01[PANELS]VIRTUAL_COCKPIT_TEXTURES_SCALE=2.0 // Default is 1.0IMAGE_QUALITY=1QUICKTIPS=0PANEL_OPACITY=100PANEL_MASKING=1PANEL_STRETCHING=1UNITS_OF_MEASURE=0DEFAULT_VIEW=0[CONTROLS]Controls_Default=StandardControls_Current=StandardKBDAIL=64KBDELEV=64KBDRUD=64force_master_gain=10000force_stick_force_enabled=0force_stick_shaker_enabled=0force_gear_bump_enabled=0force_crash_enabled=0force_ground_bumps_enabled=0force_master_enabled=0[TextInfo.1]Latitude=1,1Longitude=1,2Altitude=1,3Heading=1,4AirSpeed=1,5WindDirectionAndSpeed=1,6[TextInfo.2]FrameRate=1,1LockedFrameRate=1,2GForce=1,3FuelPercentage=1,4[TextInfo.3]Latitude=1,1Longitude=1,2Altitude=1,3Heading=1,4AirSpeed=1,5WindDirectionAndSpeed=1,6FrameRate=2,1LockedFrameRate=2,2GForce=2,3FuelPercentage=2,4[SlewTextInfo.1]Latitude=1,1Longitude=1,2Altitude=1,3Heading=1,4AirSpeed=1,5[SlewTextInfo.2]FrameRate=1,1LockedFrameRate=1,2[SlewTextInfo.3]Latitude=1,1Longitude=1,2Altitude=1,3Heading=1,4AirSpeed=1,5FrameRate=2,1LockedFrameRate=2,2[DynamicHeadMovement]LonAccelOnHeadLon=-

0.020000LonAccelOnHeadPitch=-0.010000RollAccelOnHeadLat=0.010000YawAccelOnHeadLat=-0.100000RollAccelOnHeadRoll=0.100000MaxHeadAngle=5.000000MaxHeadOffset=0.300000HeadMoveTimeConstant=1.000000[VirtualCopilot]VirtualCopilotActive=0[USERINTERFACE]PageID=1OpenATCOnCreate=0SHOW_MISSION_CAPTIONS=0PAUSE_ON_LOST_FOCUS=0PROMPT_ON_EXIT=1Map_Orientation=0ShowAllACPaintSchemes=1SelectAircraftManufacturer=AllSelectAircraftPublisher=Flight1/CoolSkySelectAircraftType=AllSITUATION=c:\users\*******\documents\flight simulator x files\Last FsPassengersX save.FLT// SITUATION=FLIGHTS\OTHER\FLTSIMDisplayFuelAsWeight=0[ATC]ShowATCText=0COMM_MSG_NONE_COLOR=FFFFFFFFCOMM_MSG_ATC_USER_COLOR=FFB6FFB6COMM_MSG_USER_ATC_COLOR=FFFFD21BCOMM_MSG_ATC_AI_COLOR=FF00FF00COMM_MSG_AI_ATC_COLOR=FFFF7840AutoOpenAirTrafficWindow=0UsePilotVoice=0PilotVoice=458752[PointOfInterestSystem]CycleSetting=2[TrafficManager]AirlineDensity=0GADensity=0FreewayDensity=0ShipsAndFerriesDensity=0LeisureBoatsDensity=0IFROnly=0AIRPORT_SCENERY_DENSITY=0[AContain]ShowLabels=0ShowUserLabel=0ShowLabelManufacturer=0ShowLabelModel=1ShowLabelTailNumber=0ShowLabelDistance=1ShowLabelAltitude=1ShowLabelAirline=1ShowLabelAirlineAndFlightNumber=0ShowLabelFlightPlan=0ShowLabelContainerId=0ShowLabelAirspeed=0ShowLabelHeading=0LabelDelay=1000LabelColor=FFFF0000[INTERNATIONAL]ASLAT=2ASLON=1MEASURE=0[REALISM]PFactor=1.000000Torque=1.000000GyroEffect=1.000000CrashTolerance=1.000000General=1.000000UnlimitedFuel=FalseTrueAirspeed=FalseAutoCoord=FalseRealMixture=TrueStressDamage=TrueGEffect=TrueManualLights=TrueGyroDrift=TrueCrashWithDyn=FalseCrashDetection=TrueAutoTrim=False[SIM]SYSCLOCK=1[STARTUP]DEMO=0SHOW_OPENING_SCREEN=1STARTUP_DEMO=LoadWindow=1[FACILITIES]COUNTRY=STATE=CITY=GTL_BUTTON=1232[Misc]Com_Rate=7[RWW_WEATHER_MAP]SHOW_AIRPORTS=0SHOW_VORS=0SHOW_NDBS=0SHOW_APPROACHES=0SHOW_INTERSECTIONS=0SHOW_VICTOR=0SHOW_JET=0SHOW_AIRSPACE=0SHOW_FLIGHTPLAN=1SHOW_WEATHERSTATIONS=1SHOW_WEATHERSYSTEMS=1SHOW_DATATAGS=1SHOW_TERRAIN=1[FlightPlanMap]LineWidth=2SHOW_AIRPORTS=1SHOW_VORS=1SHOW_NDBS=1SHOW_APPROACHES=1SHOW_INTERSECTIONS=1SHOW_VICTOR=0SHOW_JET=0SHOW_AIRSPACE=1SHOW_FLIGHTPLAN=1SHOW_WEATHERSTATIONS=1SHOW_WEATHERSYSTEMS=1SHOW_DATATAGS=1SHOW_TERRAIN=1show_waypoints=1show_airways=1show_markers=1show_volume_boundaries=1show_ac_twr=1[MAPVIEW_MAP]SHOW_AIRPORTS=1SHOW_VORS=1SHOW_NDBS=1SHOW_APPROACHES=1SHOW_INTERSECTIONS=0SHOW_VICTOR=0SHOW_JET=0SHOW_AIRSPACE=1SHOW_FLIGHTPLAN=1SHOW_WEATHERSTATIONS=1SHOW_WEATHERSYSTEMS=1SHOW_DATATAGS=1SHOW_TERRAIN=1show_flight_history=1[WeatherMap]SHOW_AIRPORTS=0SHOW_VORS=0SHOW_NDBS=0SHOW_APPROACHES=0SHOW_INTERSECTIONS=0SHOW_VICTOR=0SHOW_JET=0SHOW_AIRSPACE=0SHOW_FLIGHTPLAN=1SHOW_WEATHERSTATIONS=1SHOW_WEATHERSYSTEMS=1SHOW_DATATAGS=1SHOW_TERRAIN=1[DISPLAY.Device.NVIDIA GeForce GTX 480.0]Mode=1280x720x32Anisotropic=1AntiAlias=1[DISPLAY.Device.NVIDIA GeForce GTX 480.0.0]Mode=1280x720x32Anisotropic=1AntiAlias=1[MULTIPLAYER]AccountLogin=1AccoutUsername=blkslvr94condAccoutPassword=0LanUsername=PlayerDefaultLobby=Free FlightVoiceVolume=-0.800000


Posted by bojote on 27 July 2010 - 01:53 AM in MS FSX Forum

Pegasus1, on Jul 25 2010, 07:02 PM, said:





@Bojote: Can you give me an answer to this?Thanks in advance.Pegasus.

Pegasus, long time ago I tested the performance in FSX using all 8 threads (HT on) so it was 4 cores / 8 threads.Performance, was ok, however every 30 seconds or so, I experienced terrible stutters, sound distortion, etc. After, countless hours of observation, I also noticed that actual FSX performance was 'exactly' the same, when using either all 8 cores or 3 (using affinity mask 12, which uses core 3 and 4, leaving Core0 for fiber work) so I decided to simply let FSX use the least ammount of cores, while maintaining the same performance. Now. I know some people will disagree.. and I completely understand their points, however, as a programmer, I can assure you that 'more' does not neccesarly mean (better) in multithreaded applications, specially if they are not optimized for > 4 cores, this is due to syncronization issues and the fact that having more threads running mean that the application will have a hard time trying to keep things in sync. So, in this cases, is better to find the 'sweet' spot.. even enterprise level apps won't perform optimally when using more than 4 cores, they will need to be specifically optimized for that. so, in short, my recomendation is to either use AffinityMask 14, or, if you trust my advice go with 12.FSX is (in fact) able to use all 8 cores, but they are good ONLY for terrain/texture loading. With FSX you don't want MANY cores running, but just a few running at FULL speed. 4.2 or higher.


Posted by bojote on 27 July 2010 - 02:55 PM in MS FSX Forum

DJJose, on Jul 27 2010, 07:14 AM, said:

[FSDREAMTEAM]AntiPopUp=100AltitudeCull=1Jesus,Does this help FSDT airports load without the initial slight pause?Thanks.

Yes it does, but it will not eliminate them. It will simply make them happen farther away from the airport.










Pegasus1, on Jul 27 2010, 05:26 AM, said:

On a normal 4 core (4 threads) machine AffinityMask=12 would lead in using physical core three and four. Why would you want that?

Because AffinityMask will NOT affect the actual fiber work going on in CORE0, meaning, that even though AffinityMask=12 instructs FSX to use only 2 cores (three and four), FSX is really using 3 cores: (that is Core0, Core2, Core3 to be exact)Fibers will ALWAYS run in Core0 regardless of your AffinityMask setting, so that means FSX will effectively use 3 threads/cores for the application. this threads will run: Fibers/Terrain + Main Scheduler + Texture Loaders If you use more than 3 cores, Fibers/Terrain and Main scheduler will NOT benefit from it, only the texture loaders will make use of those aditional cores, you can see this for yourself, simply use perfmon and select the right counters, log them and you'll see.Also, dont mess with the FFTF value... leave it at default, it won't impact anything if you run AffinityMask 12 or 14.Now, since you have HT on, for your particular case, the 'equivalent' of AffinityMask 12 would be the following:00 00 01 01 (the ones -1- represent the active threads) there is 8 digits in total, representing the 8 threads available.now, reverse it (binary numbers are read from right to left):10 10 00 00Now, change it to decimal:AffinityMask=160 (Equivalent to AffinityMask=12 with HT off)AffinityMask=168 (Equivalent to AffinityMask=14 with HT off)Don't worry, AffinityMask=84 and 168 are basically the same thing, the only change being 'which' thread is usded from the core (Primary or secondary)One more thing, I think you are worrying to much about the 'impact' this will have on performance... The real performance breackthrought in FSX is BP=0 -or- the alternative method (RejectThreshold) and if you have an ATI card the Shader Mod 3.0 (nVidia will not benefit much from the mod as ATI cards do) It's been aprox 2 months since the last time I tweaked anything on my fsx.cfg file, use it as a reference if you want and test it to see how your FSX performs.Cheers,




is it quite the same if HT is enabled and using AM=80 ? That's just my question I had :)

It should be the exact same thing.. however, having HT off also means you can run the cores MUCH faster because the reduced power requirements. Also, the explanation about fibers, Main scheduler and Texture Manager running different threads have been discussed at lenght by ex-aces members in the past, you'll have to search the forums and/or google it. I suggest you read Adam Szofran paper on terrain architecture, also check comments related to SP1 improvements and you'll see its all






there :)As for your question when only 3 physical cores are available, I would not touch AffinityMask under such scenario.




You have to explain that more detailed please, I don't understand this. If I log the several threads, I only see the load, but I don't know if Main scheduler or Texture Scheduler is running on a specific thread. How do you see that?

First, log it. then, graph it (realtime preferably) if you have a second computer, even better, you can monitor CPU usage remotely and this is what you'll see:Fibers:They are responsible for mesh terrain loading, they DO NOT load the actual textures, but the actual layout. Fibers need to work in sync with the texture managers, they can not multitask, they need to work in (co-operation with) the texture manager threads, meaning that the more TEXTURE manager threads you have, the higher the burden on the actual work for the fibers to do, specially in the 'sync/co-operation part'Main Scheduler:Basically EVERYTHING related to panels, Simconnect, AI, weather etc etc etc..Texture Manager:Autogen pre-batches every x minutes, texture loading based on the fibers work. This threads are responsible for the actual 'scenery loading' what you see out there, texture loading, autogen loadingNow, using the above explanation observe and you'll see how your different actions impact the threads in FSX.I suggest you use an external FPS limiter, limit your FPS to 25 this will allow you to better observe the Main Scheduler behavior. Fiber behavior will be dependant on the terrain surface. The most irregular the surface, the more work you'll see CORE0 doing. Texture Managers will be very active under situations where terrain resolution is <= 30cm and/or when flying over high density autogen areas.





fxs.cfg tweaks

Documents

buffer fsx

crash fsx

photo im

video card doesnt

command ring buffer

command buffer faster

cpu usage

video corruption