Ralph support OpenCL ?

Message boards : Number crunching : Ralph support OpenCL ?

To post messages, you must log in.

Previous · 1 · 2 · 3 · 4 · 5 · 6 · 7 · Next

AuthorMessage
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6900 - Posted: 1 Oct 2020, 13:46:32 UTC

OpenCl 3.0 has landed
ID: 6900 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6902 - Posted: 10 Oct 2020, 7:53:20 UTC

Intel released Compute Code with support to OpenCl 3.0 and oneAPI Level Zero stack update with an updated IGC compiler and L0 loader.
ID: 6902 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6912 - Posted: 19 Nov 2020, 17:05:45 UTC

AMD and Xilinx demonstrate converged ROCm runtime technology preview
ID: 6912 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6914 - Posted: 8 Dec 2020, 17:12:50 UTC
Last modified: 8 Dec 2020, 17:43:40 UTC

AMD released Rocm 3.10 with a lot of new features.
Intel relased version 1.0 of OneApi
ID: 6914 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6933 - Posted: 18 Dec 2020, 7:18:23 UTC

PoCl 1.6 is here
ID: 6933 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6934 - Posted: 18 Dec 2020, 19:53:28 UTC
Last modified: 18 Dec 2020, 19:57:50 UTC

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
ID: 6934 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6937 - Posted: 20 Dec 2020, 8:37:17 UTC - in response to Message 6934.  
Last modified: 20 Dec 2020, 8:37:42 UTC

Rocm 4.0 ready....
ID: 6937 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6948 - Posted: 9 Feb 2021, 14:35:50 UTC

Kronos Group releases SYCL 2020 final specification
ID: 6948 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6955 - Posted: 18 Feb 2021, 17:23:10 UTC

Interesting project: JuliaGpu
ID: 6955 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6959 - Posted: 23 Feb 2021, 17:27:22 UTC

HipSycl 0.9.0 has a lot of new features.
And HipSycl 0.9.1 will have more!
ID: 6959 · Report as offensive    Reply Quote
Profile robertmiles

Send message
Joined: 13 Jan 09
Posts: 100
Credit: 331,865
RAC: 0
Message 6960 - Posted: 24 Feb 2021, 2:39:15 UTC

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.
ID: 6960 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6961 - Posted: 24 Feb 2021, 8:22:38 UTC - in response to Message 6960.  
Last modified: 24 Feb 2021, 9:18:06 UTC

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
ID: 6961 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6968 - Posted: 5 Mar 2021, 8:40:18 UTC - in response to Message 6959.  

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!!
ID: 6968 · Report as offensive    Reply Quote
Profile robertmiles

Send message
Joined: 13 Jan 09
Posts: 100
Credit: 331,865
RAC: 0
Message 6969 - Posted: 6 Mar 2021, 5:18:20 UTC

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?
ID: 6969 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6970 - Posted: 7 Mar 2021, 9:44:12 UTC - in response to Message 6969.  
Last modified: 7 Mar 2021, 9:44:36 UTC

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.
ID: 6970 · Report as offensive    Reply Quote
Profile robertmiles

Send message
Joined: 13 Jan 09
Posts: 100
Credit: 331,865
RAC: 0
Message 6971 - Posted: 8 Mar 2021, 2:54:29 UTC - in response to Message 6970.  

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.
ID: 6971 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6973 - Posted: 10 Mar 2021, 17:21:24 UTC - in response to Message 6971.  
Last modified: 10 Mar 2021, 17:31:16 UTC

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...
ID: 6973 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6974 - Posted: 10 Mar 2021, 22:05:49 UTC - in response to Message 6971.  

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)
ID: 6974 · Report as offensive    Reply Quote
Profile [VENETO] boboviz

Send message
Joined: 9 Apr 08
Posts: 840
Credit: 1,888,960
RAC: 0
Message 6975 - Posted: 10 Mar 2021, 22:19:09 UTC

Sycl 2020 revision 3 released with its sources available in open-source
ID: 6975 · Report as offensive    Reply Quote
Profile robertmiles

Send message
Joined: 13 Jan 09
Posts: 100
Credit: 331,865
RAC: 0
Message 6976 - Posted: 11 Mar 2021, 0:43:29 UTC - in response to Message 6973.  
Last modified: 11 Mar 2021, 0:46:37 UTC

duplicate
ID: 6976 · Report as offensive    Reply Quote
Previous · 1 · 2 · 3 · 4 · 5 · 6 · 7 · Next

Message boards : Number crunching : Ralph support OpenCL ?



©2024 University of Washington
http://www.bakerlab.org