NVIDIA to Cease Driver Development for 32-Bit Operating Systems
by Anton Shilov on December 28, 2017 11:30 AM EST
NVIDIA has announced plans to cease developing drivers supporting 32-bit operating systems for any GPU architecture in the near future. All NVIDIA GPU drivers published after the release 390 (due in early 2018) will only support x86-64 OSes. The decision marks an important milestone in the transition of the PC industry to 64-bit computing that has been ongoing for over a decade, but may upset some of the users who still run older machines or those that require drivers for embedded systems.
NVIDIA driver version 390 will be the final drivers from the company that will support 32-bit Windows 7/8/8.1/10, Linux or FreeBSD. Whatever version comes after, it will only run on 64-bit versions of OSes. The company will continue to release 32-bit drivers containing security fixes till January 2019, but has no plans to improve the performance or add features to such releases.
The transition of the PC industry from 32-bit to 64-bit has taken a very long time, but it seems to be in the final stages of completion, at least for consumer-based machines. AMD released the first x86-64 processors for PCs in late 2003, whereas Microsoft came up with Windows XP Professional x64 Edition for client computers in mid-2005, kicking off the transition of the PC industry to 64-bit computing. By now, all contemporary x86 processors are 64-bit capable and the vast majority of personal computers in all form-factors come with four or more gigabytes of RAM (that’s the maximum user addressable memory for a 32-bit OS), so the absolute majority of new PCs today run a 64-bit OS. The last remnants of 32-bit machines are often long-standing hold-overs, such as the machine that George RR Martin writes his Game of Thrones novels on (although he is still DOS based).
There other reason that springs to mind for using a 32-bit OS is for embedded systems, such as those running point-of-sale type environments, display walls, gambling machines, or monitoring. Although these systems are typically deployed for the super-long term, at some point between now and 19th January 2038 they will have to be replaced due to the Unix Epoch time-rollover bug that will affect all 32-bit systems (bug? feature? oversight! Surely no-one will still have a 32-bit system in 2038, right?).
According to Steam hardware survey there are 2.19% of users who continue to use 32-bit Windows. Those 32-bit systems are legacy machines and PCs that have to run old programs or hardware natively. Owners of such computers are hardly interested in the latest GPUs (modern graphics cards may come with more memory than a 32-bit OS can address) or driver features, so the end of support will likely go unnoticed by the vast majority of involved parties. Meanwhile, 2% – 2.2% out of a billion of PCs in use worldwide is 20 – 22 million systems (the actual number will be higher because not all PCs run Steam). Therefore, there definitely will be disgruntled owners of 32-bit PCs running entry-level GPUs released in the recent years and now left without updated driver support for the latest GPUs.
Related Reading
Source: NVIDIA
Facebook
Twitter
RSS
33 Comments
View All Comments
extide - Thursday, December 28, 2017 - link
"The same C and C++ code I write runs perfectly fine on x86, x64, armv7 and arm64 platforms, with zero modifications necessary."But do you write code that very closely interacts with hardware and the respective kernels in each situation? Sure it is good practice to have your code be as portable as possible but with stuff like this you definitely have more limitations than generic code.
ddriver - Friday, December 29, 2017 - link
That code would be a part of the thin and easily maintainable integration abstraction layer. Even for something like kernel space driver development you can the bulk of your code be 100% portable.That's one of the most common design mistakes - riddling your code all over with non-portable functionality. This turns porting into a nightmare. I personally never make direct use of any external resources, be that system calls or 3rd party libraries or even the C++ standard library. It is all handled by abstraction layers, so porting requires to reimplement only the abstraction layer, while all the remaining core logic, which is like 99.9% of the code remains the same, because it is completely abstracted away, there is no need to change anything, it just works.
jospoortvliet - Sunday, December 31, 2017 - link
Note that the NVIDIA code also has to be portable between kernels - lin/win/bsd & mac ;-)I bet the at least on some of those the API is different between 32/64bit
twtech - Tuesday, January 2, 2018 - link
If you aren't writing display drivers specifically, then I'd save criticism of their codebase until you know more about the specific reasons why they decided they want to drop 32-bit OS support. Also, the more platforms you support, the more platforms you have to test and optimize for. If some of those OS configurations are not being used with the newer hardware that new driver releases are targeting, then it's a waste of time to continue supporting them.timecop1818 - Friday, December 29, 2017 - link
> I would not doubt - someday in the next couple of years we will have 64 bit only Windows version.Windows server already only supports 64bit, last 32bit version was server 2008 or something iirc.
ztrouy - Thursday, December 28, 2017 - link
I am curious about a potential repercussion of this move, and that relates the x86 emulation provided by the new ARM version of Windows 10, as it's limited to 32 bit x86 emulation. Does this mean that ARM-based Windows 10 devices will be limited to integrated or AMD GPUs for the foreseeable future? Or am I misunderstanding something?haukionkannel - Thursday, December 28, 2017 - link
Most likely, or there will be generic driver that does not use any spesial features (read slow)But not big deal when we talk about arm x86 emulation. If it can render text and netpages and maybe even video, it is good enough, and those systems use build in gpu in anyway like phones and other ultra portable devices.
r3loaded - Thursday, December 28, 2017 - link
Nope, hardware drivers for Arm devices will be compiled natively as Arm AArch64 code by the SoC vendor. Emulation pertains only to user mode programs that are compiled for x86.HStewart - Thursday, December 28, 2017 - link
I don't believe any ARM device has support for NVidia cards and in any case if they did the device has about performance of Atom CPU - so why do it.Also I serious doubt there is emulation software for NVidia hardware out there.
ztrouy - Friday, December 29, 2017 - link
I'm not talking about some janky third-party Nvidia emulator, I'm talking about the official ARM port of Windows 10 by Microsoft. While lots of code is not specifically x86 reliant, for the code that does rely on x86 instructions, the ARM port has a built-in emulator for the x86 code. However, this emulator is limited to running 32 bit code, which could pose a problem in the future for more powerful ARM-based Windows devices as they would be incapable of connecting to Nvidia graphics, instead being limited to AMD and the integrated graphics.And yes R3loaded, that is the hope, however one has to wonder if Nvidia will actually do the same and compile their code to run natively on ARM-devices as well.