Brief update:

Windows - AMD OpenCL app v102.17 seams to be the most stable of all the others. Keep sending your feedback. It may help us to polish issues (or at least some of them) within the next build. Yet, the app may not work on some GPUs. Keep on mind that OpenCL apps can be highly affected by the drivers in use and there is no universal cure (version, vendor, etc.).

Linux - AMD OpenCL app v102.17 is ready. Waiting for Kyong to release it. Here are some details for the system on which it was built:

Ubuntu 20.04.1 LTS   Release:  20.04
ldd (Ubuntu GLIBC 2.31-0ubuntu9) 2.31

I hope this will do, as I can't go lower with versions.
And again, keep sending your feedback please.
By the way it will be interesting to know if the app woks on Mesa platforms.

As to the other questions

Have you deliberately set it to use about half the GPU RAM?

No. The amount of allocated memory will be different for every GPU model.

Do you use something like this to run CUDA code on AMD GPUs?

No. The code was written from scratch.

Cheers!
Georgi

---

“The good thing about science is that it's true whether or not you believe in it.” ― Neil deGrasse Tyson

V17 is running perfectly on R9 Nano (OpenCL 2.0). Every task works and takes about 20 minutes.

However it fails to run on R9 280X (OpenCL 1.2).

And on the Nano it's much slower than my CPU, whereas on other projects the GPU is way faster. A lot of speed increase will be required to make it worth using GPUs here. My Ryzen 9 3900X can do 24 of them in 50 minutes, which is almost 10 times more throughput.

However it fails to run on R9 280X (OpenCL 1.2).

You may try again on this one as the final app v102.17 is a different build that the previous buggy (Version: 102.18.1.0) one.
You should be able to see

Version: 102.18.5.0

in Stderr output of the tasks.

Let me know how was it.

---

“The good thing about science is that it's true whether or not you believe in it.” ― Neil deGrasse Tyson

No, I see "Version: 102.18.1.0" (on the bad and good cards), even though Boinc lists it as 102.17, for example:

https://asteroidsathome.net/boinc/result.php?resultid=401167874

It also says:
"The system cannot find the file specified.
(0x2) - exit code 2 (0x2)</message>"

I see. The executable is definitely the wrong one. I'll talk to Kyong.

Will keep you posted.

---

“The good thing about science is that it's true whether or not you believe in it.” ― Neil deGrasse Tyson

From my stderr output (does that stand for standard error?!):

Multiprocessors: 64
Max Samplers: 16
Max work item dimensions: 3
Resident blocks per multiprocessor: 16
Grid dim: 2048 = 2 * 64 * 16
Block dim: 128

Looking up the specs for my card:

Shading Units 4096
TMUs 256
ROPs 64
Compute Units 64

I have no idea what a ROP or TMU is, but can I assume from "Multiprocessors: 64" in stderr you're using the 64 compute units? Folding@Home uses the shaders apparently. Not sure if that's possible, it may depend on what calculations you're doing, but I'm guessing 4096 shaders is faster than 64 compute units.

My BOINC-Client ist still using the old 102.15 App Version.
How can I force the client to load the new one?

My BOINC-Client ist still using the old 102.15 App Version.
How can I force the client to load the new one?

Abort the tasks you have and it will download the new one. The version is tied to the task.

Abort the tasks you have and it will download the new one. The version is tied to the task.

