Using OpenCL on FreeBSD

astyle

Daemon

Reaction score: 480
Messages: 1,110

I'm trying to get OpenCL going on FreeBSD. The GPU that I have is an Asus Radeon RX 550 4 GB. Per these instructions, I installed lang/clover, benchmarks/clpeak, devel/ocl-icd, deve/clinfo, and graphics/drm-kmod. I successfully got a Plasma Wayland session going, so I know graphics/drm-kmod is working. And I have everything compiled from ports, with as many options enabled as possible. The ports snapshot is from early July.

My problem is really the fact that benchmarks/clpeak keeps dumping core and crashing. If I don't start Plasma Wayland, I can actually get my benchmarking numbers on the TTY before clpeak announces 'core dumped'. Trying to run clpeak inside a Plasma Wayland session (e.g., Konsole) crashes the GUI session so hard, I can't even SSH in and reboot.

Today, I tried to see if Blender can take advantage of OpenCL. There's a config option that I tried:
1627097133999.png

Trouble is, selecting OpenCL made Blender crash and dump core.

This is making me conclude that even though I do have properly compiled codecs on VLC, and it will play stuff reasonably smooth, even the HD stuff, I can't use GPU acceleration properly at this point. Not for playing videos, not for speeding up renders on Blender, not for transcoding/subtitling videos. My Ryzen 5 1400 (3.4 GHz) is still stuck doing the heavy lifting for all that.

I strongly suspect this has something to do with devel/ocl-icd not working properly... both clpeak and clinfo crash. I've seen suggestions to use valgrind, and I discovered oclgrind recently to troubleshoot this.
 
OP
astyle

astyle

Daemon

Reaction score: 480
Messages: 1,110

Did some research, only to discover that my hardware may be unsupported:
  1. According to ROCm's github page, my GPU is actually supported, but my CPU is not on the list. Closest thing to my CPU is a Ryzen 5 1600 (Mine is 1400), and Amazon shows it for ~$200 USD. The difference is something called PCI-E Atomics. According to ROCm docs, it is important to have that. Haven't explored the issue further, but I suspect that PCI-E Atomics could be the reason behind the core dumps I mentioned in the previous post.
    1. It may be a viable option to look at sysctl(8) or even the BIOS to see if PCI-E Atomics can be set using those methods - needs to be explored further.
  2. My mobo (Asus B350 Prime): Yeah, it will support the 1600 (and even one more GPU for CrossFire, per GPUmag.com and pcpartpicker.com). Doesn't look like a B-chipset vs X-chipset mobo is really the issue... At least that's the conclusion I drew from a quick glance at official documentation.
  3. It does sound like X570 mobos with Zen 3 CPU's will propertly support PCI-E Atomics. Looks like Zen 3 first, then an X570 mobo for best results.
  4. I did briefly consider trying a Windows install on my hardware just to see if that makes a difference for Blender being able to use OpenCL. After all, it's just a matter of swapping in a different SSD. But even then, that's time consuming, and I'm reluctant to blow $30 on an SSD just to find that out.
 
OP
astyle

astyle

Daemon

Reaction score: 480
Messages: 1,110

Yeah, my research did confirm that Vull had compatible hardware, unlike me. That's most likely why he had no segfaults, and could go much further than I could.

Seems like that mesa-libs bug is still open... As I suspected, it does have something to do with graceful exits, as in, not properly handling lack of support for PCI-E Atomics.

Looks like my options are: 1. Buy a compatible CPU ($200), or 2. Save up and build another rig with compatible parts (Cezanne Zen 3 CPU on an X570 mobo with a Big Navi GPU). I'm frankly leaning towards the latter, even though it will come much later.

Marking this SOLVED, because I did enough research to track the problem down to incompatible hardware...
 

Vull

Aspiring Daemon

Reaction score: 446
Messages: 740

Yeah, my research did confirm that Vull had compatible hardware, unlike me. That's most likely why he had no segfaults, and could go much further than I could.

