According to https://www.notebookcheck.net/Strange-GeForce-RTX-50-series-benchmark-issues-solved-but-new-problem-for-gamers-arises.967614.0.html , Nvidia RTX 50 series GPUs remove support for 32-bit CUDA and 32-bit OpenCL. It is possible that both BOINC server software and BOINC client software need to be made aware of this lack of 32-bit CUDA support and 32-bit OpenCL support so that 32-bit CUDA tasks and 32-bit OpenCL tasks are not sent to clients with GPUs that cannot handle them.

I am making this thread after making a thread about BOINC clients because I realized that BOINC server software and not just BOINC client software probably need to be modified to take into account the breaking changes that removing 32-bit CUDA and 32-bit OpenCL support are.

I am making this thread after making a thread about BOINC clients because I realized that BOINC server software and not just BOINC client software probably need to be modified to take into account the breaking changes that removing 32-bit CUDA and 32-bit OpenCL support are.

An unofficial driver allowing 32-bit CUDO and Open CL would seem a simpler solution than modifying the BOINC server code. I am pretty sure the gaming community will come up with something given time.

Best post this information at BOINC Github.
https://github.com/BOINC/boinc/issues

seems like a non-issue.

the 50 series requires the latest drivers, which don't work on 32-bit systems anyway. BOINC doesnt need to be updated for this since these cards will never be on a 32-bit system.

---

You misunderstood the problem. Previously, it was fine to assume that 32-bit CUDA and 32-bit Nvidia OpenCL tasks would work on 64-bit clients that have Nvidia GPUs, so servers would send 32-bit Nvidia GPU tasks to such clients. Nvidia broke that assumption by removing support for 32-bit CUDA and 32-bit OpenCL applications starting with the Blackwell architecture GPUs.

BOINC clients and/or servers need to be modified to do one of 3 possibilities: whitelist which Nvidia GPUs that are running on 64-bit OSes that can accept 32-bit GPU tasks (the best choice if Nvidia continues to refuse to support 32-bit CUDA and 32-bit OpenCL in Blackwell and future GPUs), blacklist Blackwell and any other future Nvidia GPUs that lack 32-bit CUDA and 32-bit OpenCL support (could work if Nvidia reverses course on future GPUs. This could work with a driver check if Nvidia adds a shim to translate 32-bit CUDA to 64-bit CUDA for Blackwell probably because Nvidia looks like it is using an OpenCL to CUDA shim), or no longer send 32-bit Nvidia GPUs tasks to 64-bit clients.

I looked at the Github and am feeling a bit lost on how to file and properly classify the issue so that it gets the correct priority level. Could someone who has better experience with the Github file the issue there?

