Using Android GPU is on the BOINC client roadmap at the main BOINC website. Not available yet.

---

New volunteers comming, don't see covid-WUs and disappear, because its not related to their interests.
Did we win? No.

Seems not

We're so grateful for our volunteer community:
• active users DOUBLED since late Feb
• 4 of our 10 best compute days EVER occurred in the last — (wait for it) — 4 days

---

We're so grateful for our volunteer community:
• active users DOUBLED since late Feb
• 4 of our 10 best compute days EVER occurred in the last — (wait for it) — 4 days

And continuing to grow. They are now up to 400,000 GigaFLOPS.
They must have had plenty of reserve server capacity.

---

Thank you very much for this detailed descriptions!

---

Using Android GPU is on the BOINC client roadmap at the main BOINC website. Not available yet.

I just wanted to add a comment here about GPU. We'd love to use GPUs and we're well aware of how powerful they are, but making Rosetta work on GPUs isn't as easy as just updating the website and the BOINC infrastructure.

Running on GPUs requires code that at the very CPU instruction level is doing the same thing millions of times. Like rendering every pixel on a screen or calculating the hash of a cryptocurrency function millions of times.

The problem with the Rosetta code base (which I should remind is 3M lines of C++ code), is that it was written well before the thought of ever using GPUs. Rosetta is this beautiful objected-oriented programming playground where everything is just a pointer away with elegant recursive functions to make everything work and a super-fast monte-carlo simulated annealer to pick new amino acids. The problem is that everything I just described is inherently single-CPU, and trying to change this would involve rewriting the core of Rosetta.

Now, with that in mind, some of the big names in Rosetta code development started a project 2 years ago to get Rosetta to run on GPUs. As I said, this is a full rewrite from the ground up. They've made great progress and have gotten the score function and minimizer to work. But I think the packer gave them a bit of trouble. As I said, the packer is a long series of trial and error that simply doesn't parallelize well. I think they eventually settled on trying to design like 100 proteins at once rather than making it truly parallelizable.

But yes, we want GPUs just as bad as you do. And while we are making progress with the GPU Rosetta, they've only recreated about 1% of the whole infrastructure so far.

But yes, we want GPUs just as bad as you do. And while we are making progress with the GPU Rosetta, they've only recreated about 1% of the whole infrastructure so far.

VERY interesting!!
Thanks for your effort!

---

.
But yes, we want GPUs just as bad as you do. And while we are making progress with the GPU Rosetta, they've only recreated about 1% of the whole infrastructure so far.

I do OpenCL coding for a living and I'm between jobs.

Any 2-3 weeks tasks?

To try and maximize my contribution to fighting SARS-CoV-2, I've adopted the approach of running R@h for CPU work, and running Folding@home for my GPUs

Much thanks to the R@h team!

To try and maximize my contribution to fighting SARS-CoV-2, I've adopted the approach of running R@h for CPU work, and running Folding@home for my GPUs

Much thanks to the R@h team!

I am doing the same. Here in the morning I could get 2 work units for F@H (Nothing afterward the people in the US wake up) and it uses only 10 percent of my CPU, the other approx 85% goes to Rosetta, when the F@H units finish, usually early in the afternoon here, that 10 also goes to Rosetta.

I am considering the options to use my old config as a rosetta dedicated machine in the future, however I do not have a PSU so this has to wait till the pandemic is over...

.
I do OpenCL coding for a living and I'm between jobs.

Any 2-3 weeks tasks?

Unfortunately I don't think so. This is very much a long slough by the same people that wrote Rosetta the first two times. Much of the challenge here is trying to figure out how to redo the core algorithms but in parallel fashion (with performance being #1).

There might be GPU Rosetta jobs running someday, but they'll likely be doing very different tasks from what you see here. One of the goals of getting the GPUs going was for fast data-transfer to machine learning algorithms. So with that in mind, you might see some sort of deep-learning Rosetta thing in a few years.

The other issue with the GPU version is that like I said, there's a whole stack of science built on-top of the core code that would take thousands of hours to reproduce. The GPU version is very much a fork with different goals.

Unfortunately I don't think so. This is very much a long slough by the same people that wrote Rosetta the first two times. Much of the challenge here is trying to figure out how to redo the core algorithms but in parallel fashion (with performance being #1).

Pity, it sounded like a fun project. But i understand the answer after reading a bit on rosetta commons.

I wondered about the internal structure and found the page https://www.rosettacommons.org/docs/latest/rosetta_basics/structural_concepts/Rosetta-overview . The concept of interchangeable scoring functions and, i assume, interchangeable minimization procedures is a tough call for porting to the GPU. An efficient GPU implementation needs all those parts (Pose, MoveMap, Packer, scoring and the min-procedure) on the GPU, with a data structure adopted to GPU systems. Doing that is easy if all components are known, well maintained and no 3. party can add stuff. I can guess where the code comes from based on the papers and having worked with science people written high-performance code, that will not be fun.

That GPU-port will need to cut corners in some places. They can probably not get it all running in one go. As an advise from an internet stranger: pick the most commonly us

Run the project or don't.

I can only agree. They have bigger fish to fry than satisfying our curiosity at the moment.
We can quibble about it later.

They don't have bigger fish to fry.

New volunteers comming, don't see covid-WUs and disappear, because its not related to their interests.

Did we win? No.
So we, as old participants, and the rosetta-team should satisfy the curiosity.
Even if it's just to get the job done.

