Jump to content
Sign in to follow this  
tom79

VideoMemoryOverride: Does it really work?

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

vastesta.png

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:

fsxmemvmo1gdefdrv125m.th.png


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:

vastestb.png

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:

vastestc.png

vastestd.png

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:

 

vasteste1a2.png

vasteste2b2.png

 

vastestf1c2.png

vastestf2d2.png


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 !  ^_^
  

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...