OpenCl 3.0 has landed

Intel released Compute Code with support to OpenCl 3.0 and oneAPI Level Zero stack update with an updated IGC compiler and L0 loader.

AMD and Xilinx demonstrate converged ROCm runtime technology preview

AMD released Rocm 3.10 with a lot of new features.
Intel relased version 1.0 of OneApi

PoCl 1.6 is here

Kronos Group publishes OpenCl 3.0.6 maintenance release and the first revision of C++ for OpenCl
Amd relases new versione of HIP programming guide

Rocm 4.0 ready....

Kronos Group releases SYCL 2020 final specification

Interesting project: JuliaGpu

HipSycl 0.9.0 has a lot of new features.
And HipSycl 0.9.1 will have more!

You might post more information on how to learn some of the GPU computer languages compatible with BOINC.

I've already had online classes in C++ and CUDA, so I'm most interested in online classes for OpenCL.

I'm not to the point where I can check if the various other GPU computer languages you post about are compatible with BOINC.

You might post more information on how to learn some of the GPU computer languages compatible with BOINC.

Boinc platform is "language-agnostic". Boinc platform simply "expose" the hw (and its features) to the app.
During these years i saw apps in C++, Fortran, Java, etc on Boinc.
Now, for example, MLC@Home is running a Rocm app on AMD gpu (cause Pytorch does not support OpenCl officially)
You may write an F# app to target gpu and it runs on Boinc

I'm not to the point where I can check if the various other GPU computer languages you post about are compatible with BOINC.

As i said it's not a problem of language, it a "problem" of app (if it may be parallelized, if it will be correctly compiled for gpu, etc).
And, if you are scared about gpu, you can use the boinc wrapper.
Xansons4Code did it: started gpu use with wrapper and, after, they created a gpu native app

HipSycl 0.9.0 has a lot of new features.
And HipSycl 0.9.1 will have more!

First test to hypsycl on intel gpu.

hipSYCL can compile to a single binary that runs on CPUs/AMD/NVIDIA/Intel GPUs!!

Most of the alternate software packages mentioned here for GPU use under BOINC look usable if you want BOINC to start a task, and then have no control of that task until it finishes. But how many BOINC users want to allow that?

I've looked into getting the source code for the Ralph@Home and Rosetta@Home applications. It is allowed, but only for those who pay a fairly high price for it (several thousand dollars).

Do you feel it is reasonable to pay that much money to produce GPU versions that, so far, seem likely to run at roughly the same speed as the CPU versions?

Most of the alternate software packages mentioned here for GPU use under BOINC look usable if you want BOINC to start a task, and then have no control of that task until it finishes. But how many BOINC users want to allow that?

?
These "alternative softwares" are only compilers/library/tools that permit to compile sw to runs on gpu.
A lot of boinc projects run code on gpu automatically: gpugrid (CUDA), Einstein/Milkyway (OpenCl), MLC (Rocm)

I've looked into getting the source code for the Ralph@Home and Rosetta@Home applications. It is allowed, but only for those who pay a fairly high price for it (several thousand dollars).

We know it's closed. And we know it's not optimized (rsj5 and a recent publication from admins admit it), not even for cpu.

Do you feel it is reasonable to pay that much money to produce GPU versions that, so far, seem likely to run at roughly the same speed as the CPU versions?

We don't know how gpu version could be faster than cpu version, cause we don't have gpu version.
Maybe 10%, maybe 70%, maybe 350%. We don't know.
The solution, maybe, will be to fork the code and run only one specific kind of simulation on gpu.

Most of the alternate software packages mentioned here for GPU use under BOINC look usable if you want BOINC to start a task, and then have no control of that task until it finishes. But how many BOINC users want to allow that?

?
These "alternative softwares" are only compilers/library/tools that permit to compile sw to runs on gpu.
A lot of boinc projects run code on gpu automatically: gpugrid (CUDA), Einstein/Milkyway (OpenCl), MLC (Rocm)

I've run GPUGRID, Einstein, and Milkyway applications before. I haven't looked at MLC.

Years ago, a major section was added to BOINC to allow running CUDA applications. Another major section was then added to allow running OpenCL applications. I'd expect this to be required for adding capability to run applications using any other GPU computer language, although it is possible that other GPU computer compilers could translate their requirements into using either the CUDA section or the OpenCL section instead, or have a library that can do these translations.

Some of the things that must be handled :

