OOMs & OOMs....&OOMs

Any issues, problems or troubleshooting topics related to the Prepar3D client application.
vgbaron
Posts: 633
Joined: Fri Oct 15, 2010 8:38 pm

Postby vgbaron » Tue Oct 21, 2014 4:38 pm



Quote:

Quote from KUB10 on October 21, 2014, 06:34

To be honest, bringin out a Flightsimulator in 2013 which is still 32bit goes beyond me.

It limits you to fly small GA planes in remote areas, makes demanding software like PMDG at big airports useless.



That makes training no fun...




I would think it would be up to PMDG to make their demanding software conform to the platform rather than the other way around. There are many users flying demanding software w/o having this issue. Each system reacts differently.



Vic

KUB10
Posts: 24
Joined: Sun Jun 02, 2013 5:56 pm

Postby KUB10 » Wed Oct 22, 2014 1:42 pm



Quote:

Quote from vgbaron on October 21, 2014, 16:38

Quote:

Quote from KUB10 on October 21, 2014, 06:34

To be honest, bringin out a Flightsimulator in 2013 which is still 32bit goes beyond me.

It limits you to fly small GA planes in remote areas, makes demanding software like PMDG at big airports useless.



That makes training no fun...




I would think it would be up to PMDG to make their demanding software conform to the platform rather than the other way around. There are many users flying demanding software w/o having this issue. Each system reacts differently.



Vic




That would not bring any enhancements and software to todays standards. Isnt it time to go with the time and say goodby to yesterday at some piont,

as other developers do, as this would be a definite solution to those problems.



So you'd rather stick with old platforms and flying Abacus like planes? Not me...

User avatar
Rob Ainscough
Moderator
Posts: 2236
Joined: Sat Jan 05, 2013 6:46 pm
Location: Oregon USA

Postby Rob Ainscough » Wed Oct 22, 2014 1:48 pm



Quote:

Quote from mta00jtl on October 21, 2014, 00:46

VAS usage is really a big issue for me in the current version (2.4). Yesterday I attempted to complete a flight from KLAX to KSFO using FSDT scenery, Orbx NCA, Airbus A318/9 and ASN real weather (for the most part clear during the flight).



I used the suggested settings posted by Rob previously but to no avail - with very modest slider settings and things dialed down, I had an OOM at 20ft above RWY28L at KSFO. There is very little else I can think of to reduce in order to make a flight like this possible. It's especially strange as I have done this flight before (in the A320) and with higher slider settings.



I'm watching VAS usage constantly in Process Explorer which isn't much fun - I am fully aware that the scenery and add-ons are complex and challenging for the sim but I am not too sure why I'm having so many more problems than I did previously. And that was when I used higher slider settings. Does anyone at LM have any thoughts on VAS usage and why I and others may be experiencing the above when compared to previous versions of P3D (2.2)? Just wondering if anything that has been changed in subsequent updates that could have had an effect on VAS usage - cloud shadows perhaps? I'm just a little out of ideas.



James




