no  its manly used for missing  textures in aircraft I believe

No, no, no, no, no! Don't tweak affinity mask.

Have to disagree. From a software technology point of view, there are a lot of reasons to tweak affinitymask in fsx if you have more than 4 cores and hyper threading enabled. Also you can go without buffers if core #0 (ht enabled #0+#1) is not used in fsx. Just try a clean scenario with and without affinitymask. I get about 5fps more standing at a gate (with a total of 30-35fps in KJFK) and in air it's fixed with fsx limiter @40fps.

 

But it could be a chance to eliminate the freezes... at least it's a try worth I think.

Also you can go without buffers if core #0 (ht enabled #0+#1) is not used in fsx.

 

What do you mean with this?

Buffers?

As in bufferpools?

 

But it could be a chance to eliminate the freezes... at least it's a try worth I think.

Yes absolutely!

I'm still waiting to find out how many benefit from HIGHMEMFIX=1. Since it never improved performance when it came out in the first place, it would be odd to find it magically does something now. Originally allowed more than512Mb textures and so some parts of an aircraft may be missing. After more testing on DX9 and DX10 I was surprised to find HIGHMEMFIX=1 used on average around 150Mb to 200Mb more VAS.

 

Bufferpools and FFTF are tools the DX programmer can use to profile the code. Fixing these settings may improve performance for a particular scene, but ultimately the scene changes constantly during a flight.

No, bufferpools is like this: pools = caches. New calculations needn't to be made as they're available.

 

Highmemfix does only give fsx much more memory to with textures on gpu than used than usual (fsx was programmed decades ago!).

Exactly, then the scene changes and recalculate. The difference with HIGHMEMFIX=1 on a modern card which has no texture restriction, is only a slight change in memory layout during transfers, which results in slightly more VAS used, for no improvement in performance, However stutters are introduced during new texture loading, like the example with lightening as I mentioned earlier. I would avoid HIGHMEMFIX=1 for this reason. Don't get me wrong, I'm always testing tweaks on all my new machines. It's an absorbing game and addictive. Unfortunately I've never seen a mod that can improve performance, whereas knocking LOD RADIUS or AUTOGEN down a notch always does, what some tweaking utilities sneak in to show an apparent magic gain in performance. The best boost has always been to get a new PC.

 

Talk about lod radius and autogen; another recommended setup shown in the docs is to lower autogen and set max lod. However with this aircraft I prefer to set lod radius lower and keep max autogen since I'm not spending much time near the ground.

Steve,

 

I have just completed a short test flight at an airport where the FSUIPC "chimes" kicked in on the downwind leg. This is with the "HIGHMEMFIX=1" statement added to the fsx.cfg file. Curiously, I did not notice this during similar recent test flights at the same airport (using the same plane....PMDG 737NGX, and without that statement in the fsx.cfg file). I will run that test again with the HIGHMEMFIX statement removed (everything else exactly the same), and see what happens. I will completely shut down the PC first to make sure that the test is as close to accurate as possible.

This might explain why we have different results with HIGHMEMFIX.

 

quote:

[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, it will completely prevent textures, buildings and entire cockpits from disappearing! This 'bug' is triggered when there is a high video memory usage situation.

unquote:

 

I have a Nvidia GTX680 with 3GB memory.

You?

 

 

 

Got that info frome here:

http://www.sim-outhouse.com/sohforums/showthread.php?34661-Thank-you-*******-*******-Altuve-that-is-*-FSX-Important-*

I completed the same test with the "HIGHMEMFIX=1" statement removed from the fsx.cfg file, but the results were inconclusive. What I can say is that I only heard two FSUIPC "chimes" during this second test flight (the first one on the downwind leg at roughly the same time as the first test, and the next one when levelling out for final approach). This contrasts with the several "chimes" that I heard during the first test, including shortly before touchdown, and also when turning off the taxiway. In addition, the first test (the one with the HIGHMEMFIX statement enabled) exhibited missing textures at the end of the runway, and also on the apron (which I assume could be a sign that I was slightly closer to the VAS limit during this test).

 

I suspect that this may indicate a slight increase in VAS usage with HIGHMEMFIX enabled, but it is not definite. However, further test flights with HIGHMEMFIX active seem to suggest that it has solved (or at least reduced) my "black skies" problem. Test flights at EGNS Ronaldsway airport using the ES Isle of Man scenery package and PMDG 737NGX always resulted in a black sky texture if I turned my head to look at the airport on the downwind leg prior to activating the HIGHMEMFIX statement, but when I tried this with the statement added to the fsx.cfg file, I did not have any problems. This would seem to suggest that Rob's comment about it preventing textures from disappearing during high graphics load is correct.

 

My graphics card is a 1GB GeForce GTX 560Ti.

 

 

I would avoid HIGHMEMFIX=1 for this reason. Don't get me wrong, I'm always testing tweaks on all my new machines.

But Steve, Highmemfix is a fix, not a tweak. it was left out in error by M$. it really is an essential fix, and would not fly without it.

The "fix" was to allow some (way) older GPUs to load more than 512Mb textures. What it does now is allow a flood of texture information rather than a smooth feed of textures, that's why we see the drop in frames and the stuttering with the fix with the lightening example I showed. There is a "small" increase in VAS used as Christopher found out, but unfortunately his system is operating near the VAS limit and so the results will be inconclusive. What you get is stutters and run into the VAS limit earlier with HIMEMFIX=1 - it's that simple.

Of course you run into the VAS limit earlier with HIGHMEMFIX if a bunch of textures do NOT dissapear anymore!

 

No HIGHMEMFIX=dissapearing textures=less VAS !

 

Something is seriously wrong with your PC if HIGHMEMFIX causes stutters.

My PC stays smooth as silk WITH highmemfix, 30fps locked internally and 1/2Vsync in Nvidia Inspector.

Note that Christopher had several textures not appearing with the fix - these are inconclusive tests. The VAS measurements I've been making uses a tool that runs outside of FSX, FSUIPC VAS chimes are OK but that runs inside FSX and consumes 400Mb of VAS, my testing does not alter the VAS.

 

Something is seriously wrong with your PC

Respectfully, you're the one experiencing freezes - I'm not.

Nope, no freezes here, OPUS on core 1,2,3 and fixed, no idea what you are talking about.

 

FSUIPC using 400MB VAS??

 

not on my PC it doesnt....I am telling you, you have a problem with your PC!

I haven't noticed any additional stutters with "HIGHMEMFIX=1" enabled.