1. Which GPU to use, if the computer has more than one.
2. Any pauses or slowdowns needed to allow the user to do something else on the computer before the application finishes,
3. A way to abort the application if the current task appears to be trying to run forever.
4. Reporting the application's progress to BOINC.

[snip]

Do you feel it is reasonable to pay that much money to produce GPU versions that, so far, seem likely to run at roughly the same speed as the CPU versions?

We don't know how gpu version could be faster than cpu version, cause we don't have gpu version.
Maybe 10%, maybe 70%, maybe 350%. We don't know.

Since the clocks for GPUs on graphics boards are typically about a quarter of the speeds of CPU clocks, the GPU version could be as slow as a quarter of the speed of the CPU version if it had no two operations that could run simultaneously. But in that case, no BOINC project would be likely to offer that GPU version.

However if the maximum possible number of operations that could run simultaneously on that graphics board were compatible with the program, the GPU version could run as fast as a fourth of the CPU application multiplied by the number of GPU cores in the GPU. For some of the latest graphics boards, that could be a thousand times as fast as the CPU version.

Ten times as fast as the CPU version is more typical for GPU versions released by BOINC projects, though.

Intel GPUs are occasionally able to run faster than graphics board versions, since Intel GPUs is inside the CPU package and can therefore have very high bandwidth paths to the CPU. Graphics board GPUs have slower paths through the PCIe slots and can only transfer fewer bits at a time.

The solution, maybe, will be to fork the code and run only one specific kind of simulation on gpu.

I've read that the Ralph@Home and Rosetta@Home applications have large collections of different software paths, many of which are not used in most tasks.

However, it should be possible to identify paths that are used the most and have the most possible speedup, and produce a forked version that uses only those paths, with GPU use where it is reasonable.

I've also read that the Rosetta developers do not want to deal with interpreting dumps from more versions of their applications, so I'd expect them not to want to do this.

Also, this would require the developers to produce a way to sort all of the tasks into those that can run on the GPU version and those that cannot.

Years ago, a major section was added to BOINC to allow running CUDA applications. Another major section was then added to allow running OpenCL applications. I'd expect this to be required for adding capability to run applications using any other GPU computer language, although it is possible that other GPU computer compilers could translate their requirements into using either the CUDA section or the OpenCL section instead, or have a library that can do these translations.
Some of the things that must be handled :

1. Which GPU to use, if the computer has more than one.
2. Any pauses or slowdowns needed to allow the user to do something else on the computer before the application finishes,
3. A way to abort the application if the current task appears to be trying to run forever.
4. Reporting the application's progress to BOINC.
.......
Since the clocks for GPUs on graphics boards are typically about a quarter of the speeds of CPU clocks, the GPU version could be as slow as a quarter of the speed of the CPU version if it had no two operations that could run simultaneously. But in that case, no BOINC project would be likely to offer that GPU version.
However if the maximum possible number of operations that could run simultaneously on that graphics board were compatible with the program, the GPU version could run as fast as a fourth of the CPU application multiplied by the number of GPU cores in the GPU. For some of the latest graphics boards, that could be a thousand times as fast as the CPU version.

Ten times as fast as the CPU version is more typical for GPU versions released by BOINC projects, though.

We know there is a LOT of problems to "adapt" cpu app to gpu.
But, for example, they use gpu to "train" AI on Rosetta, so i think it's not impossible to produce gpu app for this project

I've read that the Ralph@Home and Rosetta@Home applications have large collections of different software paths, many of which are not used in most tasks.
However, it should be possible to identify paths that are used the most and have the most possible speedup, and produce a forked version that uses only those paths, with GPU use where it is reasonable.
I've also read that the Rosetta developers do not want to deal with interpreting dumps from more versions of their applications, so I'd expect them not to want to do this.

As i understand a lot of time ago, the first problem is the will of developers.

Also, this would require the developers to produce a way to sort all of the tasks into those that can run on the GPU version and those that cannot.

Another problem.
But, as we said before, some projects run both cpu and gpu apps, so it's not impossible.


PS. I'm much more optimist about cpu optimizations...

I've also read that the Rosetta developers do not want to deal with interpreting dumps from more versions of their applications, so I'd expect them not to want to do this.

Now, for example, they are working on new app version, in Phyton.
And, with Python, there is a lot of gpu support (like PyOpenCl or PyCuda)

Sycl 2020 revision 3 released with its sources available in open-source

duplicate