Jump to content
Sign in to follow this  
Petraeus

Version 2.1 OOM and possible memory leak.

Recommended Posts

I think Mr Doney misses the point here. We were promised relative compatibility of addons - it was one of the reasons why Lockheed Martin kept Prepar3D at x32.

 

If we can't use addons at all - because every departure from a vanilla P3D causes OOM - what is the point of not pressing the compile button next to the x64 version? After all the addons need to be made compatible in both cases. And the sooner we get to x64 the better, as addon producers will have more time to switch to x64.

 

I hope LM will not release 2.2 version just addressing some small bugs, but will instead make a x64 version of P3D available and then focus on other bugs.

Share this post


Link to post

I think Mr Doney misses the point here. We were promised relative compatibility of addons - it was one of the reasons why Lockheed Martin kept Prepar3D at x32.

 

He also ignores that some of us are able to get OOMs with default aircraft and default scenery, and just puts us down as liars or delusional.

Share this post


Link to post

No, you absolutely were not promised compatibility, with every addon, at every single slider setting available.

 

Of course you weren't. In fact, you were explicitly warned otherwise, if you'd been listening.

 

To the point though, that's not what this thread is about. I agree with you that 64bit is required, but that isn't the reality of the situation today. So you (collective you) can either learn to compromise for that like an adult, like any adult that realized this would be the case since before release of 2.0.

 

Or you (collective you) can continue your temper tantrums of entitlement.

 

Either way, this thread is about:

 

Version 2.1 OOM and possible memory leak.

 

and not 64 bit. We've already done 64 bit to death.


He also ignores that some of us are able to get OOMs with default aircraft and default scenery, and just puts us down as liars or delusional.

 

I would be the delusional one, were I to believe your "luck" theory over actual testing I have done first hand. I don't necessarily think you or anyone is lying, but even Jeroen went through this with the 2.0 release, where initially he refused to accept that his addons could be the cause of his issues.

 

How'd that turn out ?

 

In fact, I think he's still using that Cessna. 

 

In any case, if there is a leak, you should easily be able to provide me with a situation where I can re-create it.

 

I'm waiting.

 

EDIT: I am going to go ahead and wrap up my participation in this thread. We have passed the conversation stage, and are now in the denial and arguing with evidence while providing none stage, that I have no interest in being a part of.

 

If anyone, after all of this, isn't at least willing to question other causes, then nothing else I say will matter anyway, and I'll not be wasting any more of my time responding to pure conjecture. If anyone does want to continue discussing this rationally, well, show your testing first, and we'll go from there. 


Regards,

Brian Doney

Share this post


Link to post

If we can't use addons at all - because every departure from a vanilla P3D causes OOM - what is the point of not pressing the compile button next to the x64 version?

It is apparent that you are not a programmer or you wouldn't have made such a statement. There is no magic "compile button" for making source code 64bit compliant. The hardest part of the task is refactoring the millions of lines of source code.

 

Even Austin had to spend over two years refactoring his source code before he could then spit out a 64bit version of XP. Now that the hard part is done however, he can compile for both 32bit and 64bit using a setting in the compiler.


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556


     Avsim Board of Directors | Avsim Forums Moderator

Share this post


Link to post

Setting veggies to Sparse has so far helped. Haven't flow for more than 10 minutes in the Twin Otter. Will have to do some much longer tests tonight.

 

The sim does look pretty damn bad with veggies at such low levels, i must say. But if it works... Compromises sometimes suck  :angry:

Share this post


Link to post

I based my assessment on the post by West Bard in the Prepar3D forum:

 

Yes.

It's not as simple as pressing the compile in 64-bit button, or else it would have been done already icon_smile.gif The baseline has multiple languages, and while you all have mentioned most of the benefits of 64-bit, there are drawbacks, one of the biggest is certain things like BGL (most of the addon scenery you likely use use BGL) won't be 64-bit compatible. So developers will really have to redevelop a lot of their content for a 64-bit P3D.

Wes Bard
Software Manager - Prepar3D® Team

 

Sure, I am not a programmer, I did not know about refactoring of the code. However, he clearly gives here the main reason for not compiling 64bit: the issues with compatibility of addons, not the workload or difficulty (which, I still think, is immense). Here it is also, where the compatibility of addons was not promised, but strongly implied as one of the reasons behind staying with 32bit. We all know how LM is working with the addon developers to ensure such compatibility and has been praised for this numerous times by the community.

 

Please note the number of threads on the Prepar3d support forum with OOM in its title. It simply means that there is no other way than going 64bit and it is time to abandon the priority of superficial compatibility (which after all does not work). That is my point. 

 

To Mr Doley: you are accusing me that I cannot compromise with my addons. But what you require is not simply a compromise - but total abandonment of all addons I wish to run: Prepar3d vanilla. That is pretty far from what compromise means to me.

Share this post


Link to post

Just a small update:

 

While we can improve, and will continue to improve system performance and memory management, some of these use cases maxing out autogen and flying at 120kts and running out of memory need to be put into perspective. We draw a lot more autogen in v2.

However, as a robust simulation platform our settings are intended to support the broadest range of training scenarios. Certain use cases need to max out their system without ever moving the camera. So one shouldn't expect max settings to be usable at mach 2. We don't want to make a "safe mode" that will lock down the platform and limit settings that will be completely stable in all scenarios. We made the graphics profiles to help assist with this

 

...

 

Wes Bard

Software Manager - Prepar3D® Team

 

 

So, pretty much exactly what I have been saying here over the past few days.

 

Interesting isn't it ?

 

Well...I thought it was anyway.  :lol:


Regards,

Brian Doney

Share this post


