Maybe PMDG could as well "outscource" demanding things like FM or systems and just leave the eyecandy to be processed by the sim.

They already do a lot of stuff externally, they just don't post it as publicly as Majestic does.

Seems to me that going to 64 bits will introduce another limit: your installed RAM. Right now developers have to work hard in order to keep VAS usage down. When there is no limit anymore (right now I would call 18,446,744,073 GB almost limitless) developers may forget about optimizing stuff and we may run into problems because we don't have enough RAM installed... It will take a few years before you can plug 18,446,744,073 GB of RAM in a PC... And another problem obviously would be that things would get too heavy for our systems: all those GB's of data will have to be processed by the CPU and GPU. What do you think that adding all possible add ons to the sim will do to performance? I hope I am wrong... (which could well be because I am no expert in all this).

 

All in all I am quite happy right now with how well P3D 32 bits performs and I wonder if going to 64 bits is going to be the holy grail or simply one step forward and two steps back because of new problems we will encounter.

 

It's all in the nature of computing.

 

You solve one chokepoint, then there's a (shortlived) golden age until you hit the next chokepoint.

 

At the moment the (actually somewhat misnamed) Out of Memory (program can't count any higher) error is a hard limit to how many pixels and processes the simulator can push onto a screen or through a physics engine.

 

Doesn't matter how much you upgrade the system, run things in parallel, have multiple processors or faster processors or more ram or bigger better stronger faster the computer is. When the 32 bit addressing runs out, it runs out.

 

If you triple the speed and ram and processing power of your PC, the limit before the 32 bit program (software) runs out of addressing space, does not change in the slightest.

 

Want a 220 degree wrap around visual driving cloud shadows, aircraft-casting shadows on self, ultra high definition simulator with Orbx scenery everywhere, masses of clouds and weather effects, street lights, moving vehicles on all of the roads to the point of traffic jams, a study simulator simulating all aspects of the aircraft, pushback vehicles and ground handling, lots of detailed ai aircraft, and 3 dimentional cities and towns and trees on 1cm/pixel photoreal terrain of the whole earth?

 

OOM.

 

Doesn't matter if you have a new 9999499599194995GHz processor with 4000000000TB of ram. Once the 32 bit program uses 4GB of virtual addressing space, the program stops.

 

All you can do is reduce the load. Potentially leaving our theoretical 9999499599194995GHz processor and 4000000000TB of ram basically unused, simply because the 32 bit program can't count to 4,294,967,296 or beyond.

 

According to a 64 bit program, 4,294,967,295 + 2 = 4,294,967,297

According to a 32 bit program, 4,294,967,295 + 2 = either 0, or infinity, or something else: Does not compute: Error.

The availability of resources can be checked by the program before committing. It's possible that programs don't check, then allocate themselves memory, then forget to free it up, then allocate themselves some more, gradually using all the memory until it's gone. So it's possible that a program running in the address space of FSX/P3D like a gauge or a dll, may make these mistakes, and crash the sim long before it would have used up the 4Gb normally.

There is this silly notion in this thread that a 64-bit application can somehow run higher graphics than a 32-bit application. That, as a base concept, is flawed. The graphics level versus size issue is bound to the size of your video card memory and little else.

 

A 64-bit application can't push more textures into the 2GB-4GB video memory than a 32-bit application. It just can't.

 

Now... the physical size of your textures... that will impact memory usage and that is where 32-bit versus 64-bit can change things. However, with how poorly the FSX/Prepar3D code handles texture management and such right now... I would not recommend going 64-bit until that's resolved. Otherwise you'll still get OOMs, because chewing up memory is fast and it doesn't matter how much you have.

 

 

How about writing 64bit modules wich willl interact trough simconnet with 32bit P3D?.

 

I'm pretty sure FSX/ESP/P3D are based on the quad tree process for terrain loading ... there is no way around a 32bit limit here if you want a larger LOD radius (i.e. higher quality textures being display further out from the view point) it will and can only come from a 64bit process.  There is obviously a view point where a larger LOD Radius will become visually indistinguishable ... the current 6.5 is NOT that point (go to any mountain region you can clearly see that).  Even with LM's continued work on optimization I don't see them being able to really push the LOD Radius out far enough to reach the point of being indistinguishable.

 

SimConnect is 32bit process and it's managed code that is a part of P3D.  A 64bit process would need to reference a 64bit SimConnect ... which is compiled into P3D so P3D would also need to be 64bit.

 

People do seem to be confused with VRAM and RAM ... a GPU works frame buffers, holds texture data for quick access and processing, and renders shaders (and a few other accelerated processing features) ... it does NOT manage the 3D world as one flies thru it, it only presents a snapshot of it.  There is NO relationship to VRAM and a 32bit address space or a 64bit address space.

 

I'll disagree with Ed on one point (otherwise agree with Ed that the terrain loading system needs improvement), the OOM's in regards to 64bit process would come out of physical RAM limit (i.e. if one only has 8GB RAM) - with 32GB or 64GB RAM you'll be hard press to trigger an OOM regardless of code efficiency or flight duration ... I recently completed a 16 hour and 7 minute (QW BAe146 unlimited fuel and yes I wasn't present for 95% of the flight) flight from KSFO to YBBN and did not encounter an OOM or any other issues in P3DV2.2 -- so P3D has come a long way already on the OOM front.

 

I could never do 16 hour flights in FSX and even less likely if I used a PMDG product (which could be why PMDG are testing the waters with XP10).  With PMDG products I pretty much had to turn just about everything to mins (graphics wise) and make sure I disabled many add-ons if I were to attempt any long distance flights in FSX -- I guess if all you care about are flight systems and nothing about the outside world then this process will work for those goals (but my hunch is people would want both, not one or the other).  

 

