Monday, March 3rd 2025
NVIDIA GeForce RTX 50 Series Faces Compute Performance Issues Due to Dropped 32-bit Support
PassMark Software has identified the root cause behind unexpectedly low compute performance in NVIDIA's new GeForce RTX 5090, RTX 5080, and RTX 5070 Ti GPUs. The culprit: NVIDIA has silently discontinued support for 32-bit OpenCL and CUDA in its "Blackwell" architecture, causing compatibility issues with existing benchmarking tools and applications. The issue manifested when PassMark's DirectCompute benchmark returned the error code "CL_OUT_OF_RESOURCES (-5)" on RTX 5000 series cards. After investigation, developers confirmed that while the benchmark's primary application has been 64-bit for years, several compute sub-benchmarks still utilize 32-bit code that previously functioned correctly on RTX 4000 and earlier GPUs. This architectural change wasn't clearly documented by NVIDIA, whose developer website continues to display 32-bit code samples and documentation despite the removal of actual support.
The impact extends beyond benchmarking software. Applications built on legacy CUDA infrastructure, including technologies like PhysX, will experience significant performance degradation as computational tasks fall back to CPU processing rather than utilizing the GPU's parallel architecture. While this fallback mechanism allows older applications to run on the RTX 40 series and prior hardware, the RTX 5000 series handles these tasks exclusively through the CPU, resulting in substantially lower performance. PassMark is currently working to port the affected OpenCL code to 64-bit, allowing proper testing of the new GPUs' compute capabilities. However, they warn that many existing applications containing 32-bit OpenCL components may never function properly on RTX 5000 series cards without source code modifications. The benchmark developer also notes this change doesn't fully explain poor DirectX9 performance, suggesting additional architectural changes may affect legacy rendering pathways. PassMark updated its software today, but legacy benchmarks could still suffer. Below is an older benchmark run without the latest PassMark V11.1 build 1004 patches, showing just how much the newest generations suffers without a proper software support.
Sources:
PassMark on X, via Tom's Hardware
The impact extends beyond benchmarking software. Applications built on legacy CUDA infrastructure, including technologies like PhysX, will experience significant performance degradation as computational tasks fall back to CPU processing rather than utilizing the GPU's parallel architecture. While this fallback mechanism allows older applications to run on the RTX 40 series and prior hardware, the RTX 5000 series handles these tasks exclusively through the CPU, resulting in substantially lower performance. PassMark is currently working to port the affected OpenCL code to 64-bit, allowing proper testing of the new GPUs' compute capabilities. However, they warn that many existing applications containing 32-bit OpenCL components may never function properly on RTX 5000 series cards without source code modifications. The benchmark developer also notes this change doesn't fully explain poor DirectX9 performance, suggesting additional architectural changes may affect legacy rendering pathways. PassMark updated its software today, but legacy benchmarks could still suffer. Below is an older benchmark run without the latest PassMark V11.1 build 1004 patches, showing just how much the newest generations suffers without a proper software support.
52 Comments on NVIDIA GeForce RTX 50 Series Faces Compute Performance Issues Due to Dropped 32-bit Support
They need to back pedal on this. Offer 2 drivers at least, with one containing 32-bit support. Even if they don't update it as often as the 64-bit. But support this driver for at least 2 years or something.
Hell, they could likely even make some money like MS does with ESU on Windows. Have an ESU driver companies can pay for if they need to maintain 32-bit support.
I agree with you that the 5000-series has been a disaster. I really get the impression NVIDIA's A-team is all working on "AI" chips and the B-team was left to do consumer graphics, with the inevitable result that we got a B-grade product and a lot of unnecessary foot-shooting. Huang is not doing his job very well.
At a point in time you have a transition from the technology. With MSDOS we had the luck with dosbox.
I wonder how long nvidia will support those obsolete features in their driver packages. Especially when the driver package only is valid for certain graphic card generations. Obsolete feature opencl32? phsyx? cuda32?
--
The hole benchmark is faulty - P*ssmark
www.passmark.com/products/performancetest/history.php
x.com/PassMarkInc/status/1894279961374330896
The architecture is nearly identical to the previous gen judging by the performance "improvements" that scale pretty much linearly with transistors and power consumption so there was no real reason to have done this
I think I read recently that cuda32 is for 7 years already obsolete.
Did they say when they are going to fix their software ?
Edit: OpenCL? Even more irrelevant. Is anyone updating their OpenCL drivers? OpenCL was dead a decade ago.
On top of this Nvidia has the shitty habit of disclosing absolutely nothing about their ISA, like it's some sort of national secret.
PS
....and in a year from now people will keep saying how badly AMD hardware, drivers, features, support, everything/you name it, are.......Aaaaaaaa...........that's why......Huang is having a huge problem to fill all those AI orders and he is sending all the chips that somewhat fail quality check, but still can be called functional, to gamers.
www.khronos.org/conformance/adopters/conformant-products/opencl#submission_268
Anyhow, as others have already said, nvidia has deprecated 32-bit support since CUDA 9 (almost 8 years since then):Nvidia also never had proper backwards compatibility. Newer products always required a update to the CUDA version, so you'd have to rebuild your application to support the newest applications nonetheless.
PassMark developers should Not accuse NVIDIA in any wrong doing and they simply should Not allocate any blocks of memory greater than 2 GB, or significantly exceeding 2 GB, for 32-bit applications.
Many companies already dropped full support for any 32-bit applications.
PassMark developers stated that some tests are 32-bit and it is Not clear why they did Not port these tests to 64-bit.
PS: All my internal HPC related OpenCL 32-bit tests do Not allocate greater than 2 GB of memory and, actually I do Not pay attention for these 32-bit verifications for a long time.
Do Not blame somebody else and look at what is wrong on your side first.
Also, in a 64-bit world it is Not possible to mix 64-bit and 32-bit codes. Microsoft had a similar problem many years ago when trying to mix 32-bit and 16-bit codes in Windows 3.1 with Win32s extension, Windows 95, Windows for Workgroups, etc 32-bit operating systems. A solution from Microsoft was very complex, unreliable, and based on thunk-based technique.
In the middle of 90th we had a problem on a financial project with mixing 32-bit and 16-bit codes and a Microsoft DDE ( Dynamic Data Exchange Win32 API ) client-server solution was used to "execute" 16-bit codes from a client DLL in a 32-bit server application. That was very complex, I personally worked on it, and the solution was abandoned after a provider of the 16-bit cryptography DLL finally released the 32-bit version.
I would Not worry about problems of PassMark and I would Not blame NVIDIA for Not clearly informing PassMark developers about dropped support.
NVIDIA always makes critical notes in Release Notes and companies involved in Software Development should read them on NVIDIA website, for example for a driver ABC for a GPU card XYZ.
PassMark developers, just port all these 32-bit tests to 64-bit world and forget about it.
Hell, it was created by Apple and even they don’t support it anymore.
GPUs work in a regime where almost everything is compiled first before running anyway, it's very bizarre to drop support for something unless there was a technical reason to do so. It's one thing to drop support for development and a different thing to remove the ability to run certain software entirely.
Things must move on? Sure. This way? At all.
Imagine intel or AMD dropping suport of some 32bit instructions or sets without prior warning... any warning.
We should learn from that topic. Passmark is not really a decent benchmark software. Someone there is unable to read the release notes. They do not have proper coders or enough coders to keep their benchmarks up to date.
If you do not know which libaries you use in a project - you have an issue.
32bit is dead in my point of view for personal computers.