I had no old tasks, when I started Asteroids today.
The BOINC manager pult a fresh one but with the old App-Version. :(

Abort the tasks you have and it will download the new one. The version is tied to the task.

I had no old tasks, when I started Asteroids today.
The BOINC manager pult a fresh one but with the old App-Version. :(

You're using Linux, perhaps it's on a different version to Windows? They're having different problems with each OS!

Hi all,

I'm still getting jobs for 102.15, and errors as a result.

I believe the version has not been properly updated for Linux:

https://asteroidsathome.net/boinc/apps.php

sched_reply_asteroidsathome.net_boinc.xml still refers to version 10215. I tried to manually wget version 102.17 from https://asteroidsathome.net/boinc/downloads but the file couldn't be found.

Best regards,

Samuel

Be patient guys.
As you can see from here https://asteroidsathome.net/boinc/apps.php those apps are not released yet.
Kyong will not be available till later today.

---

“The good thing about science is that it's true whether or not you believe in it.” ― Neil deGrasse Tyson

Latest versions has been released.

---

“The good thing about science is that it's true whether or not you believe in it.” ― Neil deGrasse Tyson

Latest Version craches with integrated Vega11

<core_client_version>7.18.1</core_client_version>
<![CDATA[
<message>
process exited with code 1 (0x1, -255)</message>
<stderr_txt>
BOINC client version 7.18.1
BOINC GPU type 'ATI', deviceId=0, slot=13
Application: ../../projects/asteroidsathome.net_boinc/period_search_10217_x86_64-pc-linux-gnu__opencl_101_amd_linux
Version: 102.17.0.0
Platform name: Clover
Platform vendor: Mesa
OpenCL device C version: OpenCL C 1.1 | OpenCL 1.1 Mesa 23.1.7 - kisak-mesa PPA
OpenCL device Id: 0
OpenCL device name: AMD Radeon Vega 11 Graphics (raven, LLVM 15.0.7, DRM 3.49, 6.2.0-32-generic) 5GB
Device driver version: 23.1.7 - kisak-mesa PPA
Multiprocessors: 11
Max Samplers: 32
Max work item dimensions: 3
Resident blocks per multiprocessor: 32
Grid dim: 704 = 2 * 11 * 32
Block dim: 128
Binary build log for AMD Radeon Vega 11 Graphics (raven, LLVM 15.0.7, DRM 3.49, 6.2.0-32-generic):
OK (0)
Program build log for AMD Radeon Vega 11 Graphics (raven, LLVM 15.0.7, DRM 3.49, 6.2.0-32-generic):
OK (0)
Prefered kernel work group size multiple: 64
Setting Grid Dim to 256
amdgpu: The CS has been rejected (-125), but the context isn't robust.
amdgpu: The process will be terminated.

Latest Version craches with integrated Vega11

<core_client_version>7.18.1</core_client_version>
<![CDATA[
<message>
process exited with code 1 (0x1, -255)</message>
<stderr_txt>
BOINC client version 7.18.1
BOINC GPU type 'ATI', deviceId=0, slot=13
Application: ../../projects/asteroidsathome.net_boinc/period_search_10217_x86_64-pc-linux-gnu__opencl_101_amd_linux
Version: 102.17.0.0
Platform name: Clover
Platform vendor: Mesa
OpenCL device C version: OpenCL C 1.1 | OpenCL 1.1 Mesa 23.1.7 - kisak-mesa PPA
OpenCL device Id: 0
OpenCL device name: AMD Radeon Vega 11 Graphics (raven, LLVM 15.0.7, DRM 3.49, 6.2.0-32-generic) 5GB
Device driver version: 23.1.7 - kisak-mesa PPA
Multiprocessors: 11
Max Samplers: 32
Max work item dimensions: 3
Resident blocks per multiprocessor: 32
Grid dim: 704 = 2 * 11 * 32
Block dim: 128
Binary build log for AMD Radeon Vega 11 Graphics (raven, LLVM 15.0.7, DRM 3.49, 6.2.0-32-generic):
OK (0)
Program build log for AMD Radeon Vega 11 Graphics (raven, LLVM 15.0.7, DRM 3.49, 6.2.0-32-generic):
OK (0)
Prefered kernel work group size multiple: 64
Setting Grid Dim to 256
amdgpu: The CS has been rejected (-125), but the context isn't robust.
amdgpu: The process will be terminated.

i think your opencl version is too old, 1.1 is ancient. Mesa is generally not well suited for real compute loads. Many people have issues using Mesa with BOINC

try installing the real AMD drivers. you might have to back up to an older OS/kernel though. or try the ROCm drivers, but i think ROCm 5.6? was the last to support Vega

---

It's not exactly that.
The linux app is OpenCL 1.1 compliant (in respect to the Windows app, which is OpenCL 1.2). I've tested it on my Arch Linux system using clover-mesa drivers and it was working as a charm. Well, as you remember I was using latest libraries for everything, especially I had to built the clover-mesa from the latest source in their gitlab branch. The application does not use any Image nor Texture manipulation functions, wich are the Achilles heel in most of the cases with Clover.

But as I mentioned previously, integrated graphics needs special approach and will need additional research:

It still may have issues with integrated AMD Graphics though. Those CPU based Graphics needs different memory alignment. Unfortunately there is now way for us to distinct them at project level from discrete GPUs.
So, those of you who have such systems may want to restrict their use for now using cc_congif.xml and

<exclude_gpu>

tag (Client configuration).
At least until we handle their specs through the code.

Georgi

As your graphics are GCN5 you definitely have to move towards ROCm.
Clover will be retired in the next few months:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19385

---

“The good thing about science is that it's true whether or not you believe in it.” ― Neil deGrasse Tyson

Check this out. This could put some enlightenment to the issue with

amdgpu: The CS has been rejected (-125), but the context isn't robust.
amdgpu: The process will be terminated.

Amdgpu timeout with OpenCl kernel (reproducible)

Random GPU crashes amdgpu across 2 different GPUs

Send your feed back on your progress with that.

---

“The good thing about science is that it's true whether or not you believe in it.” ― Neil deGrasse Tyson

The new version in Windows is now working on my older OpenCL 1.2 cards (R9 280X).

Just need more speed, nothing is getting to full temperature. How much faster do you expect to make them go eventually?

My R9 Nano and R9 280X cards are both taking the same 20 minutes to complete a task. This is odd considering the Nano is exactly twice as fast by specs and by other projects.

Are you perhaps limiting it to so many computing units, and the Nano is only usually faster because it has more of them?

Good to hear it's working.

At the moment there is an issue utilizing too many cores and memory allocation, so yes, there is a limitation.
I've ordered one RX 580. When it arrives I'll try to find what is wrong with kernel execution on bigger grid. Can't say much more for now.

---

“The good thing about science is that it's true whether or not you believe in it.” ― Neil deGrasse Tyson