I've done this exact same flight with exact same add-on in the A318 and in the CS 777 without hitting the VAS limits ... even used GSX at both departure and destination. Did you also include my suggestion to Pick the airport, select the aircraft, set your season/time of day, save flight, exit P3D, then start P3D by double clicking the saved flight file (.fxml)? Using this approach with my graphics settings here: http://www.robainscough.com/P3D_V2.php I've not encountered an OOM (it's close 3.8GB but no OOM).



But just an FYI, in the above flight (which I've done many times) my GPU VRAM usage will be around 4.2 - 4.3 GB (running Titans so I have 6GB but also run 4K res) -- have you monitored your GPU VRAM usage during the flight?



Cheers, Rob.
Rob Ainscough
Prepar3D Forum Global Moderator

User avatar
Rob Ainscough
Moderator
Posts: 2236
Joined: Sat Jan 05, 2013 6:46 pm
Location: Oregon USA

Postby Rob Ainscough » Wed Oct 22, 2014 2:23 pm



Quote:

Quote from KUB10 on October 22, 2014, 13:42

That would not bring any enhancements and software to todays standards. Isnt it time to go with the time and say goodby to yesterday at some piont,

as other developers do, as this would be a definite solution to those problems.



So you'd rather stick with old platforms and flying Abacus like planes? Not me...




And what standards would those be? ;)



Very few would debate against the desire for a 64bit platform ... agree it's needed, not much debate there. However, what would you fly in a 64bit P3D? What scenery would you use? What airports? What weather engine? Answer: there would be no existing products that would be compatible.



In order to progress to 64bit LM would:



1. Create the SDK/Tools needed to support 64bit 3rd party development (before release)

2. Try to get some 3rd party developers to make 3rd party aircraft, scenery, etc. for initial release of 64bit P3D (most, if not all, of the aircraft in P3D were done by 3rd party)

3. Initiate a lengthy and time consuming process of converting all existing 32bit code to 64bit ... code that has probably been touched by 100's of developers over decades



I'm not aware of any software as complex and as large as this being converted to 64bit (XP10 isn't and wasn't) ... it's a massive undertaking. So I can certainly understand why LM are trying to provide a 32bit platform to hold folks over while they build a 64bit product that will essentially be "all new" and have little or no backwards compatibility.



The transition from 32bit to 64bit (if it happens) would be extremely slow ... heck the transition from FS9 to FSX was incredibly slow, consumers don't like to give up all their compatible products and 3rd party have a hard time selling "updates". I see people constantly posting about "why should I pay for an update" when it comes to 3rd party ... they feel entitled to ever lasting free updates regardless of the work needed to make those updates a reality in a new product version. Bottom line is, if a 3rd party developer has to do additional work they are going to want to get paid for that work ... developers are people just like you and I that have a wife, kids, mortgage etc. ... they need to pay their bills too.



So to summarize, yes most want a 64bit P3D, it's not going to happen over night hence we get 32bit platform to a more modern graphics API to extend the life of the product, 3rd party will need to be involved, consumers are going to need to spend more money.



But in the meantime, there is plenty of life in the 32bit world of P3D.



Cheers, Rob.

Rob Ainscough
Prepar3D Forum Global Moderator

User avatar
Rob Ainscough
Moderator
Posts: 2236
Joined: Sat Jan 05, 2013 6:46 pm
Location: Oregon USA

Postby Rob Ainscough » Wed Oct 22, 2014 8:31 pm

Sven,



I removed your post ... no usage of PMDG in P3D discussions permitted at this time. Hopefully in the future, but not right now.



Cheers Rob.
Rob Ainscough
Prepar3D Forum Global Moderator

filippo1974
Posts: 69
Joined: Sun May 05, 2013 8:07 am
Location: North east of Italy

Postby filippo1974 » Fri Oct 24, 2014 4:15 am



Quote:

Quote from Rob on October 22, 2014, 14:23

Answer: there would be no existing products that would be compatible.




Let's not make the situation that bad :D



Addons can be made of code only, data only or both of them. In case of data-only addons (such as sceneries consisting only of textures, landclasses, meshes and vector data) the compatibility is automatically assured, provided that the file format for those data remains unchanged for an hypothetical 64 bit Prepar3D.



If there is executable code shipped with the addon, the situation obviously changes, and in this case the effort can range from a mere re-compilation of the code (if it was developed with portability in mind), to a serious overhaul to cope with different pointer size and/or take advantage of larger integer data allowed by 64 bits.



Concerning the complexity of P3D compared to X-Plane or other sims out there, I won't comment since I obviously have no access to the source code of either, so I can't say which one is the most complex. Anyway, the number of source code lines alone does not tell all the truth, an assessment shall also be made about how portable is the existing code to get an idea of the global effort required to port it to 64 bits...
ATPL frozen - CPL/IR ME
P3D v4

SKB
Posts: 16
Joined: Tue Mar 06, 2012 6:20 pm

Postby SKB » Fri Oct 24, 2014 1:05 pm

I am sure Rob referred to X-Plane as a complete new development instead of a conversion from the 32bit X-Plane 9. And if you watch the development of X-Plane you can see that it took them untill now to come up with a good compromise of stability and perfomance, more then two years after release I think. I like the idea that there will be a solid and stable 32bit-platform that uses the now available technology as far as 32bit allow it, giving LM the time to develop the 64bit-version from the ground up. They should see it as the breaking point with backwards compatibility with the professional training market in mind, focussing on stable perfomance (with VR-capable resolutions and fps in mind).



Now that they have a solid base of 3rd-party developers behind them they have the support to develop their own engine on a v3 and maybe even get past the Microsoft contract to make an entertainment license possible. That fuels the 3rd-party add-on market. That's gonna take at least 5 years I guess, presuming they haven't already startet, having the master plan from the beginning. Untill then we have a 64bit X-Plane and a 64bit DCS to "play" around with and a solid 32bit Sim for professional training or educational purposes with stunning graphics even if they are reduced below a OOM-level.



Cheers Korny

mta00jtl
Posts: 77
Joined: Thu Jan 03, 2013 7:32 am

Postby mta00jtl » Sat Oct 25, 2014 3:07 am



Quote:

I've done this exact same flight with exact same add-on in the A318 and in the CS 777 without hitting the VAS limits ... even used GSX at both departure and destination. Did you also include my suggestion to Pick the airport, select the aircraft, set your season/time of day, save flight, exit P3D, then start P3D by double clicking the saved flight file (.fxml)? Using this approach with my graphics settings here: http://www.robainscough.com/P3D_V2.php I've not encountered an OOM (it's close 3.8GB but no OOM).



But just an FYI, in the above flight (which I've done many times) my GPU VRAM usage will be around 4.2 - 4.3 GB (running Titans so I have 6GB but also run 4K res) -- have you monitored your GPU VRAM usage during the flight?



Cheers, Rob.




Hi Rob, thanks for your reply.



Yes I have done everything you outlined apart from disabling the NCA .bgl files. I started from a saved flight.



I have a GTX 780Ti connected to 3 screens but I'm only using the centre screen for P3D at 2560x1440. My GPU usage in Process Explorer runs between 80-90% generally using your settings. I too have done this flight many times before and it's only been in 2.3 and 2.4 that it has become impossible to complete. Plus my settings before used to be higher on the slider front. It's interesting you are not experiencing OOM's despite using 4K too - I know a lot of this is system specific but settings are dialled right back now and I'm pretty sure something has changed between different versions of P3D, I'm not sure if you are aware of anything specific to cause increasing VAS usage?



I intend to do a clean install on 2.5 - with the likes of the not to be mentioned complex 777 looking imminent on P3D I really want to be able to get P3D working again effectively for me.



James


Return to “Prepar3D Client Application Questions”

Who is online

Users browsing this forum: No registered users and 17 guests