Seems like that mesa-libs bug is still open... As I suspected, it does have something to do with graceful exits, as in, not properly handling lack of support for PCI-E Atomics.

Looks like my options are: 1. Buy a compatible CPU ($200), or 2. Save up and build another rig with compatible parts (Cezanne Zen 3 CPU on an X570 mobo with a Big Navi GPU). I'm frankly leaning towards the latter, even though it will come much later.

Marking this SOLVED, because I did enough research to track the problem down to incompatible hardware...
Might check pawn shops; I just got lucky finding this Lenovo G50-45 laptop w/1TB hdd for $200 at a nearby pawnshop and it's proven to be very compatible with FreeBSD-13.0-Release and the newer drm-kmod stuff.
 
OP
astyle

astyle

Daemon

Reaction score: 480
Messages: 1,110

According to ROCm's github page, my GPU is actually supported, but my CPU is not on the list. Closest thing to my CPU is a Ryzen 5 1600 (Mine is 1400), and Amazon shows it for ~$200 USD. The difference is something called PCI-E Atomics. According to ROCm docs, it is important to have that. Haven't explored the issue further, but I suspect that PCI-E Atomics could be the reason behind the core dumps I mentioned in the previous post.
What's driving me nuts is that ROCm (Debuted in 2019) only supports a limited subset of AMD's own processors - but Intel - no problem since Haswell (Released in 2013)! From get-go Intel's CPU had no problems, but AMD's own got no love. To top it off, NVidia has no problems running OpenCL kernels - clpeak's project page features clpeak being run on an NVidia card!
 
OP
astyle

astyle

Daemon

Reaction score: 480
Messages: 1,110

1. Blender always crashes with Clover (due to bugs in the latter).
Not Clover, but mesa-dri. The bug report suspects problematic exit handling in that Mesa lib, and I did see which file. I also hypothesized the exit crash might be be due to mesa-dri not handling lack of CPU support for PCI-E Atomics.
2. Clover doesn't have anything to do with ROCm's hardware requirements.
Yes and no. Clover kernels can run on NVidia no problem. lang/intel-compute-runtime is 'Clover for Intel CPUs with iGPU' and lang/pocl is 'Clover compiler for ignoring a GPU, and running on a CPU'. All that doesn't change the fact that if you want to run a Clover kernel on an AMD GPU, you have to have ROCm-compatible hardware.
3. Future Blender versions will not support OpenCL: https://code.blender.org/2021/04/cycles-x/.
Yeah, I saw this, too. Until Blender releases 3.0, it is actually able to use OpenCL. For time being, I'm treating that as a quick-and-dirty way to check that OpenCL actually works on AMD GPU.
 

shkhln

Daemon

Reaction score: 964
Messages: 2,217

Not Clover, but mesa-dri. The bug report suspects problematic exit handling in that Mesa lib, and I did see which file.
Clover is the name of the OpenCL driver bundled with Mesa: https://www.phoronix.com/scan.php?page=news_item&px=Mesa-20.3-OpenCL-1.2-Clover. (Mesa's components have their own names because there are often multiple alternative ones.)

I also hypothesized the exit crash might be be due to mesa-dri not handling lack of CPU support for PCI-E Atomics.
That's a completely baseless assumption.

Yes and no. Clover kernels can run on NVidia no problem.
"Kernel" is not a part of the driver, that's a fancy term for the program executed on GPU ("shader" is another one). So, they are just OpenCL kernels. And, of course, Clover doesn't run on Nvidia [proprietary driver], Nvidia has their own OpenCL implementation.

To be clear, a GPU driver is the code that runs on CPU that is tasked with compiling and submitting shaders for GPU execution as well as submitting/receiving data for/from those shaders. GPU drivers don't run on GPUs!

lang/intel-compute-runtime is 'Clover for Intel CPUs with iGPU' and lang/pocl is 'Clover compiler for ignoring a GPU, and running on a CPU'.
No, just no.

All that doesn't change the fact that if you want to run a Clover kernel on an AMD GPU, you have to have ROCm-compatible hardware.
Incorrect.
 
Top