Thanks, Gary, for the note you sent me, pointing me here. I passed this to Maximillian Bensch, who currently maintains the GW OpenCL code. We've not yet come across an OpenCL (driver) compiler which chokes at assigining a 'const float' to a 'float', i.e. one which handles these in different address spaces. If there is a reasonably easy fix, we will implement it.
I have been following this discussion and got interested in this problem. I also would like to start using the newest AMD drivers, the RocM and I attempted to build your latest Linux OpenCL app using the recommended sources downloaded from ...
The 6 math functions: atan2, … cos errors are mentioned specifically in several forums as a fallout of mixing static and dynamic libraries. I have not been able to resolve this problem. The libOpenCL.so I got from AMD is dynamic but the other libraries are built static. This should have worked as your makefile appears to have the correct instructions to handle both types of libraries.
I am guessing my compiler is newer and cannot handle, or possibly I should have used the NVidia sdk instead of the AMD, or some other problem. AFAICT the complete build went reasonably well with only warnings up till the "link"
I have nothing to so since I retired and thought I might look at this problem. I was able to build the Milkyway OpenCL app Your zip that I downloaded was very nicely organized and IMHO superior to the Milkyway build. Any help would be appreciated.
I see. This is the quality of discussion and depth of contribution you want here. It clearly was necessary for me to defend myself.
First my effort is summarily dismissed. Then I am admonished for rebuking the officious person who dismisses my effort, even when I selflessly follow up with further effort in spite of that dismissal. Then someone else appears with ... four separate posts intended to serially attach their name and judgment to prior content without independent contribution, entirely superfluous to a highly technical investigation, which no doubt made them feel very useful to themselves. But that of course receives no admonition. That's not rude at all.
I'm rude for pointing out what does not advance the problem solving and for carrying on. Very well.
I am glad and thankful the technical facts that I've been working on establishing have finally made their way to technical people to be taken seriously. I came here after avoiding your forums for ten years, and did the grunt work, to help the project -- not myself -- and was willing to do more. I will not make that mistake again; you all can obviously do without my bug wrangling, and I have every confidence that the professionals will inevitably do the correct thing on their own.
That is the end of this thread. Mr. Roberts: if you are sincere, and you wish to prevent further rudeness, you will lock it against further addenda from the peanut gallery lest someone else take offense at these attempts to get work done. Otherwise you can have the inappropriate comments that will surely multiply hereafter.
Mr Sagittarius: You are the owner of this thread and can request that it be deleted. I am sure that the moderator, Gary, will be happy to comply if you PM him nicely about it. Otherwise, it will be left here for very likely another 10 years and become an historical record. What type of historical record? That depends on your contribution. You can go back to your "safe space" or contribute to solving the problem by participating in the discussion.
[EDIT]
Gary: From reading the reference Mr Sagittarius listed in a previous post, it would appear that adding the option
“–cl-std=CL2.0” to the clBuildProgram() or clCompileProgram() programs the problem with the RocM drivers could be solved.
That OpenCL "build" is done in (binary file) ./3rdparty/libclfft/lib/amd/win32/2.6/libOpenCL.a
Inserting “–cl-std=CL2.0” in above using a binary editor probably would not work. However, adding it into the two places of the source should.
To test this, I attempted build a new version of the Linux OpenCL app but was unable to make the final link as described above. I assume adding that phrase will not lose backwards compatibility with boards supporting only 1.2 OpenCL. This would have to be tested and in any event I am not running those new drivers.
There is now a version 2.08 (Beta test, Linux, AMD GPU) that works at least with our (testwise) installation of Open Compute drivers. Please test and report!
Noticed a difference right away: The 2.08 GW take a 1/3 of a thread compared to about a 1/10 of a thread for GRP. This system has a 2 core Celeron 2 threads total. When all 5 gpus switch to the 208 it will be maxed out. Need to upgrade the CPU to an i7. I just checked again, all are running 2.08, used "Radeontop" all are under utilized and even the temperatures of all GPUs have dropped indicating they are being starved.
I pulled out three RX560s and currently have a pair of RX-570 and a single RX-580 which will allow me to install the RocM drivers.
Will also try an S9100 which is a "GFX7" as AMD indicated that series might work but was not guaranteed.
OK got RocM on Linux system, 18.04, with pair of RX570 and one RX580. Problem: The only board recognize by BOINC is the one in the X16 slot of the H81btc motherboard, an RX570. The other pair, RX570 and RX580 on risers are not recognized. They all worked fine using 19.50 Clearly there is a problem with BOINC not seeing all the boards. Going to let a few tasks process then will remove the RocM as it seems "mining" is not its things. Has anyone else had a problem with RocM and multiple boards? Does not look like RocM is ready for prime time.
There is now a version 2.08 (Beta test, Linux, AMD GPU) that works at least with our (testwise) installation of Open Compute drivers. Please test and report!
One of my machines has downloaded quite a number of the v2.08 test tasks. In an attempt to get quick validations, I've promoted a number of 'resends' that were included in the full set of new tasks. These are processing at the moment (and validating) without any apparent difference to the behaviour of former version tasks. This page shows the most recent validations of both the former v2.07 tasks and the first v2.08 tasks. As I write, the last three tasks in the list are validations of the new version. Obviously, things will change rather quickly as further tasks are processed. Currently, the host in question has no errors or invalid results so all appears normal.
The machine is a Ryzen 5 2600 with an RX 570 GPU running PCLinuxOS and using a 5.3.6 kernel. PCLOS is an RPM based distro and I'm using OpenCL components extracted from the Red Hat 18.30 version of AMDGPU-PRO. Obviously, this isn't ROCm but I was keen to test the new app to make sure everything still worked correctly for the majority of current volunteers who aren't likely to be using ROCm. It will be interesting to see if the OP can now successfully crunch these tasks.
Thank you very much for attending to this problem so promptly.
Thanks, Gary, for the note
)
Thanks, Gary, for the note you sent me, pointing me here. I passed this to Maximillian Bensch, who currently maintains the GW OpenCL code. We've not yet come across an OpenCL (driver) compiler which chokes at assigining a 'const float' to a 'float', i.e. one which handles these in different address spaces. If there is a reasonably easy fix, we will implement it.
BM
Thanks, Bernd. It's good to
)
Thanks, Bernd. It's good to know the problem is being investigated.
Cheers,
Gary.
I have been following this
)
I have been following this discussion and got interested in this problem. I also would like to start using the newest AMD drivers, the RocM and I attempted to build your latest Linux OpenCL app using the recommended sources downloaded from ...
https://einstein.phys.uwm.edu/download/brp-src-release.zip
This actually went pretty well until I got down to the "final build"
https://stateson.net/images/last_link.txt
The 6 math functions: atan2, … cos errors are mentioned specifically in several forums as a fallout of mixing static and dynamic libraries. I have not been able to resolve this problem. The libOpenCL.so I got from AMD is dynamic but the other libraries are built static. This should have worked as your makefile appears to have the correct instructions to handle both types of libraries.
I am guessing my compiler is newer and cannot handle, or possibly I should have used the NVidia sdk instead of the AMD, or some other problem. AFAICT the complete build went reasonably well with only warnings up till the "link"
I have nothing to so since I retired and thought I might look at this problem. I was able to build the Milkyway OpenCL app Your zip that I downloaded was very nicely organized and IMHO superior to the Milkyway build. Any help would be appreciated.
I see. This is the quality of
)
I see. This is the quality of discussion and depth of contribution you want here. It clearly was necessary for me to defend myself.
First my effort is summarily dismissed. Then I am admonished for rebuking the officious person who dismisses my effort, even when I selflessly follow up with further effort in spite of that dismissal. Then someone else appears with ... four separate posts intended to serially attach their name and judgment to prior content without independent contribution, entirely superfluous to a highly technical investigation, which no doubt made them feel very useful to themselves. But that of course receives no admonition. That's not rude at all.
I'm rude for pointing out what does not advance the problem solving and for carrying on. Very well.
I am glad and thankful the technical facts that I've been working on establishing have finally made their way to technical people to be taken seriously. I came here after avoiding your forums for ten years, and did the grunt work, to help the project -- not myself -- and was willing to do more. I will not make that mistake again; you all can obviously do without my bug wrangling, and I have every confidence that the professionals will inevitably do the correct thing on their own.
That is the end of this thread. Mr. Roberts: if you are sincere, and you wish to prevent further rudeness, you will lock it against further addenda from the peanut gallery lest someone else take offense at these attempts to get work done. Otherwise you can have the inappropriate comments that will surely multiply hereafter.
Mr Sagittarius: You are the
)
Mr Sagittarius: You are the owner of this thread and can request that it be deleted. I am sure that the moderator, Gary, will be happy to comply if you PM him nicely about it. Otherwise, it will be left here for very likely another 10 years and become an historical record. What type of historical record? That depends on your contribution. You can go back to your "safe space" or contribute to solving the problem by participating in the discussion.
[EDIT]
“–cl-std=CL2.0” to the clBuildProgram() or clCompileProgram() programs the problem with the RocM drivers could be solved.
There is now a version 2.08
)
There is now a version 2.08 (Beta test, Linux, AMD GPU) that works at least with our (testwise) installation of Open Compute drivers. Please test and report!
BM
I've got two 2.08 tasks
)
I've got two 2.08 tasks completed and validated right now, both against Nvidia 2.07 wingman. Regular 19.50 driver install here, just to indicate that.
Also running amdgpu-pro-core
)
Also running amdgpu-pro-core 19.50-967956
Noticed a difference right away: The 2.08 GW take a 1/3 of a thread compared to about a 1/10 of a thread for GRP. This system has a 2 core Celeron 2 threads total. When all 5 gpus switch to the 208 it will be maxed out. Need to upgrade the CPU to an i7. I just checked again, all are running 2.08, used "Radeontop" all are under utilized and even the temperatures of all GPUs have dropped indicating they are being starved.
I pulled out three RX560s and currently have a pair of RX-570 and a single RX-580 which will allow me to install the RocM drivers.
Will also try an S9100 which is a "GFX7" as AMD indicated that series might work but was not guaranteed.
OK got RocM on Linux system,
)
OK got RocM on Linux system, 18.04, with pair of RX570 and one RX580. Problem: The only board recognize by BOINC is the one in the X16 slot of the H81btc motherboard, an RX570. The other pair, RX570 and RX580 on risers are not recognized. They all worked fine using 19.50 Clearly there is a problem with BOINC not seeing all the boards. Going to let a few tasks process then will remove the RocM as it seems "mining" is not its things. Has anyone else had a problem with RocM and multiple boards? Does not look like RocM is ready for prime time.
Walkthrough for install of RocM: https://stateson.net/images/rocm_walkthru.txt
/opt/rocm/bin/rocminfo : https://stateson.net/images/rocm_info.txt
/opt/rocm/opencl/bin/x86_64/clinfo : https://stateson.net/images/clinfo_rocm.txt
the above lists 3 AMD GPUs, not sure why BOINC cannot find them as it sees only the one
shown in coproc_info.xml
from /var/lib/boinc/coproc_info.xml : https://stateson.net/images/rocm_coproc_info.xml
from event messages (note only one GPU shows up)
Starting BOINC client version 7.16.3 build:2020-01-25T15:48:07 for x86_64-pc-linux-gnu
Libraries: libcurl/7.58.0 GnuTLS/3.5.18 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Data directory: /var/lib/boinc-client
OpenCL: AMD/ATI GPU 0: Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (driver version 3052.0 (HSA1.1,LC), device version OpenCL 1.2, 4096MB, 4096MB available, 5243 GFLOPS peak)
[libc detection] gathered: 2.27, Ubuntu GLIBC 2.27-3ubuntu1
Host name: jyslinux1
Processor: 2 GenuineIntel Intel(R) Celeron(R) CPU G1840 @ 2.80GHz [Family 6 Model 60 Stepping 3]
Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmper
OS: Linux Ubuntu: Ubuntu 18.04.4 LTS [5.3.0-40-generic|libc 2.27 (Ubuntu GLIBC 2.27-3ubuntu1)]
Bernd Machenschalk
)
One of my machines has downloaded quite a number of the v2.08 test tasks. In an attempt to get quick validations, I've promoted a number of 'resends' that were included in the full set of new tasks. These are processing at the moment (and validating) without any apparent difference to the behaviour of former version tasks. This page shows the most recent validations of both the former v2.07 tasks and the first v2.08 tasks. As I write, the last three tasks in the list are validations of the new version. Obviously, things will change rather quickly as further tasks are processed. Currently, the host in question has no errors or invalid results so all appears normal.
The machine is a Ryzen 5 2600 with an RX 570 GPU running PCLinuxOS and using a 5.3.6 kernel. PCLOS is an RPM based distro and I'm using OpenCL components extracted from the Red Hat 18.30 version of AMDGPU-PRO. Obviously, this isn't ROCm but I was keen to test the new app to make sure everything still worked correctly for the majority of current volunteers who aren't likely to be using ROCm. It will be interesting to see if the OP can now successfully crunch these tasks.
Thank you very much for attending to this problem so promptly.
Cheers,
Gary.