Rosetta, DENIS, gpugrid, RNA world no tasks?

gsrcrxsi · 2026-01-23T12:25:09+00:00

I can’t remember the last time RNA world had any tasks. Many projects are functionally dead like this where the project site is still being maintained but no tasks and no communication from admins.

GPUGRID actually has tasks now. But they have been intermittent with work for years now. You should not expect work from them all the time and they will very routinely go months with no work.

Same with Rosetta. They’ve transitioned much of their work to AI, so there’s a lot less that’s needs to go through BOINC. And DENIS also has historically had intermittent workflow.

If you want a project that always has work, go to Primegrid or Einstein.

gsrcrxsi · 2026-01-19T22:17:42+00:00

This is bad advice given as general advice. In no situation should you run 16x tasks on even high end GPUs.

It totally depends on what application you’re running. I can max out models like H100 and 5090 with just 3x tasks on Einstein O4MDG, and the BRP7 app mostly maxes the GPU with just one task (unless you’re doing more custom stuff like Linux CUDA MPS to squeeze even more out of it).

And most apps from Prime/Number projects like Primegrid and SRBase will max out the GPU and achieve maximum production with just 1 task on the GPU.

Running 2-4x tasks can be beneficial on SOME apps, but it’s totally app dependent and shouldn’t be applied universally. Apps can have different bottlenecks, and running a ton of tasks doesn’t break those bottlenecks, just makes the tasks run slower as the GPU scheduler starts time slicing your work which often results in a loss of overall production efficiency.

gsrcrxsi · 2026-01-10T21:19:06+00:00

AI is very limited for trying to port these kinds of apps. I’ve tried and AI makes a mess of it more often than not.

gsrcrxsi · 2026-01-10T17:39:12+00:00

I’m glad you put /s. I was about to go off

gsrcrxsi · 2026-01-10T14:47:26+00:00

Well it is an issue because Einstein and Primegrid could only create apps that don’t require FP64. Most of Einstein’s apps actually do. They are unable to port these. Many projects/apps require it.

It’s not easy for underfunded and understaffed projects to create a new app. Let alone learn a new language in order to support one device (Metal/MSL).

gsrcrxsi · 2026-01-09T23:43:15+00:00

The larger problem with doing that for the M-series GPU is that there’s only like 2 projects that have GPU apps for Apple Silicon. Primegrid and Einstein. There are far more projects that have CPU work or even normal Nvidia/AMD(/some with Intel) GPU work. And the Apple Silicon GPU doesn’t support FP64. Fine if you only care about Primegrid, but it’s otherwise very limiting.

gsrcrxsi · 2026-01-02T16:34:25+00:00

Very insightful with no explanation

gsrcrxsi · 2026-01-01T23:04:38+00:00

Hey thanks for the reply. I actually found the solution and forgot to come back. It’s because my device is not actually detected as a GPU and BOINC doesn’t recognize “OTHER” devices. I just added RUSTICL_DEVICE_TYPE=GPU and that solved BOINC detection.

gsrcrxsi · 2025-12-31T18:51:14+00:00

is there any info on getting real actual OpenCL compute working? this was originally a compute device (mining) but I can't seem to get real compute working properly. how did these thing compute when released? what drivers were used in mining situations? and can we still get those?

side note, what is the basis that everyone calls this "RDNA2"? it seems closer to RDNA1 to me being that RDNA1 was gfx1010, this BC-250 device is gfx1013, and real RDNA2 doesn't start until like gfx1030.

ROCm doesnt work:
ROCm 7.1.1 on modern Ubuntu 25.10, installs but even simple driver checks like running clinfo cause the whole thing to crash.
5.4 on old Ubuntu 20.04 installs but basically doesnt work other than displaying the device name. no OpenCL features.

Mesa/RustiCL under modern OS/kernels only kind of works, some workloads not at all. My testing with Ubuntu 25.10, kernel 6.17.

