Discussion in 'Videocards - NVIDIA GeForce Drivers Section' started by Astyanax, Apr 17, 2020.
Not a problem here.
Good for you yeah it just started out of the blue maybe it's not related to the driver but I had crashes with GT5 and Fortnite also bad ones with GSOD I went back to the latest game ready driver and so far so good we will see if it holds up
ps with alt tabbing it's a crash for sure
Update cleaned the card but running 3dMark program crashes also any body have some thoughts about it ? temps are normal btw clock also
Update 01 Was using a older version of DDU downloaded latest back on this driver now 3DMark works and no crashes yet with games
nvm GTA5 just crashed feels bad
I have no idea how, but the idle clocks thing might be gone. I didn't do anything to fix it. Yesterday the card idled at 670.5 MHz. Powered on today, and the only thing that changed was a new beta for HWiNFO64. That's all. And just like that, with one app that's not even installed, the behavior is back to normal. Worth mentioning that this idle behavior occurred with or without HWiNFO64 running, and was detected by GPUZ and MSIAB, so I wouldn't pin this on HWiNFO.
Oh, and I left HWiNFO in the background for 3-4 days, sometimes up to 14 hrs. The card would just not go below 670MHz, it would only idle at 139MHz shortly after boot, after that something loaded/got executed in the OS and the card would be stuck at 670MHz at idle. So it's not like I might have missed it.
I'm running W10 2004 and with HW-accelerated GPU scheduling turned on I also notice frame-pacing in my games. (eg. Call of duty Warzone)
Aside of that a had once a critical error crash in Warzone, which I never had before.
Then I also believe that 450.xx with HW-Accelerated GPU Scheduling turned OFF gives me a slightly higher GPU time in Warzone than 445.87.
I reverted back to 445.87
I just wanted to provide an explanation as to the behavior users are seeing with GPU hardware scheduling enabled using R450 drivers on Windows 10 2004. With hardware scheduling disabled, the NVIDIA driver is able to report additional nodes to the operating system (eg. compute_0, compute_1). When you enable hardware scheduling, all of the resources are no longer virtualized and instead are reported as a single 3D node. So while you are not losing compute or CUDA with hardware scheduling enabled, you won't see the additional resources in the Task Manager -> Performance -> GPU info.
Thanks for the info, how HW-accelerated GPU scheduling works.
So I guessed correctly that compute remains enabled, just impossible to monitor, nice.
I wonder how the 100% usage we see more often with HAGS instead of the 98-99% that was typical on Pascal is related, if at all. Were those 1-2% "missing" actually utilized by some other process?
GPU utilization is always a sort-of estimate. For example, Tensor are RT cores are usually idle, and not even all CUDA cores are evenly utilized at all times by graphic tasks (there are other parts, thus other potential bottlenecks in the GPU), etc, etc. Just think about how synthetic demos like FurMark can "burn" so much electricity and cause constant clock throttling (through TDP limit).
Got a TDR in Gears5, not in menus since I remember there was such a bug, but gameplay. All stock.
Seems quite typical of DX12 games like Division2, which I don't think was ever fully fixed.
Nothing inside c:\Windows\LiveKernelReports.
my experience with dx12 is that just about every driver crash is a matter of overall system stability and drivers can just play better or worse in conditions where something that hasn't entirely been stabilized exists in the machine, quite often being the vendor overclocked board that one buys for that extra 1fps - If not an issue with the application itself, since replay threads are the most common scenario that game developers screw up.
See the change here for example; https://github.com/megai2/d912pxy/commit/8d89dab633a6712f83d9c4f07b5ef070db1199d8
How long until we will see new version?
My bet is 1-2 weeks top (20H1 should pop up on the retail ring during next week according top latest leaks and this preview is very unstable, so I guess another preview is in order before any stable WDDM 2.7 release).
There is a newer 450.99 being pushed on WU.
Anyone got the driver yet?
no, its probably specifically for 196xx users.
I've not had a crash in DX12 with Division 2 in a very long time. The difference? Lowered my GPU memory OC 100mhz effective versus running in DX11. So 11.5ghz versus 11.6. I mostly concur with Astyanax here. Generally DX12 exposes flaws in a system versus DX11. That is not to say there's not some really crap DX12 games out there.
Yeah, but I am running full stock.
I can run Vulkan and DX11 at 4K for max stress, and there will never be any issues.
Yet with DX12 games, there are these rare TDRs. Always TDRs, not actual crashing. Just the game losing the card.
So it's pure Dx12, and unrelated to GPU load/stress. Hell, I can OC and run Vulkan/DX11 4K, without TDRs.
What flaws are exposed here? If the GPU was unstable, I'd get TDRs in other APIs.
It's also a game engine thing.
Strange Brigade for example never-ever had TDRs in DX12 or Vulkan. Gears5, very, very rare. Division 2 would TDR each hour on Dx12, this is why I didn't buy the game.
Uploading 450.99 now
Absolutely wrong, trust me.
At one point in time I owned a Geforce FX and tried running it at AGP8x on a KT600a, a via chipset known to have numerous issues with 8x.
The card would run just perfectly in anything that was OpenGL, but soon as I tried 3dmark or anything DirectX the applications artifacted like crazy, hung and crashed.
At 4x the system was fine, and 8x on an nforce2 mobo was also fine.
Theres also the fact that Nvidia's Vulkan inherits a number of the opengl specific traits and behaviors that nvidia's driver includes through being implemeted in the opengl client driver.