VAS usage

[TrentXWB 20]

Fellow simmers,

 

I have an interesting finding, if I can call it that. I have been monitoring the VAS usage and interestingly when I fly and then Minimize the FSX window My VAS usage is stable, not growing to reach OOM, but If I let the window stay unminimize the for sure it will reach OOM. So to do a complete flight I need to climb until ToC and minimize FSX window and then after reaching ToD I continue the flight

 

I have tried it with both window mode and full screen.

 

My specs are 

i7 2600K @4.1 Ghz

Asus ATI 7870, latest driver (not beta)

8 Gb RAM @ 1600Mhz

 

Software during the test:

FSX with DX 10

PMDG T7

Opus

FSDT: KJFK, CYVR, KORD

REX

FTXG

 

FSX cfg:

Highmemfix=1

TEXTURE_MAX_LOAD=1024

AffinityMask=84

UsePools=1

PoolSize=100000000

 

Do you guys think there is something missing in my settings/config? Has anyone notice the same performance/issue

 

Thanks

Hendrik

[TrentXWB 20]

additional info, AI traffic :70%, road : 9 %

[Paul J 349]

 

 

Do you guys think there is something missing in my settings/config?

  

 

Yes - the rest of your settings, Hendrick! It's not possible to accurately assess your question without knowing what ALL of your pc hardware looks like, including overclocks. You need to put this in your User Profile - this will then make it appear under your Avatar pic at left. Once you do that - then copy your fsx,cfg, rename the copy as "Hendrik_fsx.txt" and then attach it to the reply, using the "More Reply Options" at the bottom-right corner of the posting window. A shot of your RadeonPro would be good, too, but others would need to comment on that as I've been an Nvidia guy for a while now.

 

Wrong - yes - your [bufferPool] number of 100000000. These are bytes, which will make 95.36743164063 MB - not a very "round" computer size, nor is it very useable as a buffer, as 10 buffers at that size will take up almost 1 GB of allocated vram. FSX will want much more than 10 buffers.

 

 

 

Has anyone notice the same performance/issue?

 

To give this kind of answer demands "apples vs apples", so - we only have a piece of your apple right now. There are probably lots of reason combinations that will cause your symptom.

 

Regards,

 

pj

[TrentXWB 20]

I'll update my information later on today since I'm about to leave now. But I did another testing in DX9 and VAS did not increase at all.. I know it sounds dodgy but it is what I am experiencing. 

 

I am not using radeon Pro just CCC 

 

Thanks.

hendrik_FSX.txt

[Paul J 349]

Hi Hendrik: 

 

[TrafficManager]
AirlineDensity=0
GADensity=0
FreewayDensity=0
ShipsAndFerriesDensity=0
LeisureBoatsDensity=0
IFROnly=0
AIRPORT_SCENERY_DENSITY=3
 

but in your previous post you say :- AI traffic :70%, road : 9 %

 

I guess it doesn't matter which is correct. 70% AI is far to high for your rig.

 

My recommendation would be for you to use 4x - or 8x CSAA at the most in the DX10 Fixer, then set the RadeonPro  (not CCC) settings in accordance with those recommended by Charles Earl here:

 

Here's the fsx.cfg with some changes, the biggest being AA MSPP and quality settings:-

 

hendrik_FSX_chgd.txt

 

I hope this helps!

 

pj

 

 

 

 

[TrentXWB 20]

Sorry Paul,

 

Before I posted this I did another test with AI at 70 and AI at 0

 

Im gonna give it a try of the new CFG file and report back

 

Thanks

[TrentXWB 20]

Sad to report that the changes in CFG file does not help.

[Paul J 349]

Are you using RadeonPro?

[TrentXWB 20]

Sorry Paul for the very late reply. Was very busy the last days.

 

Yes I am using Radeon Pro now and followed the guide from Charles.

 

I'm stuck with DX10

[MrRoper 27]

 

Wrong - yes - your [bufferPool] number of 100000000. These are bytes, which will make 95.36743164063 MB - not a very "round" computer size, nor is it very useable as a buffer, as 10 buffers at that size will take up almost 1 GB of allocated vram. FSX will want much more than 10 buffers.

 

Hi Paul,

 

I dont think this is correct, FSX will only create vertex buffers when it cant find space in any existing buffer within the pool, In-fact I run DX9 with a buffer pool of 100MB  and never see my VRAM go above 1GB in 3rd party scenery with Dense / Very Dense autogen.

 

In my testing it is obvious that a Large buffer pool performs better than many small pools. I do appreciate however that this might not be the case in DX10

[Paul J 349]

Hi Chris:

 