As a newcomer to BOINC with 2 laptops and 3 android devices running tasks - I appreciate that COVID-19 projects from the lab are labeled, and do wish all related to it were labeled as such, so I can prioritize those WUs manually, over others from Rosetta or other BOINC projects. I'm not upset about it - Rosetta has me running 4 COVID WU across my devices, and a bunch more in the queue. Thanks for standing up for us newbies - we're not all attention-seeking jerks ;)

Pity, it sounded like a fun project. But i understand the answer after reading a bit on rosetta commons.

There is another project that "folds proteins" and use GPU: https://www.gpugrid.net/
But they use CUDA, not OpenCL despite some attempts over the years to support OpenCL.
If you are interested, try to contacting them.
Thanks in advance.

But yes, we want GPUs just as bad as you do. And while we are making progress with the GPU Rosetta, they've only recreated about 1% of the whole infrastructure so far.

That is not true, people have managed to crunch e.g. MilkyWay@Home using their Android GPU by means of the alternate platform. The Boinc Client can handle Mali GPUs at the very least:

Tue May 15 15:19:00 GMT+03:00 2018||OS: Android: 3.18.35
Tue May 15 15:19:00 GMT+03:00 2018||Processor features: fp asimd evtstrm aes pmull sha1 sha2 crc32
Tue May 15 15:19:00 GMT+03:00 2018||Using 4 CPUs
Tue May 15 15:19:00 GMT+03:00 2018||Processor: 8 AArch64 Processor rev 2 (aarch64)
Tue May 15 15:19:00 GMT+03:00 2018||Host name: android_4cc605bf
Tue May 15 15:19:00 GMT+03:00 2018||OpenCL: Mali-T860 0: Mali-T860 (driver version 1.2, device version OpenCL 1.2 v1.r12p0-04rel0.44f2946824bb8739781564bffe2110c9, 3804MB, 3804MB available, 0 GFLOPS peak)
Tue May 15 15:19:00 GMT+03:00 2018||Data directory: /data/data/edu.berkeley.boinc/client
Tue May 15 15:19:00 GMT+03:00 2018||Running as a daemon
Tue May 15 15:19:00 GMT+03:00 2018||Libraries: libcurl/7.48.0 OpenSSL/1.0.2g zlib/1.2.8
Tue May 15 15:19:00 GMT+03:00 2018||log flags: file_xfer, sched_ops, task
Tue May 15 15:19:00 GMT+03:00 2018||Starting BOINC client version 7.4.53 for aarch64-android-linux-gnu

---

Dirk, the post you quoted is referring to the Rosetta infrastructure, not the BOINC infrastructure. So, what other projects are doing is not directly related to what was being said.

---

Rosetta Moderator: Mod.Sense

As an advise from an internet stranger: pick the most commonly us

I cannot understand clearly this...

---

To try and maximize my contribution to fighting SARS-CoV-2, I've adopted the approach of running R@h for CPU work, and running Folding@home for my GPUs

Much thanks to the R@h team!

This is the best approach in my opinion. GPU for Folding, CPU for Rosetta.

For me it makes little sense to do CPU for Folding since they can already do the same work with GPU which are way faster for that kind of work.

---

As an advise from an internet stranger: pick the most commonly us

I cannot understand clearly this...

I typed a lengthy post, hit "submit" and got an server error. I checked if the post made it, saw nothing. So i repeated like 10x. Still got errors, lost interest, aborted. You see the end result: 5 partial posts (if an admin could please trim the mess down to one post .... ?)

The short version of the end:

pick the most commonly used class combinations and build a monolithic GPU implementation (like the one used for most rosetta-boinc WUs). Do not care too much about making modules, but do care a lot about data layout on the GPU. Modules and stuff comes later, but getting to a data layout that is actually efficient (low number of copies between GPU and host) is hard. Making the data layout modular in the first go will bite you hard later.

I also wrote something about not aiming for MPI and multiple GPUs in the first go. I have seen a few do-it-all port attempts that failed hard because taking into consideration a rare corner case made the data layout on the GPU really, really awful. KISS (keep it simple and stupid) is king in GPU land. Adding multiple GPU / nodes later and using them in a task parallel way is very often easier and more efficient (coding-time and runtime).

BTW and very off-topic.: i saw your post about tn-grid and GPU. Thanks for the tip, that one looks doable in 2 weeks. I contacted valterc (picked the last admin posting anything GPU related), hoping to get a bit of feedback from the attempt made by Daniel.

The self-serving arrogance of this.

It's NOT "run the project or don't!"
You are not "rosetta"
We are all rosetta.

Lol - I can see the gallery's applause from here.

Can I suggest something. Can you increase your runtimes back to the default 8hrs rather than the 4hrs <you've edited> it to on your PCs?

Because the project, which is benefitting from a fantastic surge of new users atm, has <run out> of tasks right now and if you hadn't run your tasks for <half> the time you wouldn't have grabbed <double> the number of tasks for yourself to the exclusion of <other people> and they'd be able to run <more> tasks for the project and for <longer> and maybe we wouldn't have run out quite so <early>

But look how many tasks <you've> got.

You are not "rosetta"
We are all rosetta.

And again, lol. Spare me

---

BTW and very off-topic.: i saw your post about tn-grid and GPU. Thanks for the tip, that one looks doable in 2 weeks. I contacted valterc (picked the last admin posting anything GPU related), hoping to get a bit of feedback from the attempt made by Daniel.

Great!!

P.S. If you have a problem to contact Valterc, send me a PM. I know him personally.

---