Jump to content
Sign in to follow this  
777simmer

GPU memory size and influence on VAS

Recommended Posts

Hi guys,

 

I have been doing some long haul flights to test my VAS usage.

Used Process explorer to monitor VAS during several flights.

 

During those flight my VAS steadily goes up by about 100Mb per hour.

(even if I do a holding at the same spot over default FSX scenery, VAS goes up from 2.5G. to 3.5Gb in 10hrs)

 

I dont like what I am seeing (VAS creeping up) yet I believe this behavior is normal.

(Word Not Allowed posted it is normal for VAS to keep rising as well)

Just how much VAS increases during a flight depends on how many and what addons you are using.

 

Recently someone commented to me that the size of GPU memory has an influence on VAS as it is "shadowed?" in VAS.

 

Is this true?

A 3Gb GPU has a higher VAS footprint than a 1Gb GPU regardless of what scenery you are flying over?

 

(I allways thought more GPU memory only increases its footprint on RAM, but not on VAS)

 

Thx.


Rob Robson

Share this post


Link to post
Share on other sites

Here's a post from Ryan a while back on the dangers of using video cards with large amount of onboard RAM. From what I have read the reason DX10 has eliminated OOMs for some, especially those who have 3gb or larger cards is that DX10 addresses the video memory differently than DX9 does. 

 

When I built my latest system I got a card with only 2gb of RAM knowing that I would most likely stick to using DX9. I've flown the T7 and NGX all over the world, sometimes leaving FSX running for 2 or three days in a row while in flight and never had an OOM. That's flying into addon sceneries like Dubai, LAX, JFK, etc., also with some photo scenery enabled in the scenery.cfg.

 

Ryan's quote comes from this thread, post 48-> http://forum.avsim.net/topic/349324-service-pack-better-be-good/page-2

 

 

 

Bert, How do the CTDs you're seeing happen? If they're completely random and happen out of nowhere they're almost surely the result of resource starvation in FSX (contiguous virtual address space) and not something we can really "fix". What are your system specs and what scenery addons are you running at the time when this happens? The basic background is that FSX is a 32-bit application and there's absolutely no way around the hard 4GB VAS limit. If it tries to allocate more than that or if it tries to allocate a large contiguous chunk and can't find unfragmented space for it, the sim is gonna CTD every time. It's the "physics" so to say of how applications work in Windows and DX9. Your video memory amount counts against the 4GB limit too because in order for FSX to address it, it has to be copied/shadowed into the application's VAS. We've had cases at support where people install 3GB video cards and the sim won't even run because it's sitting there with 1GB or less of addressable space after the video memory, which isn't enough to even load the sim and plane. If your crashes are a repeatable thing that's caused by doing something in the FMC or if it's the type of thing where the panel freezes but the sim keeps running, then it'll likely be solved in SP1. 

 

Sean Campbell


Avsim Board of Directors | Avsim Forums Moderator

Share this post


Link to post
Share on other sites

Here's a post from Ryan a while back on the dangers of using video cards with large amount of onboard RAM. From what I have read the reason DX10 has eliminated OOMs for some, especially those who have 3gb or larger cards is that DX10 addresses the video memory differently than DX9 does. 

 

When I built my latest system I got a card with only 2gb of RAM knowing that I would most likely stick to using DX9. I've flown the T7 and NGX all over the world, sometimes leaving FSX running for 2 or three days in a row while in flight and never had an OOM. That's flying into addon sceneries like Dubai, LAX, JFK, etc., also with some photo scenery enabled in the scenery.cfg.

 

Ryan's quote comes from this thread, post 48-> http://forum.avsim.net/topic/349324-service-pack-better-be-good/page-2

 

 

 

 

Sean Campbell

excellent info, thx a bunch!

 

(not good News, but good to know)


Rob Robson

Share this post


Link to post
Share on other sites

Here's a post from Ryan a while back on the dangers of using video cards with large amount of onboard RAM. From what I have read the reason DX10 has eliminated OOMs for some, especially those who have 3gb or larger cards is that DX10 addresses the video memory differently than DX9 does. 

 

When I built my latest system I got a card with only 2gb of RAM knowing that I would most likely stick to using DX9. I've flown the T7 and NGX all over the world, sometimes leaving FSX running for 2 or three days in a row while in flight and never had an OOM. That's flying into addon sceneries like Dubai, LAX, JFK, etc., also with some photo scenery enabled in the scenery.cfg.

 

Ryan's quote comes from this thread, post 48-> http://forum.avsim.net/topic/349324-service-pack-better-be-good/page-2

 

 

 

 

Sean Campbell

o.k. If I understand that correct than this means that FSX should not run with modern 4GB or 6GB cards in DX9 at all.

 

Is that true? Maybe someone with a Titan or R9 290x can comment on this.

 

I hope (and trust) that in P3D 2.0 this is no longer the case as it uses DX11.