LM have already improved this goal considerably where I can do long flights and keep my visuals (boggles my mind why PMDG aren't jumping to get their product on this platform sooner).

 

Why I feel 64bit is important to P3D is because of the LOD radius limitation which is most notable when using photo realistic scenery (like MSE and others) ... it would be beneficial for photo realistic scenery content providers to see a much large LOD Radius (well beyond 6.5) so as to be able to show off what their product can do for the simulated experience.

 

But anyway, LM have performed magic before with 2.2 lets see what they come up with ... I can wait for 64bit.

 

Cheers, Rob.

I believe, with no evidence at hand, that LM will probably not migrate to 64 bits. First of all, this would be an extremely expensive and time-consuming task. Most simmers would likely not be able to afford a licence, not to mention buying new aircraft and scenery for the new platform, and will therefore stay with the latest 32-bit version. But more importantly, P3D is intended to be a flight-training tool. I would guess that flight trainers would be extremely happy with P3D2.2, especially when LM is still working at making it better (P3D2.3 is expected to further improve performance). LM is not at all focused on flight-simmers, although we make great beta-testers.

 

Frans

I believe, with no evidence at hand, that LM will probably not migrate to 64 bits

 

LM have already indicated the will ... but there is no official time frame and because of that some people have projected that means it will NOT happen.  I go by what was written on LM's forum, no more and no less - 64bit was listed as something they plan to do.  In the meantime they squeeze out as much as they can from a 32bit platform.  Of course when P3D does move to 64bit, the entire EULA non-sense will go away as significant code changes would warrant a new product and contracts/agreements with Microsoft would either no longer be valid or require renegotiation.

 

 

 

Most simmers would likely not be able to afford a licence, not to mention buying new aircraft and scenery for the new platform, and will therefore stay with the latest 32-bit version.

 

I see no evidence to suggest "most" either?  That statement is often repeated by those individuals that do NOT want to spend more and generalize their opinion to "most", but there is no evidence to support "most" will not spend the money -- if you look at XP10 there clearly is evidence of most moving from 32bit to 64bit.  

 

People spend money when they see value in something ... if 64bit steps up the value threshold for them, they will spend the money.

 

Now I willing to bet many 3rd party vendors would like to see a 64bit P3D ... I know Aerosoft do http://forum.aerosoft.com/index.php?/topic/57970-future-64-bit-flight-sim/?p=412727.  64bit really opens up the door of opportunity for them.  

 

Cheers, Rob.

Wasn't LM's purpose of 'streamlining' the code, to be a preparatory step towards x64? It will take a couple or 3 years, but the ground work being done here in v2, is beneficial to both, LM and us, in more ways than 1.

 

regards, Jazz

 

The only thing 64bit gives you is 4+GB of memory ... that you do not need to pull off of the hard drive.

 

What happens if you have 12GB of RAM drivespace (like I do, 2400ghz, besides no drive lag or blurries. SSD is so yesterday [Primocache]).

 

From a DirectX viewpoint, think about wasting float4's for a float, or initializing anything that's only used a few iterations, times each pixel and texel, and send that to the GPU to basically just warm the room.  That's what you'll get with dirty fat 64bit code.  And that's just the start of it.  

 

There are only a handful of 64bit games out there now ... and they ALL have stutter issues.  How you handle the bandwidth ... and the delays they cause ... between the different places your data goes in your software .. is what makes the microstutter.   

 

Before 64bit systems simply swapping data between 32bit programs is how it is done, whether be another PID on the same PROC, or on another PROC on the same bus somewhere.   You manage the bandwidth between processors, cuing up your calls like twitter feeds, instead of jamming up the bridges just dumping on them.  You keep count of the calls in the stack, not just make sure the memory is released, so your threads are even.  When programming moved from mainframes to PCs nobody counted calls anymore because there is only one PROC, and so the second skill, memory management, went by the wayside too.  But poor memory management hurts PCs too.  It didn't matter that you had another 3.5GB left of memory pool, if you don't manage your memory over pipelines you will have "stutters", whether they visible as pixels, or texels not being filled, or threads not being timed well (because you're cutting uneven "slices")  or drives thrashing because you're pulling from several places instead in line, slowing the whole chain down.

 

Most of the work converting 32 to 64 bit code involves balancing calls to hardware.

 

That being said, it is an extraordinarily difficult thing to do to time all things right.  Very few people have the patience.   If you're planning on running on someone elses hardware, you're accounting for different frequencies, bits of bandwidth, and the harmonics/multiples of them to do it right.  Call it super-computing.  This is why a company like NVidia can do what they're doing, but even they don't have the time or manpower in each iteration of hardware to get line up all the dominoes exactly perfectly the same distance apart for the first drivers.   Or like putting trains on a track one at a time.  Every step must be examined, measured.

 

LM is not doing a "miracle", and it takes a long time to work it (as even NVidia doesn't release an optimal driver until a year passes).   But nobody else does what they're doing and nobody else is doing what they're doing.  But to those who are not understanding the fundamentals, like all higher technologies to primitives, when it is finally worked out it might seem like magic.

 

64bit will be needed when there is a CPU and GPU capable of cranking out multiple 4k resolution (and a working man's market for them) and in the FS context something like LOD the same as what you'd see in real life.  But not for a couple of years yet will you be able to throw a whole 32GB ram at the CPU/GPU ... and all you're going to see is about 4GB of that move around in any useful way.   

 

Enough to choke a cow.