NVIDIA Hotfix GeForce 511.72 driver download & Discussion

actually, I just realised a possibility for it to do what you're saying.

if the access is not happening on the same core and its hyperthread each time, the cpu would possibly have cached the operations involved,
That would look like low cpu usage and barely affect games themselves, but significantly affect benchmarks.

I do have a question on the stability of the resources being used by DWM.exe, is Handle and Object counts stable, or are they increasing with time?

 

how do I check Handle and object counts ?

 

they can be enabled in task manager details, or you can double click dwm.exe from in process explorer.

 

I think it doesnt look that high, explorer has more, will try older driver some other day and see for sure..

 

Sorry, won't do that again, got carried away.

 

Looks fine, it should rise and fall but settle around the same number once windows and menus are closed or animations complete.

 

I have similar values, while using 511.65

 

Im using those too, just posted here since it has more talk about it

 

You're points are valid. My effort and concern, is that if these issues are not fixed they will be propagated continually into newer drivers and relegated. I stay on 472 and I do have long term systems - but, if I don't contribute, then when its never fixed, then then it becomes the norm to say "why didn't you report it to us or let someone know?

Its not about dch, its about the change to whatever new methodology has caused these issues. Again, issues are resolved when reverting. I'm selfish -- I just want it fixed. No matter how it is explained away, the driver change from 496 onwards has introduced issues, This something similar from the (post (398.xx) 400 series up until the 431 release and it was finally fixed (DisplayPort issues / performance hit, stutter at high resolutions) when it was fixed there was NO mention in the PDF about what it was or how it was fixed. Completely different than the Detroit Become Human fix with every driver release

Guess it feels the same this time around.

Its supposed to be just an OS, not a way of life, and its supposed to be just a video driver (that works) and not part of some ecosystem. Can I just have drivers that improve with age and gain performance and stability (free from all the other ecosystem crap)?


PS. I do not have a single chrome app on my builds as far as I know. No store apps, no edge, no google chrome, etc.

 

wait what ? when i asked you before is there a way to convert dch driver into standart package to use in 1607 LTSB you said no

 

Maybe playing the devils advocate, but would you have done so yourself when you look at how you got the message across?

Apart from that, LTSB as LTSC users got their standard drivers.
For gaming a propper OS with the full support for it should be used, with LTSX as the chosen OS support for features that it was not intended for to begin with fully rely on the operator and not the suppliers.

 

the Setup files won't run on 1607.

 

There too many things off to report about those 511.
In mine opinion the driver on DEV_17C8 work as INF installation path duo the digital signature and that's it. The driver doesn't actually work on code and dependency.
else
There an embedded monitoring tool within the package running outside the GPU scope.
Just taking few example here.

Request appear delayed on process-explorer like report.
Kernel stack +10K (old value STANDARD 471.96) on RamMap with 511.
ETL signifying X2 size increase on XPERF same task (example driver install/compattelrunner or any measured point)
Time execution double on any task tied with SYSTEM.

If you have any idea how to tackle the issue, feel free to advise.
Thank You.

 

Cause of WDDM requirements, right?

 

Chill. There's an ignore option, I apologized if I was getting too much off-topic, but I stand from what I said.

 

From my point of view an increase in ram and vram usage can be a good thing as long as it is properly utilized and doesn't lead to running out of memory.

 

because they sideload the AppX package for the control panel, minimum supported OS version is increased to 1709 at the least, this is hard coded into the coinstaller dlls.

modification to the inf is all thats necessary to make a dch driver execute a standard packages NvCPLSetupInt

 

what exactly do you mean by that?
i actually need to check which version i have(the cable itself was a newer model that i got recently, but probl. doesn't matter if the monitor etc. only supports 1.2 for example, right?)

what do i need to set it to to resolve the issue?
(of course if that's the reason why it's happening to begin with, the display version i mean.)

 

numerous Freesync displays control the status of VESA Adaptive-Sync based on whether you have the screen set to DP 1.2 or not rather than seperately exposing it in the OSD, based on the fact that its a 1.2a capability.

 

Screenshot doesn't show much since other process down are affected with the introduced threaded DPC behavior changes.
Driver work partially on installation without reboot. Restarting the driver without rebooting make it almost fully work.
Rebooting the system make it exhibit issue all around while removing component like _nvtopps _nvppo NVProfileUpdaterPlugin or commenting trough _DisplayDriverRAS telemetry out make the driver goes berserk.
Using in toto the older NVdisplayContainer for the older MessageBus somehow alleviate but not quite whatever the nvidia KDM is doing. Yet is like having a Gefore 256 with the control panel open on the desktop!