I am not your enemy

 

No one is my enemy Larry (frustration doesn't bread an enemy) ... this debate really boils down to those not willing to put their decade old legacy in a holding pattern while a better future can be built ... this seems to be more about money not enthusiasm for flight simulation ... calling LM/ESP sloppy coders is just the excuse or justification I guess for their goals.

 

Like Noel said, 64bit future is a huge opportunity at so many levels.  The only people that are really enjoying these OOMs threads is probably Laminar Research.

 

Anyway, I need to unsubscribe to this thread and just leave it alone ... may the force be with you in one's quest for optimization.  :Peace:

Rob, you're a good guy.  Stick around.  Just avoid the inflammatory language.  And drop the whole "sloppy" argument;  we're probably talking about totally different things and it's only going to serve to stir the pot.

 

I'm excited about the changes I'm seeing.  I'm sorry that you don't feel the same way.  This problem really isn't any different than the same one we had with Microsoft Flight.

 

Hook

Now the QW756 I would assume, has a bigger memory footprint than the Duke. So the two VAS curves, although the same shape, will be offset from each other, the QW757 curve to the down-side (more VAS is consumed buy the plane model itself). That could just take you into OOM territory with the QW757, but not with the Duke!

 

So the outcome may NOT be the same!

 

Rob

 

 

No I'm sorry I knew what you were saying but you're right I didn't distinguish the initial footprint of the different planes in my comment, but I would have assumed the starting footprint would matter for what it is even if there was such a thing as a memory leak related to the plane itself, which I would assume might be a possibility even if not in this case perhaps.

 

I.e., the outcome will be the same but outcome here relates to VAS usage curve not where the plan on the route runs OOM.

I  found you report very informative Dr. Harris. Thank you

you are NEVER EVER going to be OOM free as long as P3DV2.x is 32bit

 

OOM is an error message.  You can make an error handler, handle the error, before the message is sent, and avoid the shutdown. 

 

You are missing my point.  64bit will get me how much more VAS?  My card only has 3GB.  How is going to 64bit going to help that I cannot buy hardware less than $800 to have over 32bit addresses?

 

Seriously, if we had hardware that could do all these wonderful things, there would be no need for skillful programmers that know how to wrangle in the memory.  

 

I stated this earlier, *optimizing* 32bit is the best choice now.  You know, clean up the crap in the code so it's more readable.  When a wagon wheel breaks, you replace the spoke, not the whole wheel.  Then I said something that agrees with "In 2 years it would be stupid not to have made the 64bit switch".  

 

There is a business, user, and hardware economy that cannot be ignored.  They made the right decision.  They didn't reinvent the wheel, and 

 

most importantly, kept an ancient and passionate, and deeply knowledgeable user base in tact.  I don't think there is another publicly available software that has more 

 

fanatical critical core users.  I can't think of another game that I've ever seen either where the users are so on top of the game developers.  It's a gift and a curse 

 

for the P3D crew.  The only industry I can think of where the users are so demanding for instant gratification is defense contracting during a war.   So the right 

 

company has the torch in this case.

 

hundreds of programmers from India, Vietnam or China

   I'd rather keep an aviation company writing code for aviation software.  Cultural differences are worse than language barriers because they're not obvious.  

 

Sometimes there is just nothing there to relate or work with other than a shared programming language, and you can't communicate with just that.

OK, here's what led me to an 'anecdotally-based' soft conclusion/guess:

 

QW757 versus CS Super MD-80:  same exact route, same climb rate, speed, altitude, using the GPS/LNAV path from KSMF to KSBP, same gate, same runway, same time of day, same weather, same everything.  Relative to land class, these planes were in very close to same location at the same time.

 

                        QW757                MD80

Free VAS

 

at gate:            1.58Gb                1.58Gb   << this surprised me but anyway...

at 16R start      1.17                    1.25

3min aft TO      1.05                    1.10

6min aft TO      0.91                    1.10

9min ...........     0.81                    1.02

12mi ..........      0.75                    1.03

20mi ..........      0.66                    1.08

30mi ..........      0.36                    1.16   (!!!)

34mi ..........     OOM                   1.18    we're now about 80mi out from KSBA

40mi ..........                                 1.12    48m out, this doesn't mean much from here forward but...

at TD at 07                                   0.95

 

From this I have to conclude there is something very fundamentally different about these two birds that have similar systems implementation, though really the MD80 is considerably more complex, but w/ somewhat lower resolution textures maybe.  I kept the tests as similar as possible.  So while your findings may be valid (i.e. land class impact on VAS utilization curve etc) there quite obviously are other factors involved.   The 'memory leak' concept to me still holds water, or still holds VAS as the case may be.

 

This also illustrates some of the not-always-considered problems w/ 'backwards compatibility' as a rationale for continuing down a dead-end road.   Folks will rightly point out you can't expect perfect outcomes w/ content not developed to be fully compatible w/ P3D, yet this remains part of the rationale for staying 32bit.  If I were a 3PD developer right now, I'd rather wait for the inevitable (that would be 64-bit version of P3D out of necessity ultimately) versus de-bug issues w/ compatibility for what may likely be a short-lived issue.  QW was very loud about their lack of support to make their SP3 guaranteed compatible w/ P3D.   Any questions?!

 

 

calling LM/ESP sloppy coders

You're basically calling LM sloppy business managers for not throwing out a completed functioning working piece of software for a complete rewrite for hardware that is out of reach for the average user still ... rather than taking the software you have and cleaning it up for transition to 64bit.  You're basically saying ground-up rewrite which could take 2 years to get worked out, with no resources to the current user base at all, is a good business decision.

You are missing my point.  64bit will get me how much more VAS?  My card only has 3GB.  How is going to 64bit going to help that I cannot buy hardware less than $800 to have over 32bit addresses?

Please explain to me how you somehow seem to think that Virtual Address Space (which is a table of RAM addresses for the application has any bearing whatever on your video card's VRAM???

 

The two are totally unrelated.

I am sorry, Denali, but I disagree!

 

I still think it would have been best to not bother with the old FSX code but to start a new 64bit sim from scratch!

Are any of us really willing to wait anywhere from three to six YEARS for a "from scratch 64bit sim?"

 

I'm sure not!  :LMAO:

 

 

Any questions?!

 

No question but a commment. Agreed there could be legacy product that cause problems. But actually i can report having several legacy product doing a fine job on Prepar3D. I have no problem to find that some of my older bird have to be flown only in my FSX install and I have to forget about them on P3d. 

 

But I see no point to go a 64 Bit route right now because some legacy product doesnt perform well. P3D is young and I think we have not seen yet what the developper can deliver on this new platform within a 32 bit environment.

 

Of course all of this depend on the mission you want to fly. I rarely use tubeliner so I think P3D can go a long way for me at 32 bit...

 

Not one size fit all like always....

My spin?  Microsoft dropped the ball big time when they abandoned FSX for seemingly greener pastures...after all, FSX was their showcase for directX!  In their distraction they left much of FSX's potential unclaimed...but even worse, they never completed the last chapter in the book for FSX.  In a way, I think this is the big opportunity for LM.   Sure capitaliz on FSX's strengths but at the same time finish the chapter on FSX.

 

With the core now updated to DX11, the sim is looking fresh again.  And there is further potential to really demonstrate what is currently possible with shaders and all of that...within the confines of what Directx11 can afford today!    Sure OOM's are a bad story, but these can be tamed by better coding and memory management.  And if that is too difficult a challenge for Developers, then no amount of bits will help!

 

Now, I am not against 64bit.  I can only imagine it will allow the fidelity of the sim to be that much more real.  But, for next few years I think there is enough sim potential left such that those gains will not be critical.  Also, as LM further improves the sim they can provide guidance and a migration path to 64bit...something that would never exist based on the way Microsoft left FSX.

 

 

But I see no point to go a 64 Bit route right now because some legacy product doesnt perform well.

 

I don't think the reason to go is because a legacy product doesn't perform well per se.  But I do think given the potential for unsolvable issues w/ VAS the need to get to 64 bit at some point becomes a disincentive to creating new content or adapting old content to P3D 32 bit.   If the VAS issues that are surfacing now are mitigated so that users can use P3D V2.x with what amounts to little to no OOM risk, and it would not be popular to simply put in constraints so the user can't OOM, then the future of 32 bit would be a little brighter and might tease along 3PD content development a few years longer.  But if that's not the case and current levels of quality must be sacrificed to avoid OOM, then I think the sooner the better the migration to 64 bit route.  I guess we'll all see.  Right now I'm really enjoying coming into KACV in the RA Duke ;o)

Geolpilot,

 

Thanks for your contribution with this interesting paper. This confirm the importance to manage sliders and expectations. 

 

A couple of question.

 

Autogen_batch_lod is for building?

 

Autogen_batch and the sliders seems to do similar things in the end i.e. modulating the level of autogen. Why bother to change cfg if we can achieve the same results with the sliders? You use a LOD of 1 but in your examples you cannot max the sliders anyway so what is the advantage of doing so?

 

Interesting explanation about how the VAS use and release memory and the relative complexity of tree generation over buildings....

The phrase 'memory leak' is a poor choice to describe what happened in the QW757, but it's really just a metaphor for the same thing.  Saying something is causing VAS consumption to go up dramatically, versus VAS capacity is 'leaking away' dramatically, gets you to the same place.

 

The apt description would be that 'something [in the aircraft coding, for example] is causing VAS usage to go up dramatically compared to similar planes, and this is independent of the initial footprint, vegetation/autogen, and other scenery elements.  So from the VAS silo analogy:

 

What is dangerous is if our program had some fault in it that made it send regular batches of boxes to the silo, and the program “forgets” to ever tell the silo-manager to “expire” those boxes. These boxes would steadily accumulate within the silo, slowly eating away at precious space. We could detect this problem as an ongoing decline in space available within the silo, as in addition to the normal consignment load, there are always extra boxes to store that also never get replaced (VAS- remaining declines consistently and continuously, so in this sense VAS-remaining “leaks” away. VAS-remaining could never stabilise at a constant value, it is always going to shrink). 

 

Does the hot patch address anything here maybe?  I tried to install it but got black screens at flight load x4 so restored back.

 

Also, I'm not clear on what role maximum texture resolution in P3D V2.x has on VAS use efficiency.  Does the memory manager 'see' a 1024 bit texture as if it were a 4096 bit texture because we set Global Texture Resolution to Ultra/4096, thereby maybe limiting the number of reusable expired address blocks?

 

I learned vegetation seems to have an inordinate impact on VAS use early on and recommended it to Robains.   Typically just by pure trial and error I ended setting vegetation at Normal, and autogen at Very High, or Dense depending on the scenario.   So they jive well w/ Rob's analysis.  The puzzle that left me wondering was the behavior of the QW757.   And 100% true:  the issue did not manifest at all w/ V2.0 in the QW757.  Took many 2-3h and a 4h flight no problem.   Probably will just have to let that plane go for now unless maybe the hot patch could impact this issue.

 

And yes indeed, thank you Rob for the paper on VAS it helped me get a better understanding of the basics.  It was nice to learn the newer scenery add ons like FTXG are not problematic per se, and also that there is some hope to target inefficiency VAS management related to vegetation textures.

Please explain to me how you somehow seem to think that Virtual Address Space (which is a table of RAM addresses for the application has any bearing whatever on your video card's VRAM???

 

Please explain to me how a VRAM memory of more than 4GB (or actually about 3.5GB accessible because some is lost to overhead) is accessed in a 32bit program?

 

There was once a day when RAM was nothing more than a way to speed up disk access - to make a copy of what was on disk in a place that it could be accessed faster.  That really hasn't changed.   32bit programs can communicate in parallel if you know how to do that.  That's what 64bit is, it isn't just more memory.

 

 

OK, here's what led me to an 'anecdotally-based' soft conclusion/guess:

 

Noel looking at those figures, I would agree with you that the QW757 is dumping stuff in VAS that is leading to an OOM. The patterns of VAS usage for those two aircraft are NOT the same, so yes, superimposed on what is related to scenery is  a continual extra load coming from the QW757. Interesting find, indicative that it may have a coding problem.

 

But that does not occur with all add-on aircaft. I am about to do a test flight in the QW146, to see if it will also "break VAS pattern", compared to the Carenado C90 and Mooney Acclaim, which both showed the same VAS usage pattern on the same route, but offset by 100Mb (Carenado C90 on the heavier side - heavier footprint, but stable VAS usage)

 

Having test graphs like this gives me a "baseline" to detect the effects attributable to an aircraft. That was the whole point in me originally excluding the aircraft variable from my tests

 

Rob