2. Attempt to assign the Elevator Trim to the Saitek Trim Wheel ... dialog comes up

 

 

Only way to exit P3D once in this "mode" is to do a hard reboot (reset button on power button).

 

 

 

What OS are you using?

 

Do you plug the wheel into the Yoke USB port or direct to PC?

 

Cheers, Rob.

I didn't need to go anywhere near the controls dialogue I simply plug in the trim wheel and it auto sets as elevator trim...again this is all I've ever done v3 back through v1.4!

 

Win 10 now but same on 8.1 (both 64) and via yoke USB port.

 

 

Edit: okay so I followed your steps to see what would happen and once I open the controllers dialog and select Cessna trim wheel I see x axis already assigned to elevator trim, so delete this and reassign, move trim wheel and nothing gets assigned BUT nothing crashes either. Can back out of dialog into sim. Glad I kept a copy of my XML file though!

Well, I have been following this topic...and so decided to see if my GTX680 2GB card would drop to the P2 state from P0 when running with water as ULTRA.

 

So..here's the dope for a GTX 680 running P3D v2.4:

 

At rest before starting up P3D, the P state was :

 

P8

 

As soon as I clicked on the P3D program button, my P state went to P0

 

P3D v2.4 came up with ULTRA enabled (as that is the way I use water).

 

Floating on the Parry Sound Lake...in an amphib, the P state was still P0

 

I then switched from Ultra to High, and the P state stayed at P0

 

Switched back to Ultra...and the P state remained at P0

 

I do have my system set to prefer Max Power, and also that as well in the nVidia driver mask.

I also have the driver pegged to a single monitor. (For those that have only one monitor, but might have this set to multi-monitors...could this have a bearing?)

 

After dropping out of P3D v2.4, my card powered down to P8 at the Desktop.

 

So, that's my P0/Ultra story about a man, named Jed...

 

I've actually stopped using SLI now, just using a single Titan X for now.

 

Cheers, Rob.

 

Hmm.. sounds like a big step backwards.

Is this a FPS or artifacts issue?

 

gb.

Hmm.. sounds like a big step backwards.

Is this a FPS or artifacts issue?

 

gb.

This issue I described in the OP of this thread can be seen (in certain systems) with or without SLI.

 

My own experience is that SLI works perfectly in v3 with zero artifacts or issues.

My case:

 

Windows 8.1 x64; Prepar3D V3; nVidia GTX680; Core i7 4790K

 

Video card is idling at P8, when starting P3D it jumps immediately to P0 and while flying it switches back to P2. Once i put the water detail one notch below maximum, performance climbs to P0.

My case:

 

Windows 8.1 x64; Prepar3D V3; nVidia GTX680; Core i7 4790K

 

Video card is idling at P8, when starting P3D it jumps immediately to P0 and while flying it switches back to P2. Once i put the water detail one notch below maximum, performance climbs to P0.

If you'd prefer to use maximum water and still maintain P0 there is a workaround earlier in this thread from LM.

Is this a FPS or artifacts issue?

 

No artifacts, that's resolved in V3.

 

However, no FPS gain and there seems to be some conflict with my SLI setup and the CUDA libraries when Water = Ultra as it can cause excessive performance drop.

 

SLI is still VERY useful if you are using NI to get SGSS AA ... then you should see a significant benefit especially when flying thru dense cloud layers.

 

Hopefully LM update the CUDA libraries to more recent ones from nVidia.

 

Cheers, Rob.

This still doesn't seem to be resolved in v3.1, despite the new Triton files contained therein. Is that expected?

SD, confirmed that this still occurs (this is apparently a Nvidia design decision as CUDA was intended to be used for high-precision calculations) - I have a thread open on the LM forums. 

Thanks for the info Dylan - I'll keep an eye on that thread.

My workaround is to overclock p2 state to p0 clock frequencies. Benchmarking seems to show that performance is then equivalent and therefore I'm not experiencing an sli gtx 980 setup running at below optimum performance under p3d

 

boez

Although some are claiming that this phenomenon is driver related, I have never seen this happen, either with my old GTX 680 or my present GTX 980ti. Both are Evga products. I just checked this a few minutes ago and the 980ti runs at 1315 GPU clock in P3d 3.1, either with water on ultra or any other setting. That matches how it runs in other 3D apps. I am running the most recent nVidia driver.

 

That leads me to believe that the dropdown to P2 is more likely cancelled out by the way Evga clocks their chips from within the card's BIOS. It has to be something like that for some people to get one result and other people to get another.

Although some are claiming that this phenomenon is driver related, I have never seen this happen, either with my old GTX 680 or my present GTX 980ti. Both are Evga products. I just checked this a few minutes ago and the 980ti runs at 1315 GPU clock in P3d 3.1, either with water on ultra or any other setting. That matches how it runs in other 3D apps. I am running the most recent nVidia driver.

 

That leads me to believe that the dropdown to P2 is more likely cancelled out by the way Evga clocks their chips from within the card's BIOS. It has to be something like that for some people to get one result and other people to get another.

 

The issue is on the memory clock, not on the core clock. You have to check the memory clock. Everybody has it, Lockheed Martin knows and confirmed the issue.

Yes the P0 and P2 issue is a memory clock issue, core clock will change as expected.  What actual affect it has on an end users system running P3D is not clear to me ... I saw zero impact, but maybe when one starts getting close to 95% mark the increase memory clock will help?

 

Anyway, I made a quick video pointing out the issue (sorry it's in 4K so lower res might have a hard time seeing the numbers):

 

 

Who needs to fix this ... the updated CUDA libraries come form nVidia and the GPU is nVidia and the drivers are nVidia sooooo, I'm thinking if this is to be "fixed" it will have to come from nVidia.

 

Cheers, Rob.

'Rob Ainscough', on 31 Dec 2015 - 03:09 AM, said:

What actual affect it has on an end users system running P3D is not clear to me

 

You're right.

 

So, the cards do not "drop down to the P2 state" when water is set to ultra. Only the video RAM declocks to P2. Generally, the difference between P0 and P2 is most noticeable in the GPU clock (usually ~ 20% with high end cards). The difference in the video RAM clock speed is generally less than 20% and often not even 15%. Since the GPU clock usually impacts performance more than the VRAM clock, the performance difference in almost any 3D app would be marginal. A VRAM OC might be a factor either on a video card with limited VRAM bandwidth or maybe with a 3D app that has a lot of processing that is VRAM intensive (complex AA??).

 

Besides, with P3d, one would have to find a circumstance where the video card was the limiting factor in performance and that happens so rarely, as to be a non-factor.

'ca_metal', on 30 Dec 2015 - 11:04 PM, said:

Lockheed Martin knows and confirmed the issue.

 

I wonder if this is an "issue" when viewed from another angle. CUDA is used (in the simplest terms) for "math calculations on the GPU". Anyone who has played around with overclocking their CPU knows that most of the OC stress tests use two measures in order to determine whether an OC is stable. The first measure is heat. That's the obvious one. The second measure is mathematical precision. The stress test app's math result is off by even a small amount, the OC is deemed unstable. The same will be true with using CUDA to perform wave calculations in P3d. It's quite possible that at a pure P0 state, on certain video cards, precision using CUDA will be lost and the calculations will produce odd visual results with the water. It really depends how the Triton SDK uses CUDA and whether precision is an important factor.

 

Basically, nVidia did this on purpose, but for consumer level apps like P3d, they really should provide a variable in the 3D profile to turn off the downclocking of the VRAM. Then users could decide for themselves whether there is an issue or not.