Prepar3D v2.5 Development Update

[Silverbird 115]

That's P3D in it's current state. It will not be an easy transition. There is a few mantle game out on the market already including the popular BF4. Take a loo at the following numbers ran by anandtech and tomshardware

 

http://www.anandtech.com/show/7728/battlefield-4-mantle-preview

http://www.tomshardware.com/reviews/amd-mantle-performance-benchmark,3860-8.html

 

This was done during the preview period and more patches has been done since then. At the time of the benchmarks, it was a 7-10%. Its not a big deal but this is just one of the first program that really took advantage of the Mantle API. You have to think it's going in the right direction. DX12 will take over Mantle and leave it in the dark. Once gaming engine will be re-written to take advantage of multithreading operation with the GPU, I think you will see a more than 10% gain overall. You will see less CPU bottleneck and more GPU bottleneck which is what you want.

 

I agree DX12 is gonna be a good thing I'm really excited for it hope LM implements it on p3d.

 

 

And thank you Rob for the updates and videos.

[DylanM 1,069]

 

 

That's the usage of all your cores combined. The main thread runs on core zero and is generally running at 80 to 100%. The other cores are busy loading scenery textures and mostly twiddling their silicon thumbs.

That's where DX12 can fundamentally change things up...

 

http://www.littletinyfrogs.com/article/460524/DirectX_11_vs_DirectX_12_oversimplified

[fogboundturtle 2,708]

If you ever work in software development, you will find the following picture funny.

[chris1965 13]

I wonder if P3Dv2 32bit will take advantage of Windows 10 and DX12 (if that is even possible) in a future update or will we need to wait until P3Dv3 64bit? 

[denali 74]

 

 

If you ever work in software development, you will find the following picture funny.

 Bad development manager!  Bad boy!

 

 

I wonder if P3Dv2 32bit will take advantage of Windows 10 and DX12 (if that is even possible) in a future update or will we need to wait until P3Dv3 64bit? 

 I haven't looked into what that will take.  But I am wondering if anyone else read somewhere that DX12 will also help DX11 code?  I still don't think it's the DX code they've fixed, but fibers.  They're just covering it up.  I mean, sure, put it in the DX code now. But it's still a major shift in fiber implementation.

[Guest]

I like the picture ...

 

Needs a little adjustment 

1.  Theory (left) is how it would work for video rendering, 3D animation rendering ... tasks that can be divided equally with a finite segments that get done approximately in similar time.

2.  Actual  (right) - it would be more accurate if the some (not all) dogs were heading back to a 60 lb bag of dog food with some dogs already at the bag waiting for more food to be dished out while the slow eating dogs are still chomping away.  But you would never see 3 dogs hitting one bowl -- that's "not thread safe" and can lead to all kinds of problems.

 

 

Cheers, Rob.

[denali 74]

I've been hunting around, looks like some believe that dx12 will bring improvements for dx11 proggys.   It's going to be an exciting year, with all the windows 10 previews being installed and p3d dx11 to 12 testing.  hehe.

[liketofly1 11]

Gentlemen,

 

Just imagine - P3Dv3,0 with DX12 and in 64bit......

 

And now wake up again - because they still need to work on that - release date maybe this century

 

relax and fly

[jabloomf1230 2,445]

It sounds just like the recent thread here on XP11... Vaporware speculation.

[JimmiG 244]

I'm not convinced about DX12. Before P3D v2, DX11 was the knight in shining armor around here. DX11 already brings some serious improvements to multi-threading and making applications less CPU-bound, however it still requires the application to be written to take advantage of those improvements.

 

Having an API that in theory allows all CPU cores to communicate with the GPU simultaneously is one thing - modifying a complex application to take advantage of this is something completely different. I don't think P3D v2 in its current state is even close to taking advantage of all the features available in DX11, let alone DX12.

 

There's also a lot that can be gained by optimizing the engine to take more advantage of the GPU. Most games don't have this abnormal CPU-dependency that FSX and P3D (to a lesser extent) do. If you think it's CPU dependent because of the ATC, flight modeling, systems modelling etc., try turning every slider to the left, set the resolution as low as it will go and replace all aircraft models with simple low-poly ones. Then watch the frame rate skyrocket. Pre-calculating more of the scenery features and for a larger area at a time would help. This would require more storage and RAM, which is where 64-bit would be useful.

[ChaoticBeauty 6,692]

I'm not convinced about DX12. Before P3D v2, DX11 was the knight in shining armor around here. DX11 already brings some serious improvements to multi-threading and making applications less CPU-bound, however it still requires the application to be written to take advantage of those improvements.

 

