I've installed a registered copy of FSUIPC5 for P3Dv4 and using the same offset to display VAS an in v3. According to the manual the same offset should work.

However it is just displaying 0.

Does anyone have this working and if so can you please post the full offset details and how you got it working.

p.s. Please don't tell me I don't need to worry about VAS. I'm just curious to see what the figure is :-)

 

Neither of the two VAS offsets work, because they are based on 32 bit calls.

I'm not sure, but this might be intentional on the developers part

 

I say that as with the shift to 64bit, it seems that Chaseplane as stopped reporting VAS usage. Moving from an specific VAS count, to  a rather funny "Smiley Face" when running V4, as if to indicate "don't worry be happy".

I agree that it would be ideal to know the current count regardless of 64bit

P3DV3 Chaseplane

P3DV4 Chaseplane

Edited June 4, 20179 yr by Nicodemus
fixing layout

Okay. Thanks guys. Very helpful info.

I'll post on Pete's forum to see if he is intending to make it work.

Think about it - the old program dealt with 4K VAS. It read the mem used and subtracted from 4k and displayed the remaining.

Since 64bit can address exabytes of VAS do you really think it would be a meaningful figure to display one billion gigabytes remaining?

Maybe down the road Pete can just display memory used just for the curious although there are many other ways of getting that figure available.

 

Vic

You can use for example the utility Process Explorer (https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx) to check for VAS or memory used. But VAS is more or less useless to know, 64bit v4 uses 75-85GB of VAS when I'm checking.

7 hours ago, touchdown84 said:

You can use for example the utility Process Explorer (https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx) to check for VAS or memory used. But VAS is more or less useless to know, 64bit v4 uses 75-85GB of VAS when I'm checking.

I wouldnt say that, since its 64 bit all the addon developers can put more into there products for the sim that still takes up VAS. You start out with 16GB, with the regular same addons as P3D V3. getting umm lets say 65% of 4GB of VAS usage. Thats probably roughly 2000+ MBs. By the end of the flight you have close to 85% to 90% maybe a little lower. Heres the thing developers have had to optimize and create their poducts for low VAS usage, now they dont have too. So Sceneries and planes can now start to have all these awesome features that we all want but they will be using more VAS uasge like 1500mbs. Pretty soon you start to see your VAS dwindle up to 4GB->8GB-> 10GB-> so on and so on (without leaks). so if you have a lot of ram awesome, but for people who have 8GB and 16GB, i still wouldnt pass OOMS. 

VAS is meaningless in the 64b world.  You can still see what it is using Process Explorer and I took a peek during PMDG B744 testing and when I saw 32GB I had to smile.  Now the memory issue only arises if you only have 8GB, you may want to look at your physical memory commitment if things slow down indicating that you have reached the limit and the OS is using the pagefile on disc.

4 minutes ago, Alex Kulak said:

I wouldnt say that, since its 64 bit all the addon developers can put more into there products for the sim that still takes up VAS. You start out with 16GB, with the regular same addons as P3D V3. getting umm lets say 65% of 4GB of VAS usage. Thats probably roughly 2000+ MBs. By the end of the flight you have close to 85% to 90% maybe a little lower. Heres the thing developers have had to optimize and create their poducts for low VAS usage, now they dont have too. So Sceneries and planes can now start to have all these awesome features that we all want but they will be using more VAS uasge like 1500mbs. Pretty soon you start to see your VAS dwindle up to 4GB->8GB-> 10GB-> so on and so on (without leaks). so if you have a lot of ram awesome, but for people who have 8GB and 16GB, i still wouldnt pass OOMS. 

But that would a be running out of accessible RAM, not of running out of addressable memory (VAS) (which is what the OOMs were).
Not everything addressed must be in RAM, it is perfectly reasonable to swap data to the disc, but it still must be addressable. With less RAM you would just hit a performance barrier when the process has to swap critical data and eventually you'd get memory allocation errors, because there is no more memory to use (although it would still be addressable).
Many Windows system processes are running with 2TB of VAS, that doesn't mean they use that much RAM.

i still wont put it passed that running out of VAS is still possible with 64bit, it may be rare or never happen but there is still that chance it may happen 

2 hours ago, Alex Kulak said:

i still wont put it passed that running out of VAS is still possible with 64bit, it may be rare or never happen but there is still that chance it may happen 

64 bits gives you 16 exabytes of addressable memory. 1 exabyte is 1,000,000,000 gigabytes. So you think scenery and aircraft add-ons will be able to consume 16 BILLION gigabytes of VAS, even if only rarely? "Never" would be an understatement here. We'd run out of any form of storage and memory to back that much virtual address space well before exhausting even a tiny fraction of available VAS.

As a community, we need to realize that with a 64-bit platform, we simply need to stop talking about and thinking about VAS. It is entirely irrelevant now, and any discussion of it is, almost by definition, meaningless.

The limitation now, if scenery and addon developers go wild and don't exercise restraint, is physical RAM. (As pointed out by a previous comment, no, process VAS usage is not an indication of how much physical RAM you need to prevent swapping to disk and slowing things down. A process could, for example, memory map a 100GB file--which would instantly "consume" 100 GB of VAS--but only individual pages of that file will be copied to RAM when particular memory addresses are accessed by the process [demand paging], so if I only read 1GB of data out of that memory mapped file, my demand for physical RAM would only be 1GB even though my VAS usage is 100GB. So again, looking at VAS usage or VAS free is meaningless. We will not run out of VAS, and VAS is not an indication of anything else that matters anymore.)

Hang on, a bit confused here, (old and thick!).

Are we talking about GPU ram , (1080 with 8gb) or system memory, (16g.) Or both together?

I somehow thought that the relevant VAS upper in P3d V4 was my 8gb video card memory and the system memory used in 64 bit OS was the super high limit great for general program code, multiple software running but not used as video memory . 

Apologies for asking a stupid question, but could you take a few seconds to put me straight? 

Many thanks

Matt Attwell

44 minutes ago, matt511 said:

Hang on, a bit confused here, (old and thick!). 

Apologies for asking a stupid question, but could you take a few seconds to put me straight? 

Many thanks

Matt Attwell

There are no stupid questions, only stupid answers. :-)

I must admit that I too am a bit confused of all that VAS discussion, and as my system runs fine with P3Dv4, I will wait with the concerns.

 

FSUIPC was showing remaining VAS. VAS limit in 64bit system and 32bit app is 4GB. For 64bit it is 16 exabytes in theory, as our CPUs can't address more than 54/55bits (maybe I do not remember it correctly, but not relevat to physical RAM).

ProcessExplorer normaly says that my P3D uses around 50GB VAS, that is more than memory installed in my system and it is no problem. as VAS is not really used memory.

If you want monitor your free memory, you need different values. Private bytes is used memory by process which can't be alocated by other processes. So you have to sum your RAM + SWAP minus Private bytes of all running processes, and you get memory available for new processes or to be allocated by existing process.

 

And of course we talk just abour RAM not VRAM as VRAM is different story, but jsut for information, your GPU can use RAM when not enough VRAM in similar way when your system can use SWAP file (if enabled) to extend your RAM. It is called as unified memory.

On 6/4/2017 at 4:54 AM, touchdown84 said:

You can use for example the utility Process Explorer (https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx) to check for VAS or memory used. But VAS is more or less useless to know, 64bit v4 uses 75-85GB of VAS when I'm checking.

I think you mean 7.5-8.5 GB  (at least that's what I'm seeing)..........Doug