Can someone translate to plain English for me?!? :LMAO:

 

Don't worry, we will...later.

 

Yes, that is true and easy to check observing how VAS allocation grows while flying from default FSX low urbanized area to dense custom airport scenery with large amount of 3D objects and textures located in highly urbanized area.

 

The problem with that observation is that we don't know how much of that memory is used by the scenery engine for other non-GPU related things. But the difference between DX9 and DX10 VAS usage in the exact same situation is an indication.

The problem with that observation is that we don't know how much of that memory is used by the scenery engine for other non-GPU related things.

 

I think that nearly 100% of resources loaded into VAS during flight are GPU related (DEM, terrain textures, autogen geometry and textures, scenery objects geometry and textures, clouds geometry and textures, traffic objects). What can be excluded - flight model data but it is constant during flight. AI flight data amount is very small, the same with ATC data).

My understanding is that the WDDM (in vista/7) VMM controls how the VRAM is allocated, and is virtualized. Also D3d9 calls are what cause the VMM to actually allocate VRAM to FSX. Since Vista sp1 the WDDM VMM is "smrter" about how it alocates VRAM and this has an impact on amount of FSX VAS needed by the graphics. I also think WDDM 1.1 (Win7) made some changes in how VRAM/shared system RAM is reported making it easier to see what actual VRAM is being used.

 

I would think as a minimum, when testing you need to determine the actual VRAM allocated for FSX first and then look at what FAX VAS allocation there is to support it. I thnk maybe ProcExp will show that (VRAM usage).

 

scott s.

.

Scott, thanks for the suggestion. I'm gonna include process explorer in the tests. Do you know how the columns "GPU System Bytes", "GPU Dedicated Bytes" and "GPU committed Bytes" can be interpreted?

What a great post Tom, thanks for all the hard work.

I did some tests too (nothing that compares to this but still), with Process Explorer and never saw a measurable impact on VAS.

I'm pretty sure It has nothing to do with 32b OS's cause I tried on a fresh W7 32b install + 3GB switch with the same results of VAS usage than in 64b.

I tested my 2xGTX480 SLI, my current GTX580 and a HD5450 and the VAS usage was pretty much the same with any of those GPU configs.

I think I read somewhere that the VRAM that's kept in the app VAS in DX9 is what the app reserves or something like that, not what's in use for the driver to run AA and stuff like that. It's certainly not all of the GPU VRAM. You don't get your VAS limit cut down to 1GB with a 3GB GPU

I keep seeing statements that if you're running a 64bit OS that the OS/Kernel is no longer addressed into the 32bit application's memory block. I'd like to see empirical information regarding these statements.

Yeah, I dont think that statement is true at all.

Hey everyone!

I know it's been a long time since I wrote the last post, but I was tied with so much work for almost a year that I couldn't find the time to touch a sim until know. But I didn't forget about the tests I promised to run (also because they were completed half way a year ago), so here are the final results:

 

Test Setup
Same as above. I only decided to use the GPU's default graphics driver settings instead, not the custom one that I set in NVidia Inspector the last time.

In addition to the numbers recorded in the last test, I also recorded from Process Explorer the following values:
- GPU System Bytes
- GPU Dedicated Bytes
- GPU Committed Bytes

Process Explorer captures these values on a per-process basis, however I've been unable to get a meaningful explanation what these numbers actually mean (discussion is here in case you are interested). I decided to leave the numbers in the results, but won't try to interpret them.


Okay, so here come the test results:


Test Series A1/2
Running with DX9, I set VideoMemoryOverride(VMO) again to 1G in FSX.cfg, with AA/AF turned on in FSX's display settings (A1 tests). Then I lowered the VMO to 0.25G (A2 tests) with all other settings unchanged.

As observed in the previous tests, VAS usage was rather unaffected by the change in the VMO setting. So is VRAM usage as recorded by NVidia inspector. The GPU memory values recorded by Process Explorer are slightly lower, but like I said: I don't know what they mean. I think these lower readings have some other reason, because in later tests they did not change significantly.


Here's a screenshot from one of the tests in the A1 series to demonstrate a test result:

Test Series B1/2
This time I turned AA/AF off in FSX's display settings and then ran the same tests with VMO 1G and 0.25G respectively:



VRAM usage recorded by NNidia inspector was about 50-60M lower compared to the tests with AA/AF turned on. This also applies to the values recorded by Process Explorer.
Again, the change in the VMO setting did not affect VAS usage between tests B1 and B2 did not have any significant impact on VAS usage.


DX10 Tests

Following are the tests with VMO 1G/0.25G and AA/AF on/off:

Like in the first tests a year ago, VAS usage in DX10 was again much lower than with DX9. But again no significant difference between the VMO settings. VRAM usage is about 150M higher compared to DX9. The difference in VRAM usage in DX10 between AA/AF on and off is about 80M.

Concluding Remarks
These tests didn't really bring any new insights. To me it seems that the VideoMemoryOverride setting in FSX.cfg is simply ignored.

 

Finished? Not yet!
I didn't want to give up so early, since tabs mentioned the setting in display.cfg, I thought they might work there. So removed the VMO settings from FSX.cfg and added instead an entry for my graphics card with the PCI vendor and device IDs in display.cfg like so:
 

;----------------------------------------------------------------------
; NVidia GeForce GTX 460 SE
;        override to 0.25G memory
;----------------------------------------------------------------------
[000010DE:00000E23]
VideoMemoryOverride=268435456

Then I ran the tests VMO=0.25G in display.cfg again.
Long story short: the VMO setting had again no impact on VAS usage. For sake of completeness, here are the results comparing results with the display.cfg setting to the FSX.cfg setting:

 

 

So what's the deal with the VideoMemoryOverride setting in display.cfg?
After I finished the tests, I read that display.cfg is basically just a template for the default settings applied to FSX.cfg when it is generated (too bad I hadn't read that before, I would have saved so much time...).
To find out what happens with VideoMemoryOverride when it is changed, I deleted FSX.cfg several times to have it regenerated using different values of VideoMemoryOverride.

And yes, the presets in FSX's display settings did change. But that's pretty much it! The VideoMemoryOverride switch never got transferred from display.cfg to FSX.cfg. It's simply an indication for FSX how high or low other display settings should be set when creating the initial configuration.

Conlusion
Forget VideoMemoryOverride !  ^_^