Link to post

I read that. So, getting OOM's and all settings default or Medium and Normal is considered maxed out?

Share this post


Link to post

I read that. So, getting OOM's and all settings default or Medium and Normal is considered maxed out?

 

Any evidence of that ? What addons ?

 

Sorry, but with the test I have done in this thread, and further testing going on behind the scenes since, you, or anyone, just providing anecdotes is not enough.

 

As a reminder, this thread was about a memory leak, which is a very different thing than some settings/addons that just consume a lot of VAS. If you have some evidence that one exists, please provide it, and I'll be glad to help you confirm your findings. I find it telling that I have repeatedly asked for a testable scenario here, and have yet to be provided with one. In other words, still waiting...

 

I'd also certainly hope any testing done was in a stock configuration.


Regards,

Brian Doney

Share this post


Link to post

Any evidence of that ? What addons ?

 

Sorry, but with the test I have done in this thread, and further testing going on behind the scenes since, you, or anyone, just providing anecdotes is not enough.

 

As a reminder, this thread was about a memory leak, which is a very different thing than some settings/addons that just consume a lot of VAS. If you have some evidence that one exists, please provide it, and I'll be glad to help you confirm your findings. I find it telling that I have repeatedly asked for a testable scenario here, and have yet to be provided with one. In other words, still waiting...

 

I'd also certainly hope any testing done was in a stock configuration.

I shall guarantee you. I have had OOM's with default aircraft and a completely default/stock installation!

Share this post


Link to post

I shall guarantee you. I have had OOM's with default aircraft and a completely default/stock installation!

 

So another anecdote then.  :rolleyes:

 

Where ? When ? What aircraft ? What were your settings ?

 

Do we want to get to the bottom of this, or just whinge at each other until the end of time ?

 

Once again, an OOM is not a memory leak, which is what this thread is about. Of course, a memory leak can lead to an OOM, but so can setting your sliders too high, among other things.

 

There is very likely NOT a memory leak in P3Dv2.1.

 

There is a way to test these things, and so far, I'm not seeing many of you willing to buckle down and do it. To me that says you aren't actually interested in finding a solution, but only in complaining. If that is the case, fine, but it is completely useless, and is only so much noise. If anyone does want to put even the slightest bit of effort in to tracking this down, I'm here and willing to work with you.

 

I doubt I'll get much of a response.

  • Upvote 1

Regards,

Brian Doney

Share this post


Link to post

I doubt I'll get much of a response.

Sorry,but take a look at the prepar3d forum, plenty of reports there. They are starting to take it seriously.

Edited by n4gix
Removed excessive quote. Please, do NOT quote the entire message. Quote only enough to maintain continuity of thought.

Jude Bradley
Beech Baron: Uh, Tower, verify you want me to taxi in front of the 747?
ATC: Yeah, it's OK. He's not hungry.

X-Plane 11 X-Plane 12 and MSFS2020  🙂

System specs: Windows 11  Pro 64-bit, Ubuntu Linux 20.04 i9-9900KF  Gigabyte Z390 RTX-3070-Ti , 32GB RAM  1X 2TB M2 for X-Plane 12,  1x256GB SSD for OS. 1TB drive MSFS2020

Share this post


Link to post

Sorry,but take a look at the prepar3d forum, plenty of reports there. They are starting to take it seriously.

 

I have quoted their official statement above. 

 

Of course they will look into this, and take these reports seriously, as should we all. This is not an effort by me to sweep something under the rug that is in need of attention. I have no reason to do that. If there is an issue, lets test it to a valid result. That just isn't happening here, for the most part.

 

EDIT: by valid, I simply mean, that when you look even at the LM forums, try finding reports and testing that was done in a repeatable, default, scenario. Almost every one is "OMG I was flying my unsupported aircraft over FTX-Universe into FSDT Superport with Megatraffic3000X at max autogen and LOD and had an OOM ! P3D sucks !"

 

Once again, a memory leak is a very specific issue. That is what we are discussing here. 

 

Going off topic myself a bit, if there is anything to be a bit disappointed by, it is that the core simulation does indeed consume a pretty hefty chunk of VAS, and that the DX11 offloading really hasn't resulted in nearly as much headroom as I had hoped it would.

 

My interests in P3Dv2 were purely for those benefits, my hope was that with the GPU sharing more of the load, and with the GPU no longer taking a big chunk of application VAS for itself, that we'd have a bit more breathing room to work with. That hasn't shown itself to be the case.


Regards,

Brian Doney

Share this post


Link to post

Where ? When ? What aircraft ? What were your settings

Default location. Mooney Acclaim. Default every setting. Dept rwy turn NW. VAS starts out at 2.42 and drops consistently approx 10k every 30 sec

 

.

 

EDIT: by valid, I simply mean, that when you look even at the LM forums, try finding reports and testing that was done in a repeatable, default, scenario

 

Yep, It's diffidently a confirmed issue. No need for denial. I just hope I dont have to wait 3 or 4 months for a fix. Though I am patient, Not quite that patient. Not like its a little issue with a button or similiar. Or even the GPS deal.

Share this post


Link to post

Default location. Mooney Acclaim. Default every setting. Dept rwy turn NW. VAS starts out at 2.42 and drops consistently approx 10k every 30 sec

 

.

 

 

Yep, It's diffidently a confirmed issue. No need for denial.

 

No one has confirmed anything Rendi, but if it makes you feel better to simply argue, have at it.

 

I will fly this twice, once with the Beech, as I have personally tested with it already.

 

I will try and remain about 2000 AGL and a hdg of 315 if that is OK ?


Regards,

Brian Doney

Share this post


Link to post

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