IXEG 737 Beta-Tester and First Officer

i7 6700K@4.4GHz, 32GB RAM, Palit GTX 1080 GameRock Premium@2Ghz, Oculus Rift S, ButtKicker
X-Plane 11 latedt version on a Samsung M.2 SSD for speedy loading times

Share this post


Link to post
Share on other sites

In a 64-bit OS the effect of VRAM on a 32-bit app such as FSX is negligible.  If you look in device manager you will see vram located a couple of times in 128Kb blocks - hardly significant.  However it does impact significantly in a 32-bit OS.  Mark Russinovich (Google) explains this very well.

 

The reason that the OP is seeing a rise in VAS usage has little to do with his/her video card - Phil Taylor on his FSX blog talks about this in great detail.  As FSX runs longer the VAS becomes more and more defragmented and the contiguous space fro FSX to load into becomes less and less - and in VMMAP that will show as an increase in VAS usage.  Eventually under certain circumstances even in a 64-bit OS you may get an OOM.

 

The statement above, I presume, refers to a 32-bit OS because there is little impact by the video card in a 64-bit OS eg Win 7 which has up to 8 TERABYTES of VAS to load into and can utilise any amount of VRAM without impacting on the 4GB VAS allocated to FSX.  Ryan's post is also out of date since WDDM v 1.1.

 

If there was any effect in a 64-bit OS by the VRAM on FSX using a video card with 4GB VRAM then FSX would never start it would be impossible as it would have NO VAS to load into.  Multiple and large monitors would also be out.

 

This has nothing to do with physical RAM installed.

 

PeterH

Share this post


Link to post
Share on other sites

As far as I understand the difference with DX9 vs DX10 is that DX9 requires to keep a copy of the information that's sent to VRAM in the regular RAM as well, eating up VAS, while DX10 doesn't need the copy in the RAM, it just moves the information.

Share this post


Link to post
Share on other sites

As I said in another post:

I don't believe that [graphics card total memory counts against VAS] is the case. A graphics card is a separate computer with its own processors and memory. there is no reason why FSX should need direct access to all the graphics card memory.

This view is supported by bhollis of Lockheed Martin said on the Prepar3D forum "a high end 2 GB card will likely run better than a low end 4GB card". The implication is that a high--end 4GB card would be even better.

Prepar3D (like FSX) is a 32-bit application which has a maximum of 4GB VAS on a 64-bit system. If all the graphics card memory counted against VAS then a 4GB would use it all and FSX/Prepar3D couldn't run at all. A 3GB card would leave only 1GB. A 2GB card would leave 2GB VAS which is the unsatisfactory amount FSX had on a 32-bit system.

 

Share this post


Link to post
Share on other sites

In a 64-bit OS the effect of VRAM on a 32-bit app such as FSX is negligible.  If you look in device manager you will see vram located a couple of times in 128Kb blocks - hardly significant.  However it does impact significantly in a 32-bit OS.  Mark Russinovich (Google) explains this very well.

 

The reason that the OP is seeing a rise in VAS usage has little to do with his/her video card - Phil Taylor on his FSX blog talks about this in great detail.  As FSX runs longer the VAS becomes more and more defragmented and the contiguous space fro FSX to load into becomes less and less - and in VMMAP that will show as an increase in VAS usage.  Eventually under certain circumstances even in a 64-bit OS you may get an OOM.

 

The statement above, I presume, refers to a 32-bit OS because there is little impact by the video card in a 64-bit OS eg Win 7 which has up to 8 TERABYTES of VAS to load into and can utilise any amount of VRAM without impacting on the 4GB VAS allocated to FSX.  Ryan's post is also out of date since WDDM v 1.1.

 

If there was any effect in a 64-bit OS by the VRAM on FSX using a video card with 4GB VRAM then FSX would never start it would be impossible as it would have NO VAS to load into.  Multiple and large monitors would also be out.

 

This has nothing to do with physical RAM installed.

 

PeterH

Thx for that very informative reply.

 

In the mean time another knowledgable, well known hardware/FSX source has confirmed that GPU memory is not mapped or shadowed in VAS when on Win7!

 

quote

Driver model was changed with Vista SP1/Windows7 and GPU memory is not mapped like it was with XP

 

VAS creeping up as the flight continues is normal. Time + scenery/aircraft is your enemy with FSX

unquote.

 

So the info and links above must have been old (its from 2011).

 

I am sorry for the confusement, but with one saying this and another that I decided to do some digging/asking around.

 

For me it is now a fact that GPU memory is NOT mapped in FSX VAS when you use above mentioned OS!


Rob Robson

Share this post


Link to post
Share on other sites
Guest

 

 


VAS creeping up as the flight continues is normal.

 