Okay, I opened one (#6125), just copied your starting post and added labels. But if I were you, I would add all required information to it that you posted in this thread. You're the OP on this, I can't answer any questions from developers on this.

In reply to Jesse Viviano's message of 27 Feb 2025:

You misunderstood the problem. Previously, it was fine to assume that 32-bit CUDA and 32-bit Nvidia OpenCL tasks would work on 64-bit clients that have Nvidia GPUs, so servers would send 32-bit Nvidia GPU tasks to such clients. Nvidia broke that assumption by removing support for 32-bit CUDA and 32-bit OpenCL applications starting with the Blackwell architecture GPUs.

BOINC clients and/or servers need to be modified to do one of 3 possibilities: whitelist which Nvidia GPUs that are running on 64-bit OSes that can accept 32-bit GPU tasks (the best choice if Nvidia continues to refuse to support 32-bit CUDA and 32-bit OpenCL in Blackwell and future GPUs), blacklist Blackwell and any other future Nvidia GPUs that lack 32-bit CUDA and 32-bit OpenCL support (could work if Nvidia reverses course on future GPUs. This could work with a driver check if Nvidia adds a shim to translate 32-bit CUDA to 64-bit CUDA for Blackwell probably because Nvidia looks like it is using an OpenCL to CUDA shim), or no longer send 32-bit Nvidia GPUs tasks to 64-bit clients.

64-bit hosts can add the <no_alt_platform> argument to their cc_config and they will not be sent any 32-bit work.

no change needed to BOINC or the projects.

---

64-bit hosts can add the <no_alt_platform> argument to their cc_config and they will not be sent any 32-bit work.

However there are a lot of people using BOINC who set and forget who wouldn't know a cc_config file if it jumped out and bit them!

that doesn't mean you need to re-engineer the whole thing on the backend just to placate people who don't know how to use the tools already available to them.

educate the user how to use the features already available. that's why they are available in the first place. editing a text file is easy to do, and once done doesn't need to be done again. that's pretty "set it and forget it" to me. setting client level configurations isnt too much of a burden.

---

that doesn't mean you need to re-engineer the whole thing on the backend just to placate people who don't know how to use the tools already available to them.

I agree however with large numbers of computers with users who don't check what is happening, the issue of tasks being sent to computers that will immediately crash them remains. With the cards in question being in the realms of hen's teeth it will I guess be a few years before it is a significant problem.

In reply to Dave's message of 1 Mar 2025:

With the cards in question being in the realms of hen's teeth it will I guess be a few years before it is a significant problem.

The fact is that Nvidia has 90% market share for discrete GPUs. No matter how screwed up this release has been, and no matter how good AMDs release turns out (nor Intel's improvements in hardware and drivers for Battlemage), as people upgrade their video cards, they will pretty much be Nvidia.
They have mostly shut down all RTX 4xxxx production to move it over to RTX 5xxxx production, and if the truth of production output lies somewhere between the rumours & official statements (huge cancellations of AI/ML Blackwell orders v Nvidia has a 12 month backlog of orders to fill), i can see it being an issue towards the end of this year.



Even so, i agree with Ian&Steve C. with this not being a BOINC issue.
It will be a project issue- just as it always has been when there have been hardware/driver problems. Each project will just have to configure their systems to only give work out to hardware/software combinations that are able to process it, just as they do now (eg minimum VRAM requirements, minimum hardware architecture requirements, minimum driver version/minimum CUDA version/feature support).

As i said- this will be a project, not a BOINC issue (unless there is some development to help with how the server determines which application it can or can't send out, which is set by the project...).

---

Grant
Darwin NT.

In reply to Ian&Steve C.'s message of 1 Mar 2025:

educate the user how to use the features already available.

That option is for advanced users only. People that won't immediately f-up all their xml text files. People that know how to go back when they encounter an error message. And next everyone wants these options in a GUI, built into the manager.

It's easier for the projects to set up a plan class, as they've done already for differentiating between other 32bit and 64bit applications, just add one here, build 64bit applications and send them according to the plan class only to clients with this GPU (for now).

people do the same thing whenever they have mixed GPU systems adding the <use_all_gpus> option. even non "advanced" users are able to add a simple entry to the cc_config with little issue. it's not all that hard and not all that advanced IMO.

---

In reply to Ian&Steve C.'s message of 2 Mar 2025:

people do the same thing whenever they have mixed GPU systems adding the <use_all_gpus> option. even non "advanced" users are able to add a simple entry to the cc_config with little issue. it's not all that hard and not all that advanced IMO.

If you're used to dealing with app_info.xml, it's not.
But for the average user (which is what BOINC is aimed at), that only ever has their manager on the SImple view, anything that requires more than selecting a check box is advanced.
Even more so when the Windows default is for the ProgramData folder to be hidden.

---

Grant
Darwin NT.

person has <problem>
person wants to fix <problem>
person asks how to fix <problem>
person is instructed/educated how to fix <problem>
person fixes <problem>

this is how it always goes. I've never seen someone ask for help with a config file that couldn't easily be coached with a few clear messages. being ignorant to the inner workings doesn't mean they can't or don't want to learn. the <use_all_gpus> issue is FAR more common, and every single time people simply tell the person how to implement that argument in the cc_config. and not once was there a push to redesign BOINC because of it. this is no different. it's an edge case. if a user actually has a problem related to it and want to fix it, they will ask, and be coached how.

the truly ignorant users who don't look at anything other than the simple view or tray icon are people who wont even notice errors to begin with. and all projects have error handling anyway.

---

It would help if the volunteers offering the instruction / education could think themselves back to day zero when phrasing their assistance. My script for <use_all_gpus> would start:

In order to fix this issue, you'll need to edit a file called "cc_config.xml".
This is an optional file, and your computer may not have one.
The easiest way to create one is to make a minor change to the Event Log Options selected.
Press 'ctrl+shift+A' in BOINC Manager to switch to advanced view.
Then press 'ctrl+shift+F' to see the options.
Change one (anything), and save the changes.
Open it again, and change it back (it might not have been a good choice!) and save it again.
Now you will find a complete "cc_config.xml" in [however you usually describe it].
Every legal setting is listed in alphabetical order - <use_all_gpus> is 6 lines before the end of the file.
Don't try adding it manually: duplicated tags can cancel each out.

In reply to Ian&Steve C.'s message of 2 Mar 2025:

person has <problem>
person wants to fix <problem>
person asks how to fix <problem>

The biggest problem here is that by the time the user noticed he has a problem and may be looking for an answer to fix it, he's run through hundreds to thousands of tasks that erred. He may not even be eligible to get work for days.
And even then, there are some out there that don't ask for help. They'll just uninstall BOINC and leave a bad review, because it didn't work out of the box.

If the project has the chance to take away the first problem from happening, why should we wait for tasks to err, the user to react and reach out and someone with the right knowledge to answer on how to add an optional line to a file that doesn't at standard come with BOINC?

how many projects are even affected by this? you may be pushing a change that affects 1 or no projects at all. i looked at all the GPU projects I'm aware of and they all have 64-bit nvidia apps. and no new/future projects will make a 32-bit only nvidia app. this really seems like a solution looking for a problem.

this is a edge case. even if there's one niche project out there that would be effected, makes more sense to just push that project to make a 64-bit app. and based on the comments from the devs in the github issue, it seems they tend to agree with that. BOINC will figure out which app works and which one doesnt when there are both apps available. projects can and will use different plan classes. projects can and should make 64-bit apps available, etc

---

In reply to Ian&Steve C.'s message of 3 Mar 2025:

you may be pushing a change that affects 1 or no projects at all

It's a plan class designation that they add to the scheduler. There's no code change, no new client, nothing. Just for the project to add a 64-bit application and a plan class designation that states to send tasks for this science application only to those GPUs that state they are 64-bit only (or some such).

Just as all the other plan classes that projects already wield to send tasks to Windows, Linux, Mac and Android computers, with or without specified GPUs.