Can anyone else confirm that when Ultra water detail level is selected the nvidia driver P-State drops down to P2 level - GPU-Z or Nvidia Inspector can be used to check for this.
On my hardware (see below) this issue exists on both my Windows 8.1u1 and Windows 10 dual boot. These were both fresh installs with no other software except Prepar3d. Zero tweaks and addons.
The issue is repeatable and happens either if changed when running or before starting the App after editing the config file. Dropping the setting from Ultra to any other level sees P0 restored. It seems to be independent of any other setting, tessellation level, LOD, etc. Selecting ‘Prefer Maximum Performance’ in NI has no effect either.
On Windows 10 the CPU usage also goes to 100% on all 4 cores although this is not the case with 8.1.
P-State level P2 means that the GPU is only running at around 80-90% of its potential and so is a big performance hit on top of what might be expected for clicking the slider one more position to the right. This means lower base clock speed, boost will not kick in and VRAM memory speed is limited to 3000Mhz rather than 3500Mhz. Also any GPU overclocking - which is usually setup for P0 state - will not see the benefit while in P2.
If you are running Ultra water may want to check this out as I have been doing so since purchasing the 980GTX and thus have not being using it to its full potential!
4790K @ 4.8/46
980GTX
Windows 10 - driver 352.84
Windows 8.1u1 - driver 353.06
Selecting Ultra water detail setting causes P2 state lock-in on nvidia drivers?
-
francescodoenz
- Posts: 252
- Joined: Thu Oct 25, 2012 6:13 pm
- Location: Morges,Switzerland,
A few more folk have responded on the AVSIM thread I created which indicates that it *may* be based on GPU; here's a link to that thread.
http://forum.avsim.net/topic/469972-sel ... ia-drivers
@Francesco - I give some detail in the first post of that thread but in brief the PState is similar to the gears in your car with P0 being the gear that gives best performance. Running P2 means the graphics card performance is being restricted.
http://forum.avsim.net/topic/469972-sel ... ia-drivers
@Francesco - I give some detail in the first post of that thread but in brief the PState is similar to the gears in your car with P0 being the gear that gives best performance. Running P2 means the graphics card performance is being restricted.
-
Beau Hollis
- Lockheed Martin
- Posts: 2452
- Joined: Wed Oct 06, 2010 3:25 pm
When Ultra water is enabled, the 3D waves are enabled. The 3D wave simulation relies on CUDA when using NVidia hardware. My guess would be that either:
a) In the case of using CUDA and Rendering pipelines in the same app the driver drops the level to reserve resources for CUDA
b) The level drop is a because our water simulation does not build against the most current cuda libraries.
When last I tested, the cuda based wave simulation was faster than the Direct Compute version (which is used by any cards lacking cuda support). If you want to try using Direct Compute, you can do the following:
1) Open File: Prepar3D v2\TritonResources\Triton.cfg
2) change "disable-cuda = no" to "disable-cuda = yes". This should be around line 128.
3) Try to fight the urge to tinker with the rest of the config options.
4) If you fail at step 3, please back up your config file first. It's very easy to break the water or even cause crashes by changing settings in this file because we only use a small subset of the Triton library and we modified the source to disable features we're not using.
a) In the case of using CUDA and Rendering pipelines in the same app the driver drops the level to reserve resources for CUDA
b) The level drop is a because our water simulation does not build against the most current cuda libraries.
When last I tested, the cuda based wave simulation was faster than the Direct Compute version (which is used by any cards lacking cuda support). If you want to try using Direct Compute, you can do the following:
1) Open File: Prepar3D v2\TritonResources\Triton.cfg
2) change "disable-cuda = no" to "disable-cuda = yes". This should be around line 128.
3) Try to fight the urge to tinker with the rest of the config options.
4) If you fail at step 3, please back up your config file first. It's very easy to break the water or even cause crashes by changing settings in this file because we only use a small subset of the Triton library and we modified the source to disable features we're not using.
Beau Hollis
Prepar3D Software Architect
Prepar3D Software Architect
I can confirm that the fix works and Ultra water leaves the Power State at P0. I appreciate your quick response and accurate diagnosis.
I'm curious just to how sub-optimal this fix is though as you mention the preferred technique is to use CUDA. Can you estimate the performance drop observed during your testing when using Direct Compute actually is?
I'm also curious as to the apparent random nature of the anomaly. Certainly all those who posted on the avsim forum confirming they had the issue had recent cards which would support CUDA as expected.
I'm curious just to how sub-optimal this fix is though as you mention the preferred technique is to use CUDA. Can you estimate the performance drop observed during your testing when using Direct Compute actually is?
I'm also curious as to the apparent random nature of the anomaly. Certainly all those who posted on the avsim forum confirming they had the issue had recent cards which would support CUDA as expected.
-
Beau Hollis
- Lockheed Martin
- Posts: 2452
- Joined: Wed Oct 06, 2010 3:25 pm
The best way to compare performance would be:
1) max out water slider
2) turn down everything else.
3) Make sure the sim isn't paused and turn off frame limiting
4) Save a flight in the middle of the ocean or desert
Note that the wave simulation will run each frame regardless of if you're close enough to the water to notice. If you want to see the waves, you'll want to save your flight over water and keep the dem resolution on 1m and the tess factor reasonably high. The actual rendering of the waves is done through our standard tessellated terrain shader and does not itself rely on compute or cuda though so you don't actually need to see the waves to test the perf difference. As long as the frame time is relatively consistant with whatever settings you're using and you're not CPU bound, it should be fairly strait forward to calculate the time difference between the two modes.
I believe compute shader broadcast is enabled in our SLI profile now, so the compute based waves may actually play nicer with SLI. I haven't had a chance to test it yet.
One of the main reasons we turned on CUDA by default is that we were seeing occasional crashes in the compute version when during loading after certain settings changes. The crash was happening inside a microsoft Compute FFT library that which Triton relies on for the Compute version of the waves. I'll log a ticket to look into this for v3. I suspect this issue may already be addressed in newer Triton builds.
1) max out water slider
2) turn down everything else.
3) Make sure the sim isn't paused and turn off frame limiting
4) Save a flight in the middle of the ocean or desert
Note that the wave simulation will run each frame regardless of if you're close enough to the water to notice. If you want to see the waves, you'll want to save your flight over water and keep the dem resolution on 1m and the tess factor reasonably high. The actual rendering of the waves is done through our standard tessellated terrain shader and does not itself rely on compute or cuda though so you don't actually need to see the waves to test the perf difference. As long as the frame time is relatively consistant with whatever settings you're using and you're not CPU bound, it should be fairly strait forward to calculate the time difference between the two modes.
I believe compute shader broadcast is enabled in our SLI profile now, so the compute based waves may actually play nicer with SLI. I haven't had a chance to test it yet.
One of the main reasons we turned on CUDA by default is that we were seeing occasional crashes in the compute version when during loading after certain settings changes. The crash was happening inside a microsoft Compute FFT library that which Triton relies on for the Compute version of the waves. I'll log a ticket to look into this for v3. I suspect this issue may already be addressed in newer Triton builds.
Beau Hollis
Prepar3D Software Architect
Prepar3D Software Architect
Thanks Beau
What I want to know is P0 state Ultra water using Direct Compute noticeably slower than P0 state Ultra water using CUDA! Of course I cannot personally compare those scenarios as when I switch to Ultra water P2 is forced (without your successful workaround) and so I'm comparing dissimilar results. I guess I could force P2 state for both situations and compare that but not sure how valid that test is. (Edit: I think the difference is going to be vanishingly small compared to the improvement that P0 with Direct Compute has over P2 with CUDA but I'm always curious).
I would still like to know what is the factor that makes some systems exhibit the bug and some systems not
A.
What I want to know is P0 state Ultra water using Direct Compute noticeably slower than P0 state Ultra water using CUDA! Of course I cannot personally compare those scenarios as when I switch to Ultra water P2 is forced (without your successful workaround) and so I'm comparing dissimilar results. I guess I could force P2 state for both situations and compare that but not sure how valid that test is. (Edit: I think the difference is going to be vanishingly small compared to the improvement that P0 with Direct Compute has over P2 with CUDA but I'm always curious).
I would still like to know what is the factor that makes some systems exhibit the bug and some systems not
A.
-
jzimmermann
- Posts: 53
- Joined: Sat Jun 02, 2012 11:00 pm
Hi Beau,
Thank you very much for the detailed explanation. I noticed that in some cases after changing “disable-cuda = yes” this will invoke the dxdiag.exe to run just as P3Dv2.5 shows that it has loaded 100%, and then a few seconds later this leads to a CTD without any error message. For some reason so far on my system this only happens when I double-click on a saved scenario in the documents/p3dv2.5 subfolder.
It almost seems like something is looking for a CUDA GPU, flags it as not found, and then invokes the dxdiag to go looking if there are any hardware problems.
Is there any other way of fixing the P2 state to P0 with water detail at ultra? Any chance of a proper HOTFIX or is v3 round the corner?
Cheers,
Jerome
Thank you very much for the detailed explanation. I noticed that in some cases after changing “disable-cuda = yes” this will invoke the dxdiag.exe to run just as P3Dv2.5 shows that it has loaded 100%, and then a few seconds later this leads to a CTD without any error message. For some reason so far on my system this only happens when I double-click on a saved scenario in the documents/p3dv2.5 subfolder.
It almost seems like something is looking for a CUDA GPU, flags it as not found, and then invokes the dxdiag to go looking if there are any hardware problems.
Is there any other way of fixing the P2 state to P0 with water detail at ultra? Any chance of a proper HOTFIX or is v3 round the corner?
Cheers,
Jerome
-
Dave_YVRATC
- Posts: 19
- Joined: Mon Apr 02, 2012 12:16 am
Re: Selecting Ultra water detail setting causes P2 state lock-in on nvidia drivers?
Resurrecting an old thread here but it seems that this issue wasn't addressed in v3.
Re: Selecting Ultra water detail setting causes P2 state lock-in on nvidia drivers?
[edit] Confirming this is still an issue as well.
