I wonder if dumping of 32bit and Fermi resolves into any speed improvements.

RejZoRI wonder if dumping of 32bit and Fermi resolves into any speed improvements.

Actually the lazybones left the Fermi functions in the kernel mode layer handler (nvlddmkm.sys).
They removed only CUDA 2.0 architecture from nvcompiler*.dll

So, the answer is no...

RejZoRI wonder if dumping of 32bit and Fermi resolves into any speed improvements.

It might in the long term, if legacy support prevents them from doing certain changes to the design.

But primarily it's about resource management. They have to draw the line somewhere in terms of legacy support, or the overall quality of the product will ultimately decline. Usually it's not even about money, but how to manage a large team efficiently. An ever-growing set of platforms and features will impact release cycles, resulting in new features arriving later and/or sacrificing QA. Even if they hire the best developers and QA personnel money can buy, and even with a good modular design and good unit tests etc. in place, any project will ultimately get to a point where more resources will just increase the overhead, resulting in having to choose between lowering quality, slowing down development or deprecating stuff.

I have never worked at neither Nvidia nor AMD, but I have great respect for their driver teams, since I know the pain of maintaining a code base across many platforms with an "ever-expanding" feature set. Deprecating stuff is usually not something developers do light-hearted, it can be really painful for a development team to have to disappoint a part of their user base, but ultimately something have to give. Even if all the developers work on isolated branches and do basic verification of their changes, many new problems/bugs occur when merging these together, resulting in extra team members adding to development and QA overhead. I know Nvidia's driver team have a huge backlog of feature-requests from enterprise customers, game developers and end users alike, in addition to their own wishes. I assume AMD's driver team does have a long backlog too, like most large projects do. One concrete example I know of from sources was the launch of DirectX 12, when Nvidia already had many resources tied up on CUDA development, leaving them to prioritize stability and quality of the basic implementation and delaying some performance tuning for a few months. They also chose to bring many of the driver level changes of DirectX 12 to the core of the driver, resulting in "less gains from DirectX 12" in the public's view. From a purely technical point of view, Nvidia make the right priorities, but from a PR perspective it has resulted in a negative impression lasting to this day.

This fundamental problem of balancing feature requests, product maintenance, PR and customer requests is not unique to Nvidia, it is probably something all developers of larger projects have experienced. I've been there many times myself trying to negotiate with product management and (important) customers; the customer wants feature X immediately, the developers want feature Y because it's important for the product in the long run, and know doing X first will just result in making Y twice as hard and X to be redone afterwards resulting in three times more effort, which again impacts the next feature request. Over many years I've seen many "stitched together" features accomplished through "quick fixes" which has ultimately ruined code bases, making products "unmaintainable", new features "impossible" and resulting in notoriously broken products, even sometimes developers resigning. I think nearly every long-term developer will know what I'm talking about here, perhaps even you have seen this.

So the answer is it's complicated…
I don't know if I answered your question :)

RejZoRI wonder if dumping of 32bit and Fermi resolves into any speed improvements.

There are different drivers for 32 and 64 bit. So no, the 32 bit driver cannot hold back the 64 bit driver, because the former is not even installed when you use the latter.
That said, with 32 bit gone, it could become possible to enable some optimizations and such that weren't possible before (the drivers are packaged separately, but they do share most of the code). Even so, there won't be any significant gains to be had.

Just a small FYI, there are multiple threads over at the official forums mentioning some issues with this driver, seems to be mainly with 1060 cards but saw 1080 mentioned in one thread. Sounds like it is best to hold off until they fix it.

forums.geforce.com/default/board/33/

Why the big version number jump?

newtekie1Why the big version number jump?

Source control (git) auto-versioning schemes when creating a new branch?
It would mean new branch got lot more development (and bugs) than the parent branch which got couple of game optimizations.

newtekie1Why the big version number jump?

Shedding 32 bit support means at least the build system was seriously simplified. That's new branch material and Nvidia's drivers have always been versioned after their development branches.

Well, gaming was ok with this latest driver but somehow windows became sluggish.....:wtf:
I went back to the previous one 391.35, all good again now.

Let's hope they finally fixed the Firefox TDR this time. Last driver claimed to have fixed and just reduced the occurrence rate (a lot, from once a day to once a week).

The new driver lowered my benchmark result of Far Cry 5 , for 8 to 10 FPS ,withGTX 1080 SLI .4K Ultra priset.from 68 to 58 FPS avrige . So we can say that the SLI correction is useless, even harmful.

bogamiThe new driver lowered my benchmark result of Far Cry 5 , for 8 to 10 FPS ,withGTX 1080 SLI .4K Ultra priset.from 68 to 58 FPS avrige . So we can say that the SLI correction is useless, even harmful.

Or, we could go out on a limb and say 1 sample is not statistically relevant :P
It still sucks for you, because you're the only "sample" you care about.

It seems the desktop monitor refresh rate isn't working properly with this driver, with or without G-Sync.

went back to 389.10