MS isn't doing a darn thing and LM hasn't said it is doing anything. That is why this is unnecessary and useless.

It's fun to hear opinions and on occasion you learn something too!

MS isn't doing a darn thing and LM hasn't said it is doing anything. That is why this is unnecessary and useless.

 

 

Lockheed Martin has said P3D V2 will use DXD11 - it has said nothing about its being 64-bit. Read into that what you will.

 

OOMs seem to occur towards the end of a flight and not at its start. That suggests that VAS is being allocated but not being freed later. The problem might possibly be solved by some judicially placed calls to VirtualFree() in the source code without the need to convert to 64-bits.

 

OOMs seem to occur towards the end of a flight and not at its start. That suggests that VAS is being allocated but not being freed later. The problem might possibly be solved by some judicially placed calls to VirtualFree() in the source code without the need to convert to 64-bits.

 

But you do see memory de-allocations happen - process explorer will show this happening.  Also keep in mind that the replay system will continue to record so it's also using up memory, texture caching, weather changes (more clouds), autogen objects increase/decrease, and finally destination airports being more complex, etc. etc..  And then their are the add-ons.  I'm not saying FSX couldn't be better optimized, it probably could but that type of project (tracking down possible optimization with memory allocation/deallocation) could be more time consuming that just coding for a 64bit path.

 

Sure, if you keep FSX in a pristine configuration it will not likely hit OOM ... but that begs the questions of why provide an SDK?  Here's the door to the world but you've only got 3' x 3' x 8' to fit the rest of the simulation world in .

 

And yes, if you want to simulation a world of flight then you will probably need 128 bit (maybe even 256bit, the future awaits) ... but lets take baby steps and move to 64 bit first since it's an order of magnitude wider than 32bit.

It's not enough that memory is freed, it has to be contiguous. At the end of your flight, when FSX goes to load your complex airport scenery in on approach, you may have say 200mb free virtual address space available, FSX may just need 50MB to load the scenery, but if your largest contiguous space is only 40MB, the Application will OOM! That's why it's necessary to clear as much space up front so that space is available later on.

I absolutely love reading these threads. Makes engineers at nVidia, MS, Intel, etc, look like 12 year olds writing their first Hello World! snippet in BASIC.

 

Sometimes I wonder if MIT is really worth it. Hey Tom A, remember that idea of having user blogs available here at AVSIM? I think we should host engineering blogs. We certainly have the pedigree here.

 

LOL

 

Keep going guys, this is a blast. ;-)

 

Sent from my Galaxy Nexus using Tapatalk 2

 

Sure, if you keep FSX in a pristine configuration it will not likely hit OOM ... but that begs the questions of why provide an SDK? Here's the door to the world but you've only got 3' x 3' x 8' to fit the rest of the simulation world in .

 

You are forgetting that within the SDK, it specifies limits, (Like textures sized max 1024x1024) that are being surpassed by the 3rd party community. It's great that they can do this, but you also have to accept the consequences and compromises that come along with it.

But you do see memory de-allocations happen - process explorer will show this happening.  Also keep in mind that the replay system will continue to record so it's also using up memory, texture caching, weather changes (more clouds), autogen objects increase/decrease, and finally destination airports being more complex, etc. etc..  And then their are the add-ons.  I'm not saying FSX couldn't be better optimized, it probably could but that type of project (tracking down possible optimization with memory allocation/deallocation) could be more time consuming that just coding for a 64bit path.

 

Sure, if you keep FSX in a pristine configuration it will not likely hit OOM ... but that begs the questions of why provide an SDK?  Here's the door to the world but you've only got 3' x 3' x 8' to fit the rest of the simulation world in .

 

And yes, if you want to simulation a world of flight then you will probably need 128 bit (maybe even 256bit, the future awaits) ... but lets take baby steps and move to 64 bit first since it's an order of magnitude wider than 32bit.

 

I don't think in the hardware world available to MS they envisaged FSX still being in hard use 8 years later, in those days 64bit was completely new to the consumer and the guys who designed FSX probably never saw any reason to worry because the sliders meant that limits would never be exceed in the hardware available at the time. The hardware available to us now is capable of pushing FSX to the edge and it rightly breaks because it wasn't designed to be run this way. The stuff we are pumping into our configs now isn't even available to be tweaked by your average user and we are indeed pushing FSX to do things it was never designed to do and this will always cause problems.

 

