Arch Linux with 5.13 kernel (latest amd staging kernel) and the ROCm 4.3.1 drivers. they are on an unsupported platform, and compiled the drivers for their use from source. also on a threadripper 3000 platform.
great to hear. interested to hear your results if it runs or not. if it runs, I don't think it will be faster, but I'm just hoping it at least doesn't produce errors.
hey Wedge, can you try again but on your dual [2] Radeon VII, Threadripper system?
I'd prefer not to until I have confidence that I'll have any different results from the past - it's my primary machine, the one I use for day-to-day work and play. My past experience with it is the same as what I just described for Vega10 - BOINC simply doesn't like to co-operate with ROCr/ROCm-based drivers, I've only had (BOINC) success with PAL-based OpenCL for Vega GPUs.
I had a lot of help on this in the past from mountkidd, in fact they were the one to let me know of the incompatibility between certain amdgpu-pro versions and Ubuntu kernels in the first place.
Ian&Steve C. wrote:
and can you tell me more about the Vega 10 system you tried, what motherboard and what slot on the board is the Vega plugged into (are any risers being used)? I see the CPU being used is a FX-8350, which only supports PCIe 2.0 and from what I can tell, all lanes flow through the chipset and not direct to the CPU like newer architectures.
I'm aware of the PCIe atomics requirements of ROCm but I understood that's only relevant for older GPU generation - they dropped that requirement for Vega-generation GPUs, as you mentioned. I have several similar 990FX-based motherboards and the same results in all of them. No risers, I only use motherboard slots. And while the block diagrams indicate PCIe lanes through the 990FX chipset vs the CPU for Threadripper, I've observed no difference in OpenCL behaviour between the two, at least in the past.
Arch Linux with 5.13 kernel (latest amd staging kernel) and the ROCm 4.3.1 drivers. they are on an unsupported platform, and compiled the drivers for their use from source. also on a threadripper 3000 platform.
Encouraging to know it's possible (haven't seen many other Vega successes till now) but I'm generally not at the level of self-compiling drivers (I self-compile some of my favourite applications though). The performance appears to be substantially better than the amdgpu-pro drivers too, if it is indeed ROCm that accounts for the substantially shorter run times.
I've reported my issues on both AMD Community and ROCm GitHub, but if self-compiling the driver produces good results I wonder if there's an issue with the driver packaging for Ubuntu somewhere.
The user you mentioned appears to be anonymous. Would he/she be willing to provide some input on how they got it working with BOINC so well?
I spoke with another user,
)
I spoke with another user, who had success on their threadripper/Radeon VII system on Linux: https://einsteinathome.org/host/12883790/tasks/0/0?page=1
Arch Linux with 5.13 kernel (latest amd staging kernel) and the ROCm 4.3.1 drivers. they are on an unsupported platform, and compiled the drivers for their use from source. also on a threadripper 3000 platform.
I'm definitely thinking driver issues still.
_________________________________________________________________________
How do you lock
)
How do you lock coproc_info.xml? I thought after editing to 2.0, chmod 444, reboot -but no, back to plan class 102, no 1.28. :(
solling2 wrote:How do you
)
your computers are hidden and I can't see what system you're trying to modify.
what is the CPU/motherboard/driver version/GPU/OS/kernel being used?
you lock the coproc by setting it to read only permissions
and then changing the attribute with:
sudo chattr +i coproc_info.xmlyou have to do both steps.
_________________________________________________________________________
Thanks, I had missed that
)
Thanks, I had missed that second step, but with that it didn't work either, sigh.
I set up a test system with I5 core, Z370 chipset, Rocm 430, Ellesmere,Mint 20.2 [5.4.0].
Merely 1.18 WUs in 920 - 960 s at 2x.
post the contents of your
)
post the contents of your locked coproc file.
you need to make the change, save file, close, then set read only, then run the chattr command.
and sorry. I made a mistake it should be "+i" not "-i"
_________________________________________________________________________
"+" did the trick finally,
)
"+" did the trick finally, thanks a lot.
1.28 up and running now. Will report.
Ian&Steve C. schrieb: post
)
<coprocs>
<ati_opencl>
<name>Ellesmere [Radeon RX 470/480/570/570X/580/580X/590]</name>
<vendor>Advanced Micro Devices, Inc.</vendor>
<vendor_id>4098</vendor_id>
<available>1</available>
<half_fp_config>0</half_fp_config>
<single_fp_config>190</single_fp_config>
<double_fp_config>63</double_fp_config>
<endian_little>1</endian_little>
<execution_capabilities>1</execution_capabilities>
<extensions>cl_khr_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_ima>
<global_mem_size>4294967296</global_mem_size>
<local_mem_size>65536</local_mem_size>
<max_clock_frequency>1120</max_clock_frequency>
<max_compute_units>32</max_compute_units>
<nv_compute_capability_major>0</nv_compute_capability_major>
<nv_compute_capability_minor>0</nv_compute_capability_minor>
<amd_simd_per_compute_unit>4</amd_simd_per_compute_unit>
<amd_simd_width>16</amd_simd_width>
<amd_simd_instruction_width>1</amd_simd_instruction_width>
<opencl_platform_version>OpenCL 2.0 AMD-APP (3305.0)</opencl_platform_version>
<opencl_device_version>OpenCL 2.0 </opencl_device_version>
<opencl_driver_version>3305.0 (HSA1.1,LC)</opencl_driver_version>
<device_num>0</device_num>
<peak_flops>4587520000000.000000</peak_flops>
<opencl_available_ram>4294967296.000000</opencl_available_ram>
<opencl_device_index>0</opencl_device_index>
<warn_bad_cuda>0</warn_bad_cuda>
</ati_opencl>
<warning>NVIDIA: libcuda.so: cannot open shared object file: No such file or directory</warning>
<warning>ATI: libaticalrt.so: cannot open shared object file: No such file or directory</warning>
</coprocs>
solling2 wrote: "+" did the
)
great to hear. interested to hear your results if it runs or not. if it runs, I don't think it will be faster, but I'm just hoping it at least doesn't produce errors.
_________________________________________________________________________
first 1.28 (x2) result in
)
first 1.28 (x2) result in now: Completed, waiting for validation
Time: 960 s, so exactly what the 1.18 batch took.
Will let that test system run overnight.
[EDIT: Over night all went fine. No errors, several validated already. Meanwhile, a special 1.28 topic has been opened in the Crunchers Corner.]
Ian&Steve C. wrote: hey
)
I'd prefer not to until I have confidence that I'll have any different results from the past - it's my primary machine, the one I use for day-to-day work and play. My past experience with it is the same as what I just described for Vega10 - BOINC simply doesn't like to co-operate with ROCr/ROCm-based drivers, I've only had (BOINC) success with PAL-based OpenCL for Vega GPUs.
I had a lot of help on this in the past from mountkidd, in fact they were the one to let me know of the incompatibility between certain amdgpu-pro versions and Ubuntu kernels in the first place.
I'm aware of the PCIe atomics requirements of ROCm but I understood that's only relevant for older GPU generation - they dropped that requirement for Vega-generation GPUs, as you mentioned. I have several similar 990FX-based motherboards and the same results in all of them. No risers, I only use motherboard slots. And while the block diagrams indicate PCIe lanes through the 990FX chipset vs the CPU for Threadripper, I've observed no difference in OpenCL behaviour between the two, at least in the past.
Encouraging to know it's possible (haven't seen many other Vega successes till now) but I'm generally not at the level of self-compiling drivers (I self-compile some of my favourite applications though). The performance appears to be substantially better than the amdgpu-pro drivers too, if it is indeed ROCm that accounts for the substantially shorter run times.
I've reported my issues on both AMD Community and ROCm GitHub, but if self-compiling the driver produces good results I wonder if there's an issue with the driver packaging for Ubuntu somewhere.
The user you mentioned appears to be anonymous. Would he/she be willing to provide some input on how they got it working with BOINC so well?
Soli Deo Gloria