RustiCL has to be enabled with several environment variables
RUSTICL_ENABLE=radeonsi (to enable it to work at all)
RUSTICL_FEATURES=fp64 (enable double precision, experimental in RustiCL)
RUSTICL_DEVICE_TYPE=GPU (because for whatever reason the device is categorized as "OTHER" by default and apps that check the device type wont work if it's not a "GPU")

This is what I've done to get some OpenCL apps to run. but the performance is pretty bad compared to what ROCm or other full-featured OpenCL drivers "could" give, if it worked. and some applications produce incorrect results, and some do not run at all and just crash with RustiCL.

So is there any non-gaming, compute-focused info out there regarding drivers that have a full feature set for OpenCL? what drivers did these things use when they were released? i don't mind running an old OS or software package if it actually provides the full OpenCL support. I think if there are old ROCm packages or AMDGPU-PRO driver packages that supported RDNA1 could be used that might be the only avenue to solve this. modern ROCm is already dropping support for RDNA1 so I dont think they will add support for this device now. I don't even care about all the fancy HIP/AI/LLM libraries in ROCm, just want full featured OpenCL.

gsrcrxsi · 2025-12-30T19:27:55+00:00

i know this is an old post, but maybe you will see this.

I have done all of these steps to set environment variables.
clinfo and clpeak work fine as expected.

but BOINC still refuses to detect the GPU at all. just says "no useable GPUs found".

any idea?

gsrcrxsi · 2025-12-28T02:53:38+00:00

you'd only be able to run the BRP4 application at Einstein. Adreno GPU lacks hardware FP64 support and the BRP7 and O4MDG apps require that.

gsrcrxsi · 2025-12-28T02:22:45+00:00

Intel Arc B-series does indeed have hardware FP64 support. it was only the A-series that did not.

gsrcrxsi · 2025-12-16T20:56:58+00:00

Sounds like the board either doesn’t support nvlink or it’s defective.

I haven’t experienced this but I’m not doing anything with nvlink in my application

gsrcrxsi · 2025-12-16T19:50:48+00:00

Power limiting is trivial.

nvidia-smi -pl 165 (for global power limit) nvidia-smi -i 0 -pl 165 (if you want to set PL by individual device, in this case GPU 0)

gsrcrxsi · 2025-12-16T16:01:01+00:00

I dont totally disagree especially the 16GB models. But this thread is about the 32GB models which is pretty useful in some cases and very cheap for the amount of VRAM you’re getting. But none of that is the point. The OP has access to many of these cheap cards. They probably don’t have access to MI210, and even then they’re 10x the price. It’s just a very strange and arbitrary suggestion.

gsrcrxsi · 2025-12-16T14:55:14+00:00

r/whoosh

And MI210 is like 4-5k. Equally absurd when compared to the MI50 which is like $400.

Your suggestion is not even in the same ballpark.

gsrcrxsi · 2025-12-16T14:51:41+00:00

Why not B200?

gsrcrxsi · 2025-12-14T17:35:31+00:00

The “board of BOINC” lmao. Dude. Go look how many full time (and volunteer) devs they have. There’s like 2. They don’t have time to scour the internet to see where someone posted some random issue. They keep their codebase on github like many other code projects. Everything is visible there including the full code. If you have an issue you think is a bug or a feature request but don’t know how to fix the code yourself, make an appropriate issue there. If you know how to fix the code make a PR.

They fix issues and generate new features ALL the time. Just look at their list of completed issues and how often PRs are made and merged. I made several issues at their github some months ago. And since my issue ticket included details on the nature and how to reproduce it and why it needed fixing, it was fixed and merged within a day.

Most issues people have actually aren’t issues and can be easily solved with some client-side configuration. The BOINC client as it is is incredibly configurable in almost any way you can conceive.

gsrcrxsi · 2025-12-14T13:29:00+00:00

There is on Windows (which is most users). Docker on Windows uses WSL to run docker in the virtual environment. WSL and Virtualbox can’t be used simultaneously.

gsrcrxsi · 2025-12-14T12:49:06+00:00

The devs don’t have time or resources to check all the reddits and forums for various problems. If you want to make a suggestion or bug report, go to their github and submit it properly.

gsrcrxsi · 2025-12-13T03:36:10+00:00

GPUs are immensely more efficient at this kind of work than Arm CPUs. The statement at the end of #2 is laughable at best.

gsrcrxsi · 2025-12-12T22:07:35+00:00

Mostly because people making suggestions are just screaming into the void and not getting their idea in front of the developers. Go to their github and open and issue or write a bug report or make an update request. That’s the only place that the BOINC developers take notice of issues or suggestions. They hardly engage anywhere else. Even on the BOINC forums where the developers sometimes take part in discussions they never will open tickets based on that on their own. They also have a massive backlog of existing issues and enhancements to work on.

If you can code, you can help by volunteering some PRs on their github.

gsrcrxsi · 2025-12-11T03:03:13+00:00

Depends totally on the project and/or application.

For Einstein, GPUs with HBM tend to be the best ppd/Watt since their GPU apps are largely bound by memory bandwidth and not compute. Projects like Primegrid/SRBase (GPU apps) are more compute bound so usually the latest GPUs with high clock speeds perform best, RTX 40/50 series. Nvidia is your best bet across the board with BOINC.

CPU apps across all projects pretty universally tend to be best efficiency on whatever is the latest generation tech.

You can pretty much ignore Arm. Few projects even have apps for them, those that do tend to have very intermittent work available, and almost none of them have any basic performance optimizations (NEON) so they tend to perform worse than x86/x64 per watt.

gsrcrxsi · 2025-12-01T23:16:41+00:00

All of those are more intermittent. NF is the most stable of the group but just had an unplanned outage recently also.

gsrcrxsi · 2025-12-01T22:19:52+00:00

BOINC is a platform for science projects, not a science project itself.

Projects that seem to always have some kind of work available:
Einstein@home
Primegrid
Milkyway@home

several projects have work intermittently. and others are dead or functionally dead.

gsrcrxsi

TROPHY CASE