LHC@Home, GPU, and BOINC ProjectList

Message boards : Questions and problems : LHC@Home, GPU, and BOINC ProjectList
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile jay_e

Send message
Joined: 8 Mar 07
Posts: 112
United States
Message 93169 - Posted: 12 Oct 2019, 1:39:22 UTC

Hello.
https://boinc.berkeley.edu/projects.php shows that LHC@ home uses AMD GPU.
I can not any sub-project there that uses GPUs.
Anyone know if there really is one?
Their FAQ says no GPU of any type. (last updated in 2015)
If this is true. Can the BOINC project page be updated to remove the GPU symbol?
Thanks,
Jay
ID: 93169 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4763
United Kingdom
Message 93170 - Posted: 12 Oct 2019, 8:42:11 UTC - in response to Message 93169.  
Last modified: 12 Oct 2019, 8:49:03 UTC

Unfortunately, the project page is generated automatically from the plan class names of the project's applications.

LHC have a couple of applications they have named native_mt and native_theory.

The word native contains the letters ATI, and that's what triggers the false positive GPU report.

The same thing happens in the 'Attach to project' wizard in BOINC Manager, because that's driven from the same automatic list.
ID: 93170 · Report as offensive
floyd
Help desk expert

Send message
Joined: 23 Apr 12
Posts: 77
Message 93182 - Posted: 13 Oct 2019, 8:09:49 UTC - in response to Message 93170.  

The word native contains the letters ATI, and that's what triggers the false positive GPU report.
Assuming that most search patterns are letters only, would it be reasonable to require matches to be surrounded by non-letter characters?
ID: 93182 · Report as offensive
robsmith
Volunteer tester
Help desk expert

Send message
Joined: 25 May 09
Posts: 1058
United Kingdom
Message 93183 - Posted: 13 Oct 2019, 8:31:42 UTC

It's a very simple search routine. I dare say there are other cases where projects are using what they consider to be "innocent" application names that trip the "ooo, there's a ?????? application" by the BOINC processor type routine. Most of the time it is just a simple annoyance, but there are times when it gets a bit beyond that. Just be thankful the project "knows the truth" and doesn't send work out for a non-existent application.
ID: 93183 · Report as offensive
Profile jay_e

Send message
Joined: 8 Mar 07
Posts: 112
United States
Message 93186 - Posted: 13 Oct 2019, 15:45:09 UTC - in response to Message 93170.  
Last modified: 13 Oct 2019, 15:47:18 UTC

Thank you all for your time and effort in answering.
That clears things up.

Perhaps an exception script could be developed that looks for words like 'native' that have triggered a response.
Maybe? Or something like Floyd's idea?

Thanks again,
Jay
ID: 93186 · Report as offensive
Peter Hucker of the Scottish B...
Avatar

Send message
Joined: 6 Oct 06
Posts: 1351
United Kingdom
Message 93248 - Posted: 20 Oct 2019, 19:16:18 UTC
Last modified: 20 Oct 2019, 19:20:07 UTC

In addition to this, when I go to LHC's own project preferences, I can tick ATI. Isn't this page made manually by LHC staff?:
https://lhcathome.cern.ch/lhcathome/prefs.php?subset=project

Besides, "native" triggering "ati"?! REALLY bad programming! I can think of many many words containing the letters ati. Imagine if Google worked like this....
Search: "car"
Did you mean "incarnation?"
ID: 93248 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 4763
United Kingdom
Message 93251 - Posted: 21 Oct 2019, 12:20:00 UTC - in response to Message 93248.  

I think all the ATI detections are made automatically, including the project preferences. In which case, it's probably best that they're consistent, driven off the same data via the same rules.

I did go into this in some detail when I was writing #2643, in an attempt to synchronise the web page here with the 'attach to project' wizard displayed in the client - they were badly out of sync. It's better now, but I've discovered that the automatic updating process has broken down: Universe@Home has added an Android application which doesn't show in BOINC Manager, for example.

I agree the outcome has become bad programming, but in defence of the BOINC programmers, they're working at the cutting edge of computer science development. When BOINC coding started, we worked on CPUs only, on the main desktop operating systems and a few legacy OSs. Since then, we've added CUDA, ATI, OpenCL, intel_gpu, Android and probably more, and the original OSs have undergone huge changes. In general, BOINC works surprisingly well, under the circumstances.

Going back to the specific ATI question: the decision on what devices to support is taken individually by each separate project. The rules for supported devices are specified in Plan class names:

Plan class names encode information as follows:

  • The name includes "opencl" if and only if the app requires OpenCL libraries.
  • The name includes "cuda" if and only if the app requires CUDA libraries.
  • The name includes "ati" if and only if the app requires CAL libraries.
  • The name includes "ati" or "amd" if and only if the app uses an ATI/AMD GPU.
  • The name includes "cuda" or "nvidia" if and only if the app uses an NVIDIA GPU
  • The name includes "intel_gpu" if and only if the app uses an Intel GPU.
  • The name includes "vbox" if and only if the app is a VM app and requires VirtualBox.
  • The name includes "wsl" if and only if the app uses Windows Subsystem for Linux.

CERN's use of 'native' breaks the "and only if" component of those rules. I pointed this out to CERN while I was working on the wizard, but it's up to them to fix it.

If you can think of a better rule which would correctly discriminate all of these, please let me know and I'll forward it.

ati_opencl
ati14
ati14_app13
BRP4G-Beta-opencl-ati
BRP4G-Beta-opencl-ati-Lion
BRP4G-opencl-ati
BRP4G-opencl-ati-lion
FGRPopencl1K-ati
FGRPopencl-ati
FGRPopencl-ati-mav
GW-opencl-ati
native_mt
native_theory
opencl_ati
opencl_ati_100
opencl_ati_101
opencl_ati_AP27
opencl_ati_cat132
opencl_ati_gpu
opencl_ati_mac
opencl_ati_nocal
opencl_ati_sah
opencl_ati5_cat132
opencl_ati5_mac
opencl_ati5_nocal
opencl_ati5_sah
opencl_ati5_SoG
opencl_ati5_SoG_cat132
opencl_ati5_SoG_mac
opencl_ati5_SoG_nocal
opencl_atiapu_sah
openclatiGFN15
openclatiGFN16
openclatiGFN17LOW
openclatiGFN17MEGA
openclatiGFN18
openclatiGFN19
openclatiGFN20
openclatiGFN21
openclatiGFN22
openclatiGFNEXTREME
openclatiPPSsieve
ID: 93251 · Report as offensive
Peter Hucker of the Scottish B...
Avatar

Send message
Joined: 6 Oct 06
Posts: 1351
United Kingdom
Message 93255 - Posted: 21 Oct 2019, 19:42:25 UTC - in response to Message 93251.  

I guess the problem is that "ati" is too short to be used for this detection. "Opencl" for example would never appear by mistake in a word. Nothing that can be done now - you'd have to detect ati followed by or after a hyphen or an underline, and several other things, then new stuff would need those rules changed. I think the only answer is to explain the problem to CERN, it would be easier for them to just change those names to something else? I attached LHC to my computer thinking I could run it on my ATI, but I can't, so it's wasted my time and theirs.
ID: 93255 · Report as offensive

Message boards : Questions and problems : LHC@Home, GPU, and BOINC ProjectList

Copyright © 2022 University of California. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.