I haven't had an OOM in the month or so i've had a system able to run FSX very nicely and i still stick to 1024 textures because it's smooth and acceptable, the sliders are your friend in this instance. The software can't really be blamed when people are tweaking FSX with things that were never even publicly available let alone put into the sim, it's like overclocking, if you push it too far your asking for trouble. It is frustrating but those are the limits imposed in a software environment from 8 years ago and it isn't going to change anytime soon.

 

Also keep in mind that the replay system will continue to record so it's also using up memory

 

An interesting comment. How much memory does replay data require? Can replay be switched off?

An interesting comment. How much memory does replay data require? Can replay be switched off?

 

My understanding is that the data is written to a remporary file on disk which is deleted when FSX is closed.

You are forgetting that within the SDK, it specifies limits, (Like textures sized max 1024x1024) that are being surpassed by the 3rd party community. It's great that they can do this, but you also have to accept the consequences and compromises that come along with it.

I agree ... but if you think about it, it's an "available" variable - which means the Aces crew most likely used and changed this value to see how FSX performed ... they probably ran into the same OOM issues which is probably why the FSX UI only allows a maximum value of 1024. Faced with a known OOM issue, the development team and/or PM (aka Phil) probably elected to impose a restriction via the FSX UI rather than the alternative which would mean coding a 64bit path (a much longer and more costly project). If Aces wanted to really lock this down, they could have simply hard coded the values and not made it a variable read from FSX.CFG. But keep in mind people were hitting OOM after the first version of FSX with nothing but FSX (no add-ons) ... before a 64bit OS was used and FSX was compiled to be large address aware flag.

 

Again, not blaming anyone or FSX, it was a decision made to "live within" the budget and development time imposed on the FSX project by Microsoft ... Phil confirmed this (indirectly). I do as others, adjust my settings/configuration if I want to fly my PMDG NGX ... I choose between less visual quality or no AI traffic or whatever else I need to do in favor of realistic aircraft systems.

 

I'm not entirely sure why folks are so defensive about OOMs? And I have no idea why people feel the need to say "there is a problem with your system" without even knowing anything about that person or their hardware or their configuration -- just seems like a silly response to me -- unless they have some alternative motive??

 

Lockheed Martin has said P3D V2 will use DXD11 - it has said nothing about its being 64-bit. Read into that what you will.

 

They also have said that they will take much of the rendering off the CPU andput in on the GPU which may result in better performance. Their only comments re 64bit have been that it wouild be a massive undertaking with a HUGE rewrite of code. They have never acknowledged that they are even considering same except in offhand remarks about "someday down the road".

 

Great discussion this, but totally meaningless as it relates to P3D.

 

Vic

Ahh, the 64bit silver bullet discussion again. Love it.

My understanding is that the data is written to a remporary file on disk which is deleted when FSX is closed.

 

I would imagine there is very little data being written because it's only needing to store the script for the replay, not the whole banana if you follow the argument.

 

Great discussion this, but totally meaningless as it relates to P3D.

 

And also for FSX and even Flight!

 

They also have said that they will take much of the rendering off the CPU andput in on the GPU which may result in better performance.

 

This is a HUGE undertaking also ... probably why LM said sometime before 2016 on their FaceBook page.  My take, they are going to have to re-write A LOT going to DX11 and get full multi-GPU support ... there are a few areas of the sim they wouldn't need to touch for DX11 but if you gonna dig up that can of worms, why not move it to 64bit, it would be the more efficient process rather than having to go thru the entire process again converting everything to 64bit.

 

But LM haven't committed to multi-GPU support and that's where we'll see scalable performance (i.e. Crossfire, SLI, etc. etc.).

 

But it seems that much of this debate is suggesting that it can only be one (DX11) or the other (64bit), and not both.  Those of us hitting OOM frequently would prefer to see 64bit.  Those of us with low FPS are wanting to see DX11 (multi-GPU, DX11 alone will do nothing for performance over existing DX10).  I'd like to see both, OOMs are show stoppers and low FPS can make landing impossible -- both require compromises.

 

Personally, I'd rather see LM focus on 64bit and multi-GPU support.  If they are moving to DX11 because of tessellation then it'll be real interesting to understand the real motive behind that ... even with hardware accelerated support, tessellation is a big performance hit.  I'm guessing "night vision" improvement in visual quality via tessellation ... I can see that being important for military simulations.

 

But I agree, not much "concrete" coming out of P3D, however I still support them with my $10/mo donation