I'm not sure I'd call that normal ... lets just say I'll disagree with Phil T. on this one ... with proper GC implementation the fragments can be recovered an organized so as to keep total VAS reduction at a minimum (still fragmentation but it will not grow excessively).  My hunch is FSX had too much legacy code or the design just didn't make it possible or desirable to implement GC (garbage collection) and/or performance considerations.  But if this were "normal" then 64bit games like Crysis 3 with 4096 textures would eventually consume all my RAM after a few hours ... this has never happened to me ... also think there are some mods out that push textures to 8192 for Crysis 3 (not sure how playable they are).

 

There definitely IS a fragmentation problem in FSX, easy to demonstrate - simply allow 4096 textures, load up an airport and/or aircraft that uses 4096 textures and then set a high LOD (9.5 or 11) and sit and do nothing and watch the VAS get consumed within a few minutes and OOM.  Now keep the same LOD and use 1024 textures and do nothing and the VAS will not get consumed and will stabilize (the smaller texture sizes aren't causing as much fragmentation).  IMHO, this is a clear demonstration of a fragmentation problem.  And like I said, there are solutions to fragmentation problems, they just aren't in FSX.  And I may not actually be in conflict with Phil's statement, as I'm sure he knows there are solutions but those solutions could be governed by time constraints, code compatibility, design constraints, and more which may have made it impractical to implement changes in FSX.

 

Texture size will contribute to VAS usage but it's still very much a function of software and how it's coded.  AA will not use VAS but it will use VRAM (vary based on the types of AA used and resolution).

 

So to answer the question, 4GB VRAM can use up all your VAS if the software is coded to do so.  The max VRAM usage I've seen FSX use just before it OOMs (>4GB VAS) was around 1.6-1.8 GB (VRAM).  But because you have 4GB VRAM on your video card doesn't mean VAS is automatically used/allocated by the software, but it will allow the software too run out of VAS because the VRAM is available.  I hope that makes sense.

 

Rob

Share this post


Link to post
Share on other sites

Rob

So to answer the question, 4GB VRAM can use up all your VAS if the software is coded to do so.  The max VRAM usage I've seen FSX use just before it OOMs (>4GB VAS) was around 1.6-1.8 GB (VRAM).  But because you have 4GB VRAM on your video card doesn't mean VAS is automatically used/allocated by the software, but it will allow the software too run out of VAS because the VRAM is available.  I hope that makes sense.

 

Sorry Rob - That can't happen there is no connection between VAS and VRAM in a 64-bit OS. 

Its the cpu that deals with the Video card sending data that has already been processed -  so the VAS doesn't know or care what's happening with VRAM. 

The problem with VAS in FSX has always been loss of contiguous space and defragmentation and that's caused by the way it has been coded and how it interacts with the OS then to the cpu and the working set.

 

The VRAM and physical RAM are part of the hardware and neither has a direct link to the VAS which is part of the OS.

pH

 

 

Share this post


Link to post
Share on other sites
Guest

 

 


Sorry Rob - That can't happen there is no connection between VAS and VRAM in a 64-bit OS. 
Its the cpu that deals with the Video card sending data that has already been processed -  so the VAS doesn't know or care what's happening with VRAM. 

 

No connection at all ... could you clarify?  VAS is virtualized but at some point their is a managed reference to the physical (managed by the OS).  There has to be a connection at some point?  

 

In my experience, increasing texture sizes from 1024, 2048, 4096 has increased VAS and VRAM usage.  

 

Would like to understand your comment better.  But agree my wording is perhaps lacking.  Completely agree that FSX fragmentation is a result of how it was coded.  

 

Cheers, Rob.

Share this post


Link to post
Share on other sites

Very interesting thread, so am I correct in saying I can go and buy a 780 GTX 4 GIGS and run it on my windows 7 64 bit without causing any issues with VAS (Running DX10 and based on what I just read above)

 

Regards
Wayne


Wayne such

Asus Hero Z690, Galax 3080 TI, I712700K, Kraken x72 CPU Cooled, 64 GIGS Corsair DDR5, 32 Inch 4K 

Share this post


Link to post
Share on other sites

I agree with everyone regarding 64 bit operating systems, the whole issue with V ram dates back to when the bulk of simmers had a 32 bit OS. I remember when I had to pick my cards carefully due this limitation, with Win7 64 bit no issues.


Rob Prest

 

Share this post


Link to post
Share on other sites

Very interesting thread, so am I correct in saying I can go and buy a 780 GTX 4 GIGS and run it on my windows 7 64 bit without causing any issues with VAS (Running DX10 and based on what I just read above)

 

Regards

Wayne

Yes. I am sure there are many out there today that use a 3Gb or 4Gb GPU but do not use 3Gb or 4Gb VAS right at startup of GSX.

Rob Robson

Share this post


Link to post
Share on other sites

If defragmentation amd carbage collection is the problem then it sounds we need something like TRIM for FSX.

 

can this be done?


Rob Robson

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