I am on a system that uses an AMD CPU but since AMD stopped supporting OpenGL I had to switch to an alternative (POCL in my case, also mentioned in the guide). The installation so far seemed successful but when trying to start Fosphor I get this error:
[!] CL Error (-1001, /home/.../fosphor/gr-fosphor/lib/fosphor/cl.c:286): Unable to fetch platform IDs`
[!] No suitable OpenCL device found"
The guide also mentioned this error, specifically related to AMD CPUs:
When running python flowgraphs on machines with AMD graphics (fglrx driver) and UHD enabled in gr-osmosdr you may experience the following error [!] CL Error (-1001, fosphor/cl.c:268): Unable to fetch platform IDs. This is due to TLS sections in both, AMD OpenCL library and UHD library interfering with each other. A workaround is available through preloading the AMD OpenCL library LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libamdocl64.so osmocom_fft -F (path may vary). C++ flowgraphs are not affected.
I cannot follow this tip as I do not have the AMD OpenCL library installed. The only comparable library from POCL I was able to find on my system is libOpenCL.so. However, when I try running
First … don’t trust that guide too much, it’s … very outdated.
Truth is there are so many variation and drivers and stuff that it’s impossible for us to maintain an up-to-date comprehensive list.
So now : you say “AMD CPU” ? But what matter is the GPU you use, so do you mean you have a AMD Ryzen or so and you use the iGPU inside those ? If so : Which model exactly ?
I’m not sure what you mean by “AMD stopped supporting OpenGL” … OpenGL is still very much supported and for most AMD GPU is provided by Mesa directly.
OpenCL on the other hand is another matter … but I’ll need to know exactly which GPU you’re working with to know what the options are.
[Edited because I mixed up “OpenCL” with “OpenGL”]
Hey there, thank you for your fast reply.
The server I use does not have a GPU, that’s why I’ve been going for the CPU implementation of OpenCL at first. My information that AMD stopped supporting OpenCL for CPUs is from here: What is going on with OpenCL and Ryzen? - AMD Community. I’m on a Linux system and wasn’t able to find a OpenCL implementation so far.
The server’s CPU is an AMD Ryzen 9 7950X 16-Core Processor, you can find more information here: https://www.amd.com/en/product/12151 Under “Graphics Capabilities” it says that it uses Integrated Graphics, specifically AMD Radeon Graphics.
Does this mean that I actually am able to use a GPU implementation? If not, how would you go on? I hope I was able to provide all information you needed
So I’m assuming the screen is connected to that machine (fosphor wouldn’t work through X forwarding or anything like that), so it had to have a GPU somewhere
And indeed the 7950X has a built-in iGPU and should be able to be used for fosphor.
Before I dig further, a bit of terminology reminder (simplified):
“Mesa” is the project that provides Free Software implementation of various 3D/Compute API for multiple vendors : OpenGL / OpenCL / Vulkan / …
“Gallium” is the name of the internal API between “vendor specific” drivers inside Mesa and the generic part that implement the user visible API (OpenGL / OpenCL / …)
As far as compute stacks that will work with your particular GPU, there are several options :
ROCM : This is the official Compute stack from AMD and it includes OpenCL support. Unfortunately their support for iGPU is not quite official so you have to override some checks to enable it. I think for that iGPU it would be export HSA_OVERRIDE_GFX_VERSION=10.3.6 but I don’t have it so can’t be sure.
RustiCL: This is a new OpenCL stack from Mesa project itself. It’s usually not enabled by default, so you need to export RUSTICL_ENABLE=radeonsi to enable it to work over the radeon Gallium driver. I tested and RustiCL definitely can run fosphor.
Clover: This is a previous OpenCL stack from Mesa well, I’m not 100% sure if it has all the support required to run fosphor, I don’t think I have ever tried.
There is also of course the option to not use any of the GPU and just run on your CPU:
POCL: This is a Free Software CPU runtime. I’ve just tested and fosphor runs on it if you use the latest version (4.0) and if you compile it with CONFORMANCE disabled ( part of it is not 100% conformant to spec and they disable those parts if you have this option enabled, but we need those parts for fosphor).
Intel OpenCL CPU runtime: This was provided by Intel to run on their CPU but of course it was working on any modern x86 CPU. They seem to have discontinued it to promote their “oneAPI” stuff … You can still download some file from here but you’ll need to juggle a bit to make it work on your setup ( unpack some RPM, place stuff at the right spot … ). I know it used to run fosphor back in the days, but I couldn’t immediately make it work on my newer laptop … didn’t dig much though.
The best method to install / setup any of those is very dependent on your distribution however so I’m not sure I can provide much help there.
As a side note, I saw a post from you on the GR mailing list : Are you trying to setup “RFNoC fosphor” or “fosphor” ? Theses are very different projects …
fosphor / gr-fopshor : This is all done on CPU/GPU and doesn’t depend on any particular hardware.
RFNoC fosphor : This is specific to Ettus RFNoC platform and although the display is meant to look like the former, the bulk of the computing is done in a FPGA and then on the GNURadio side you just have a block that handles the rendering of the data to screen.
They have nothing in common. Well … they have me since I wrote both, but from software components to install, they are independent.
First of all, thank you very much for your extensive reply. Also it’s very thoughtful of you for explaining the different terms and components I’m still quite inexperienced in that area
So I’m assuming the screen is connected to that machine
So far I’m using VNC to access the screen remotely but it’s also possible to connect a screen to the machine.
ROCM : This is the official Compute stack from AMD and it includes OpenCL support.
Also when speaking of exporting e.g. HSA_OVERRIDE_GFX_VERSION are you just referring to exporting Linux system variables?
I’ve just tested and fosphor runs on it if you use the latest version (4.0) and if you compile it with CONFORMANCE disabled
Very nice to know, I’m gonna re-install POCL with conformance disabled then.
The best method to install / setup any of those is very dependent on your distribution however so I’m not sure I can provide much help there.
My distro is the latest version of Debian, Debian 12.
As a side note, I saw a post from you on the GR mailing list
Great to see you on the GR mailing list as well Hope you don’t mind that I double-posted here and there but considering the small communities, the more the merrier I guess.
Considering that I’ve also had quite a few troubles with the Ettus FPGA, I first wanted to make sure that gr-fosphor is working before moving on to RFNoC fosphor. Doesn’t RFNoC fosphor require the drivers, OpenCL, … as well?
Not really sure how that works. If there is a real X server running on the GPU and then just sending the frame, it might work, but if it’s not tied to the GPU then it might not.
Do OpenGL apps work ? Things like glxgears or even just glxinfo ( or eglinfo maybe if it’s wayland based). The result of the latter (glx/egl) would be interesting to see if you can post them on pastebin or such.
Ok, you can check if that worked by using the clinfo utility, it should show your GPU.
Yes
No, the RFNoC version doesn’t need OpenCL at all. It uses OpenGL only. The “C” is for “Compute” and all the computation is done in the FPGA and we just need the “G” for “Graphics” to display the result.
Additional info in the meantime: After having installed the AMD drivers over
sudo amdgpu-install --opencl=legacy --accept-eula
I have gotten this output when running clinfo:
Number of platforms 2
Platform Name rusticl
Platform Vendor Mesa/X.org
Platform Version OpenCL 3.0
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_icd
Platform Extensions with Version cl_khr_icd 0x400000 (1.0.0)
Platform Numeric Version 0xc00000 (3.0.0)
Platform Extensions function suffix MESA
Platform Host timer resolution 0ns
Platform Name Clover
Platform Vendor Mesa
Platform Version OpenCL 1.1 Mesa 22.3.6
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_icd
Platform Extensions function suffix MESA
Platform Name rusticl
Number of devices 0
Platform Name Clover
Number of devices 0
NULL platform behavior
clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) rusticl
clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) <error: 0 devices, multiple matching platforms!>
clCreateContext(NULL, ...) [default] No devices found in platform
clCreateContext(NULL, ...) [other] <error: no devices in non-default plaforms>
clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) No devices found in platform
ICD loader properties
ICD loader Name OpenCL ICD Loader
ICD loader Vendor OCL Icd free software
ICD loader Version 2.3.1
ICD loader Profile OpenCL 3.0
Before having installed the drivers, Number of platforms was 0 . Would you be able to say that this an indication for a correct installation?
So first, make sure to check my previous post, it seems we posted seconds appart so you might have missed it
From that clinfo it seems to have installed two platforms I mentioned earlier :
RustiCL
Clover
That’s probably because installing the AMD driver from AMD installed new mesa libraries compiled by AMD and not the default ones from debian and those were built with those options enabled and debian default one was not (or they were put in distinct packages).
Anyway, neither of those platforms are ROCM so it’s technically not the official AMD stack for that GPU (or rather the official AMD stack that could run on that GPU since officially AMD only supports their “pro” cards for ROCM).
The fact RustiCL got installed is nice though because you can maybe use that.
try to export RUSTICL_ENABLE=radeonsi and then in the same terminal run clinfo again.
The other platform it installed (Clover), I wouldn’t bother with. At least here (on a intel gpu, so not 100% comparable), it doesn’t support all the features needed by fosphor.
I’m not 100% sure of the required command line to install ROCM. The ones you pasted before (without the legacy opencl) seemed like a better bet. It wasn’t working ?
EDIT: Upon checking debian bookwork packages mesa-opencl-icd is what you’d have to install in debian 12 to get rusticl stack. But this is just FYI, now that you got it through the amdgpu thing, it’s best not to mix the two … The AMD installer kind of “takes over” and only if you go through the uninstall can you then use normal debian packages for mesa/gpu stuff again.
The output of clinfo after running export RUSTICL_ENABLE=radeonsi is:
Platform Name rusticl
Platform Vendor Mesa/X.org
Platform Version OpenCL 3.0
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_icd
Platform Extensions with Version cl_khr_icd 0x400000 (1.0.0)
Platform Numeric Version 0xc00000 (3.0.0)
Platform Extensions function suffix MESA
Platform Host timer resolution 0ns
Platform Name Clover
Platform Vendor Mesa
Platform Version OpenCL 1.1 Mesa 22.3.6
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_icd
Platform Extensions function suffix MESA
Platform Name rusticl
Number of devices 0
Platform Name Clover
Number of devices 0
NULL platform behavior
clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) rusticl
clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) <error: 0 devices, multiple matching platforms!>
clCreateContext(NULL, ...) [default] No devices found in platform
clCreateContext(NULL, ...) [other] <error: no devices in non-default plaforms>
clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) No devices found in platform
ICD loader properties
ICD loader Name OpenCL ICD Loader
ICD loader Vendor OCL Icd free software
ICD loader Version 2.3.1
ICD loader Profile OpenCL 3.0
I’m not 100% sure of the required command line to install ROCM. The ones you pasted before (without the legacy opencl) seemed like a better bet. It wasn’t working ?
I haven’t tried that one yet. When I first installed it I thought the opencl flag was necessary.
Upon checking debian bookwork packages mesa-opencl-icd is what you’d have to install in debian 12 to get rusticl stack. But this is just FYI
Thanks for looking that up, you have a great overview over all of this
So it’s a pure software implementation, not using the GPU and that’s most likely because you’re using some virtual VNC server and it has no proper GPU surface.
So moving to a local setup and get it working first there and then maybe after trying to translate it to a remote one would be a best approach.
I’m not 100% sure why rusticl wouldn’t find the GPU though, that should be independent.
Can you check which DRI drivers are present ?
List files in /usr/lib/x86_64-linux-gnu/gallium-pipe/ and /usr/lib/x86_64-linux-gnu/dri/ ( I think those are the path on debian … search for dri directory and gallium-pipe under /usr/lib or something if those path have nothing ).
You can also try RUSTICL_ENABLE=llvmpipe this will enable rusticl running on the software gallium driver which in effect makes it a CPU implementation of OpenCL.
-rw-r--r-- 1 root root 8246000 Mar 22 11:18 pipe_crocus.so
-rw-r--r-- 1 root root 13864 Mar 22 11:18 pipe_i915.so
-rw-r--r-- 1 root root 8352696 Mar 22 11:18 pipe_iris.so
-rw-r--r-- 1 root root 7228600 Mar 22 11:18 pipe_nouveau.so
-rw-r--r-- 1 root root 5485728 Mar 22 11:18 pipe_r300.so
-rw-r--r-- 1 root root 6021760 Mar 22 11:18 pipe_r600.so
-rw-r--r-- 1 root root 7332880 Mar 22 11:18 pipe_radeonsi.so
-rw-r--r-- 1 root root 5588024 Mar 22 11:18 pipe_swrast.so
-rw-r--r-- 1 root root 5487312 Mar 22 11:18 pipe_vmwgfx.so
and here’s .../dri/:
total 404984
-rw-r--r-- 13 root root 25762552 Mar 22 11:18 crocus_dri.so
-rw-r--r-- 13 root root 25762552 Mar 22 11:18 d3d12_dri.so
-rw-r--r-- 5 root root 12703584 Mar 22 11:18 d3d12_drv_video.so
-rw-r--r-- 13 root root 25762552 Mar 22 11:18 i915_dri.so
-rw-r--r-- 1 root root 1751600 Jul 11 2020 i965_drv_video.so
-rw-r--r-- 1 root root 14488216 Feb 18 2023 iHD_drv_video.so
-rw-r--r-- 13 root root 25762552 Mar 22 11:18 iris_dri.so
-rw-r--r-- 13 root root 25762552 Mar 22 11:18 kms_swrast_dri.so
-rw-r--r-- 13 root root 25762552 Mar 22 11:18 nouveau_dri.so
-rw-r--r-- 5 root root 12703584 Mar 22 11:18 nouveau_drv_video.so
-rw-r--r-- 13 root root 25762552 Mar 22 11:18 r300_dri.so
-rw-r--r-- 13 root root 25762552 Mar 22 11:18 r600_dri.so
-rw-r--r-- 5 root root 12703584 Mar 22 11:18 r600_drv_video.so
-rw-r--r-- 13 root root 25762552 Mar 22 11:18 radeonsi_dri.so
-rw-r--r-- 5 root root 12703584 Mar 22 11:18 radeonsi_drv_video.so
-rw-r--r-- 13 root root 25762552 Mar 22 11:18 swrast_dri.so
-rw-r--r-- 13 root root 25762552 Mar 22 11:18 virtio_gpu_dri.so
-rw-r--r-- 5 root root 12703584 Mar 22 11:18 virtio_gpu_drv_video.so
-rw-r--r-- 13 root root 25762552 Mar 22 11:18 vmwgfx_dri.so
-rw-r--r-- 13 root root 25762552 Mar 22 11:18 zink_dri.so
You could try (as a test! not for usage!) to run clinfo as root temporarily
Tried that and I wasn’t able find a difference compared to running clinfo as my standard user. To be sure, here’s the output anyway
Platform Name rusticl
Platform Vendor Mesa/X.org
Platform Version OpenCL 3.0
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_icd
Platform Extensions with Version cl_khr_icd 0x400000 (1.0.0)
Platform Numeric Version 0xc00000 (3.0.0)
Platform Extensions function suffix MESA
Platform Host timer resolution 0ns
Platform Name Clover
Platform Vendor Mesa
Platform Version OpenCL 1.1 Mesa 22.3.6
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_icd
Platform Extensions function suffix MESA
Platform Name rusticl
Number of devices 0
Platform Name Clover
Number of devices 0
NULL platform behavior
clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) rusticl
clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) <error: 0 devices, multiple matching platforms!>
clCreateContext(NULL, ...) [default] No devices found in platform
clCreateContext(NULL, ...) [other] <error: no devices in non-default plaforms>
clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) No devices found in platform
ICD loader properties
ICD loader Name OpenCL ICD Loader
ICD loader Vendor OCL Icd free software
ICD loader Version 2.3.1
ICD loader Profile OpenCL 3.0
Additionally please keep in mind that I won’t be able to reply until Monday. That’s when I can also test the local screen setup. Thank you two for all your help so far
Also when trying as root, don’t use sudo clinfo because sudo will reset the environment variable, so you need to sudo -s to get a shell as root, then redo the export ... and then try clinfo.
Here’s the output of clinfo after running export RUSTICL_ENABLE=llvmpipe:
Number of platforms 2
Platform Name rusticl
Platform Vendor Mesa/X.org
Platform Version OpenCL 3.0
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_icd
Platform Extensions with Version cl_khr_icd 0x400000 (1.0.0)
Platform Numeric Version 0xc00000 (3.0.0)
Platform Extensions function suffix MESA
Platform Host timer resolution 0ns
Platform Name Clover
Platform Vendor Mesa
Platform Version OpenCL 1.1 Mesa 22.3.6
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_icd
Platform Extensions function suffix MESA
Platform Name rusticl
Number of devices 1
Device Name llvmpipe (LLVM 15.0.6, 256 bits)
Device Vendor Mesa/X.org
Device Vendor ID 0
Device Version OpenCL 3.0
Device Numeric Version 0xc00000 (3.0.0)
Driver Version 22.3.6
Device OpenCL C Version OpenCL C 1.2
Device OpenCL C all versions OpenCL C 0xc00000 (3.0.0)
OpenCL C 0x402000 (1.2.0)
OpenCL C 0x401000 (1.1.0)
OpenCL C 0x400000 (1.0.0)
Device OpenCL C features __opencl_c_int64 0x400000 (1.0.0)
__opencl_c_images 0x400000 (1.0.0)
__opencl_c_3d_image_writes 0x400000 (1.0.0)
Latest conformance test passed v0000-01-01-00
Device Type CPU
Device Profile FULL_PROFILE
Device Available Yes
Compiler Available Yes
Linker Available Yes
Max compute units 8
Max clock frequency 300MHz
Device Partition (core)
Max number of sub-devices 0
Supported partition types None
Supported affinity domains (n/a)
Max work item dimensions 3
Max work item sizes 1024x1024x1024
Max work group size 1024
Preferred work group size multiple (device) 32
Preferred work group size multiple (kernel) 32
Max sub-groups per work group 0
Preferred / native vector sizes
char 1 / 1
short 1 / 1
int 1 / 1
long 1 / 1
half 0 / 0 (n/a)
float 1 / 1
double 0 / 0 (n/a)
Half-precision Floating-point support (n/a)
Single-precision Floating-point support (core)
Denormals No
Infinity and NANs Yes
Round to nearest Yes
Round to zero No
Round to infinity No
IEEE754-2008 fused multiply-add No
Support is emulated in software No
Correctly-rounded divide and sqrt operations No
Double-precision Floating-point support (n/a)
Address bits 64, Little-Endian
Global memory size 2147483648 (2GiB)
Error Correction support No
Max memory allocation 2147483648 (2GiB)
Unified memory for Host and Device Yes
Shared Virtual Memory (SVM) capabilities (core)
Coarse-grained buffer sharing No
Fine-grained buffer sharing No
Fine-grained system sharing No
Atomics No
Minimum alignment for any data type 128 bytes
Alignment of base address 4096 bits (512 bytes)
Preferred alignment for atomics
SVM 0 bytes
Global 0 bytes
Local 0 bytes
Atomic memory capabilities relaxed, work-group scope
Atomic fence capabilities relaxed, acquire/release, work-group scope
Max size for global variable 0
Preferred total size of global vars 0
Global Memory cache type None
Image support Yes
Max number of samplers per kernel 32
Max size for 1D images from buffer 134217728 pixels
Max 1D or 2D image array size 2048 images
Base address alignment for 2D image buffers 0 bytes
Pitch alignment for 2D image buffers 0 pixels
Max 2D image size 16384x16384 pixels
Max 3D image size 2048x2048x2048 pixels
Max number of read image args 128
Max number of write image args 64
Max number of read/write image args 0
Pipe support No
Max number of pipe args 0
Max active pipe reservations 0
Max pipe packet size 0
Local memory type Global
Local memory size 32768 (32KiB)
Max number of constant args 1024
Max constant buffer size 134217728 (128MiB)
Generic address space support No
Max size of kernel argument 1576 (1.539KiB)
Queue properties (on host)
Out-of-order execution No
Profiling Yes
Device enqueue capabilities (n/a)
Queue properties (on device)
Out-of-order execution No
Profiling No
Preferred size 0
Max size 0
Max queues on device 0
Max events on device 0
Prefer user sync for interop Yes
Profiling timer resolution 0ns
Execution capabilities
Run OpenCL kernels Yes
Run native kernels No
Non-uniform work-groups No
Work-group collective functions No
Sub-group independent forward progress No
IL version (n/a)
ILs with version (n/a)
printf() buffer size 1048576 (1024KiB)
Built-in kernels (n/a)
Built-in kernels with version (n/a)
Device Extensions cl_khr_byte_addressable_store 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_3d_image_writes
Device Extensions with Version cl_khr_byte_addressable_store 0x400000 (1.0.0)
cl_khr_global_int32_base_atomics 0x400000 (1.0.0)
cl_khr_global_int32_extended_atomics 0x400000 (1.0.0)
cl_khr_local_int32_base_atomics 0x400000 (1.0.0)
cl_khr_local_int32_extended_atomics 0x400000 (1.0.0)
cl_khr_3d_image_writes 0x400000 (1.0.0)
Platform Name Clover
Number of devices 0
NULL platform behavior
clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) rusticl
clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) Success [MESA]
clCreateContext(NULL, ...) [default] Success [MESA]
clCreateContext(NULL, ...) [other] <error: no devices in non-default plaforms>
clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) Success (1)
Platform Name rusticl
Device Name llvmpipe (LLVM 15.0.6, 256 bits)
clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) Success (1)
Platform Name rusticl
Device Name llvmpipe (LLVM 15.0.6, 256 bits)
ICD loader properties
ICD loader Name OpenCL ICD Loader
ICD loader Vendor OCL Icd free software
ICD loader Version 2.3.1
ICD loader Profile OpenCL 3.0
Other than that, I am now able to run Fosphor The fosphor sinks from gr-fosphor now run successfully, even over VNC, when exporting the variable above beforehand.
Just out of curiosity, I’ve seen on the gr-fosphor GitHub that there are different colormaps available for Fosphor. How can I change the displayed colormap?
Glad to hear you got fosphor running. Although llvmpipe is basically CPU meaning it might be slow/use a lot of CPU, not sure what your target sample rate is, but might be worth continuing debug to see if getting it to run on the GPU is possible.
Yeah, the RFNoC fosphor display block isn’t in GR 3.10 and even then AFAIK it’s buggy in main … I need to look at that and also have the name changed to more clearly differentiate between RFNoC fosphor and the gr-fosphor.
Currently there isn’t really multiple color map supported except changing the code.
Although llvmpipe is basically CPU meaning it might be slow/use a lot of CPU, not sure what your target sample rate is, but might be worth continuing debug to see if getting it to run on the GPU is possible.
Yes, as of right now my fosphor flowgraph is very CPU heavy. I am able to make it run smoothly by reducing the input sample rate luckily. Gonna look into using the GPU soon.
Yeah, the RFNoC fosphor display block isn’t in GR 3.10 and even then AFAIK it’s buggy in main
That’s unfortunate to hear. I’m currently trying to port the GR 3.8 version of the block from gr-ettus (https://github.com/EttusResearch/gr-ettus/blob/maint-3.8-uhd4.0/include/ettus/fosphor_display.h) to GR 3.10 y myself but ran into an issue I wasn’t able to solve yet. You haven’t encountered something along the lines of recursively required by substitution of ‘template<class T> class in relation to importing QT classes while building the Fosphor .so by chance?
Other than that, I want to thank you again for your help
The fosphor sinks from gr-fosphor now run successfully, even over VNC, when exporting the variable above beforehand.