While I am, for sure, no Guru on BP - but I have studied the differences between DX9 and DX10 graphics, and how the system works in order to come up with the BP doc, and to date no-one has offered to correct any "wrongness" which may exist therein. I have to say, too - I am fully open to having the BP doc studied and corrected if necessary. It wouldn't be the first time I've been wrong in this or any other chunk of my life!

 

FSX will only create vertex buffers when it cant find space in any existing buffer within the pool

    

 

Correct: and this all assuming that FSX is managing the bufferpools. i.e . UsePools=1. FSX will create and fill that first buffer, (2MB here)

( 3DDevice::CreateVertexBuffer BUF1 2097152 520 0 0  )

( 3DDevice::CreateVertexBuffer BUF2 2097152 520 0 0  ) .... etc....

 

  then create a new buffer, BUF 2, and proceed to fill that one, and as many more as needed, static and dynamic, along with index buffers for same. In doing this with 100MB buffers FSX and/or the gpu (DX9 or DX10) has to contend with managing that volume of data in each buffer. 100 MB can contain a huge volume of vertex data, and I can only say that on your system (because everyone's system is different, and is configured differently, with thousands of different preferences) you are not very demanding in your "graphical needs", otherwise you would likely experience VRAM OOM's. I don't personally care about, or monitor VAS or VRAM. If I run out of VRAM the screen will tell me pretty quickly, and only with the earlier < 1GB vram GPU's and DX9 did this ever happen.

 

 

 

In-fact I run DX9 with a buffer pool of 100MB  and never see my VRAM go above 1GB in 3rd party scenery with Dense / Very Dense autogen.

Again - correct - DX9 shares its graphics memory and manipulation algorithyms with the CPU. With DX10, this is no longer the case.

 

 

 

From ACES Raf:

 

 

In RTM, the default setting was 1MB (1000000).  The lower this number, the more pools the allocator will have to rummage through to find space for buffers and the more stutters you may have.  In Sp1, we raised the default to 4MB (4000000) and optimized the underlying algorithm for finding free buffers

So be careful here, making this smaller can hurt you, since searching for space takes time and can cause stutters, and making the number too large can waste space. 4-10m is probably the range to be thinking about using unless you have a very high memory graphics card (  >512 )

 

In SP2 this was raised again to 8MB. 

 

When pushing the onus on the GPU to manage the buffering (UsePools=0) - you will find the GPU creates thousands of very much smaller buffers - most are dynamic, and most in the order of a couple of hundred kB each - not even a MB! Because the GPU manages the graphics buffers (UsePools=0) - not FSX (UsePools=1) the system will experience a modest performance gain.

With the advent of DX10 - all graphics processing is done on the GPU, and, if it's sufficiently fast enough, and its' memory large enough that it won't stall - then there's an even greater performance gain by using UsePools=0.

 

BUT!  Given that you have not posted your system's specs, configurations or testing, Chris, I'm not going to argue about your experiences with your system - If you find that 100MB buffers work - then more power to you!

 

All the Best,

 

pj

[MrRoper 27]

 

 

While I am, for sure, no Guru on BP - but I have studied the differences between DX9 and DX10 graphics, and how the system works in order to come up with the BP doc, and to date no-one has offered to correct any "wrongness" which may exist therein. I have to say, too - I am fully open to having the BP doc studied and corrected if necessary. It wouldn't be the first time I've been wrong in this or any other chunk of my life! then create a new buffer, BUF 2, and proceed to fill that one, and as many more as needed, static and dynamic, along with index buffers for same. In doing this with 100MB buffers FSX and/or the gpu (DX9 or DX10) has to contend with managing that volume of data in each buffer. 100 MB can contain a huge volume of vertex data, and I can only say that on your system (because everyone's system is different, and is configured differently, with thousands of different preferences) you are not very demanding in your "graphical needs", otherwise you would likely experience VRAM OOM's. I don't personally care about, or monitor VAS or VRAM. If I run out of VRAM the screen will tell me pretty quickly, and only with the earlier < 1GB vram GPU's and DX9 did this ever happen.

 

Hi Paul,

my response was in no way an attempt to prove any wrongness in your document , just to point out that FSX (Certainly in DX9) will only create vertexbuffers when using a "managed" pool when it cannot find any room in any existing tracked dynamic VertexBuffer, and that it is much quicker to search and track one large buffer than many small buffers.

 

While this could result in memory waste, at the most this waste will only be (100MB - vertex data size) if our buffer pool setting was 100mb. The real way to balance this is to use Intel GPA to track VertexBuffer usage depending on settings and set the bufferpool size accordingly.

 

The reason I rather do this is so that I don't have to run my water at 2xHigh that is required when not using a shared buffer as i found the FPS hit to be quite high ( I appreciate that this is not needed in dx10!)

 

There are a few caveats to this, I run quite an aggressive RejectThreshold that means that the majority of objects are given dedicated vertexbuffers which lowers the usage of the shared buffer(s) and I also have quite a powerful machine (ivybridge at 4.5ghz and a GTX 780)

 

Regards

Chris

[Paul J 349]

Hmmm.. No problem, Chris: reading responses like yours is great, because always promts a re-evaluation of earlier conclusions - which can be wrong, or can be misunderstood easily on a forum, and with an answer which is insufficiently clear. I'm 100% sure that not many folks understand buffers, and while being greatful to Bojote for his pioneering research - his original posts were not as "correct" as Steve's "hands-on" documentation has shown. Steve's blog is very clear, and my own dabbling has merely borne out his documentation.

 

"use Intel GPA to track VertexBuffer usage" - yes, this is the way to see the evidence, and understand how the system responds for sure.

 

I run water at 5 or 6 without penalty, Chris, but - given a 780 and a "relatively slow" (see note below) processor - why would you not run UsePools=0 and let the 780 run free? I suspect you wouldn't have a water problem unless there's something else going on in your pc. The early Bojote mantra that the ground flashing which resulted from UsePools=0 isn't there when using DX10. Are you running DX10?

 

 

"and that it is much quicker to search and track one large buffer than many small buffers."  True - when FSX is doing it - but you have a 780, and that beast will search and find far faster than FSX can supply data.  If you had a 580 instead of the 780 - using UsePools=1 and a small RT makes sense, and this worked for me, too, but when the 780 went in - within a week it became UsePools=0.

 

"Note below"

My remark about the "relatively slow" processor is based on the FSX architecture being more suited for single-thread computing and is not a 100% multi-threading application. It think the SB at 4.8 - 5.0+ yields a much higher FSX performance than does the IB. I've seen a number of folks claim that the IB at 4.6 is the equivalent of a SB at 5.3+. It may be, if one is interfacing a browser-based, multi-threaded, multi-user business application as a front-end to an Oracle database. But this is FSX.

 

Anyway - good subject, and interesting to get another viewpoint!

 

All the Best,

 

pj

[MrRoper 27]

Hmmm.. No problem, Chris: reading responses like yours is great, because always promts a re-evaluation of earlier conclusions - which can be wrong, or can be misunderstood easily on a forum, and with an answer which is insufficiently clear. I'm 100% sure that not many folks understand buffers, and while being greatful to Bojote for his pioneering research - his original posts were not as "correct" as Steve's "hands-on" documentation has shown. Steve's blog is very clear, and my own dabbling has merely borne out his documentation.

 

"use Intel GPA to track VertexBuffer usage" - yes, this is the way to see the evidence, and understand how the system responds for sure.

 

I run water at 5 or 6 without penalty, Chris, but - given a 780 and a "relatively slow" (see note below) processor - why would you not run UsePools=0 and let the 780 run free? I suspect you wouldn't have a water problem unless there's something else going on in your pc. The early Bojote mantra that the ground flashing which resulted from UsePools=0 isn't there when using DX10. Are you running DX10?

 

 

"and that it is much quicker to search and track one large buffer than many small buffers."  True - when FSX is doing it - but you have a 780, and that beast will search and find far faster than FSX can supply data.  If you had a 580 instead of the 780 - using UsePools=1 and a small RT makes sense, and this worked for me, too, but when the 780 went in - within a week it became UsePools=0.

 

"Note below"

My remark about the "relatively slow" processor is based on the FSX architecture being more suited for single-thread computing and is not a 100% multi-threading application. It think the SB at 4.8 - 5.0+ yields a much higher FSX performance than does the IB. I've seen a number of folks claim that the IB at 4.6 is the equivalent of a SB at 5.3+. It may be, if one is interfacing a browser-based, multi-threaded, multi-user business application as a front-end to an Oracle database. But this is FSX.

 

Anyway - good subject, and interesting to get another viewpoint!

 

All the Best,

 

pj

Hi Paul,

 

No I don't run DX10, mainly due to issues with heavy cloud and stutter which I have not resolved as yet and as you said in DX10 the issue with corrupt objects is not apparent and I would be able to run a lower water setting and turn off shared buffer pools.  However I can demonstrate easily the cost of running High water (In DX9) as the FSX engine has to render the scene twice so that it can apply the reflection textures to the water.

 

I appreciate that as a DX10 discussion this was probably off topic as my case is particular to DX9, just wanting to point out that a "BufferPool" is just a large VertexBuffer with many objects in it as apposed to bypassing the bufferpool which is just lots of VertexBuffers with an object in each

 

And I agree its a very interesting subject