DirectX 11 wasn't that big of an improvement actually when it came to CPU performance, it still had the 20% overhead like DirectX 10 did.

[liketofly1 11]

I'm not convinced about DX12. Before P3D v2, DX11 was the knight in shining armor around here. DX11 already brings some serious improvements to multi-threading and making applications less CPU-bound, however it still requires the application to be written to take advantage of those improvements.

 

Having an API that in theory allows all CPU cores to communicate with the GPU simultaneously is one thing - modifying a complex application to take advantage of this is something completely different. I don't think P3D v2 in its current state is even close to taking advantage of all the features available in DX11, let alone DX12.

 

There's also a lot that can be gained by optimizing the engine to take more advantage of the GPU. Most games don't have this abnormal CPU-dependency that FSX and P3D (to a lesser extent) do. If you think it's CPU dependent because of the ATC, flight modeling, systems modelling etc., try turning every slider to the left, set the resolution as low as it will go and replace all aircraft models with simple low-poly ones. Then watch the frame rate skyrocket. Pre-calculating more of the scenery features and for a larger area at a time would help. This would require more storage and RAM, which is where 64-bit would be useful.

 

Hey, I'm sorry to say, but unfortunately I don't have any idea about programming..... And if you say so - I will have to trust your word - but anyhow thats why I said "Imagine" ...

 

In this (My) Imagination - P3Dv.X is fully streamlined to make use of each and every benefit DX12 and 64bit brings    ------ Now wouldn't that be nice -----

 

and now I wake up again - and go on flying with what I've got 

 

ciao

[Anxu00 176]

 

 

Back to FSX DX10! I'll miss the cloud shadows. And that's about it. 

Try FSX-SE and DX10 ;-)

 

I bought into P3Dv2 solely for the continuing code/os support, now that FSX-SE is supported by DTG, I am giving it a second look, simply because I still have too many add-ons with FSX.  As for 2.5 I would just have to wait it out until the dust settled.  I for one don't understand the thinking behind moving cfg file to ProgramData, I am not seeing any real benefit except to cause griefs. Oh Well, we did ask for continued support didn't we?  My only wish is that LM would make available 2.2 for me to get again.  I bought into P3Dv2 only at 2.3.

[Guest]

Pre-calculating more of the scenery features and for a larger area at a time would help. This would require more storage and RAM, which is where 64-bit would be useful.

 

This makes no sense at all.  How do you pre-calculate (unless you're talking buffers but that has nothing to do with your context) a scenery (I assume you mean a scene/frame) when real time directional changes are happening?  That would be a huge waste of processing time. In fact, most modern simulations/games will clip to process only what's in the view because it's much faster to do so, and P3D does exactly that.

 

 

There's also a lot that can be gained by optimizing the engine to take more advantage of the GPU

 

And what would that be exactly?  Not tessellation, that's already an option which is exclusive to DX11 ... not going to find that in FSX or FSX:SE.

 

Ok, so how about those Terrain Shadows ... simple test, turn them ON and watch the GPU usage double, turn them off and watch GPU drop back down.  The GPU most definitely is being utilized.

 

The issue is distance and it will always be an issue for any flight sim in which we want to fly the globe ... XP10, FSX, FSX:SE, P3D ... the more "real" you make the world with tessellation, cloud shadows, terrain shadows, etc. etc. the more it's going to work both the CPU AND the GPU because of that thing called "distance" ... that's why cloud, terrain, object shadows have draw distance slider adjustments because they cause a huge amount of GPU work.

 

Other "games" don't have a 150-200 mile or more view distance, lucky if other 3D shooters have a 5 mi view distances ... they operate by loading a "level" which is NOT the entire globe.

 

 

 

My only wish is that LM would make available 2.2 for me to get again.  I bought into P3Dv2 only at 2.3.

 

You lost me there ... how can you get 2.2 "again" if you didn't get P3D until v2.3?

 

Also, it begs the question of 3rd party supporting older versions of P3D which again would NOT be wise to stick with older versions that have known bugs that get fixed in newer versions as 3rd party move forward and LM moves forward.

 

I don't allow add-ons to be a ball and chain for me -- seems rather limiting especially when P3D does support so many add-ons.

 

Cheers, Rob.

[rjack1282 316]

• Added a configuration option to the Prepar3D.cfg and Camera Definitions that allows cameras to share a single terrain view

Added an option to specify whether or not a panel should write alpha when rendering into a texture

Can someone translate these into non-programmer terms?