Opencl on ARM - Unable to retrieve platform id - arm

I am running open cl on a linux machine with ARM processor and Mali GPU remotely. But it is giving an error something like "Unknown error: cannot retrieve platform id" at clGetPlatformIDs().
I tried both
cl_uint numPlatforms; //the NO. of platforms
cl_platform_id platform = NULL; //the chosen platform
cl_int status = clGetPlatformIDs(0, NULL, &numPlatforms);
and
cl_int status = clGetPlatformIDs(1, &platform, &numPlatforms);
but for both, I am getting the same error. The same code is working for me on my personal windows laptop with AMD graphics.
What could be the reason for this error?

Reason can be simple - OpenCL driver isn't working well. That's why you can't load platforms list. Did you test that ARM machine with OpenCL code before?

By arm linux machine you mean arm chromebook? libOpenCL.so in your machine is only a stub driver. Actual platform implementations are listed in /etc/OpenCL/vendors. You could also have libOpenCL.so without icd support exposing only 1 platform
In any case if its samsung arm chromebook, arm has a detailed setup guide for mali opencl & opengl-es http://malideveloper.arm.com/develop-for-mali/features/graphics-and-compute-development-on-samsung-chromebook/

Related

Will all ARM compilers produce the same Assembly code and run on various CPUs?

I have been developing code for an older device which has an NXP i.MX28 single core CPU which is ARM-based. The device runs Embedded Linux.
I am now upgrading to a better device which has an NXP i.MX6UL quad core processor, of course ARM-based also, and also running Embedded inux.
Is it normal that the same toolchain which I was using for the for building the code for the i.MX28 will also work for the i.MX6UL, even though the i.MX6UL is more advanced with more cores etc.?
I have built my code now for a test with the same compiler and even run it on a Rasberry Pi which seems to run ok. The Rasberry Pi uses a Broadcom BCM2711 SoC with an ARM Cortex-A72 processor which again is a different CPU.
I therefore must ask, will any ARM toolchain build code and be able to run on any type of ARM device regardless?
CPUs differ by the core architecture (incl. instruction set) and set of peripherals. Difference in the peripherals is solved by drivers and HALs. Difference in core arch is solved by the toolchain.
If the toolchain "knows" new arch it will emit the corresponding assembly code, that will run on the new CPU. So, compilers will not produdce the same assembly, but the same source code will run after rebuild, that's the idea of high-level languages.
Problems emerge when old code contains an inline assembly, or uses some specific DSP instructions or libraries

GPU ARM Mali and OpenCL driver

I have my TinkerBoard powered by an ARM-based Maliā„¢-T764 GPU. I am running Debian linaro v2.0.8 strech.
I am looking for an OpenCL support, how can I enable the GPU MALI with OpenCL 1.2 FP?
If you can advice me to update it I would appreciate it.
You need to install the binary ARM Mali drivers. How you do that, depends on the distro you're using. On Odroids for example, it comes installed with their Ubuntu.
Once you have it installed, it either comes with OpenCL enabled, or you can simply enable it: create a file /etc/OpenCL/vendors/mali.icd and put inside that file the path to the driver, e.g. on my Odroid it's /usr/lib/arm-linux-gnueabihf/mali-egl/libmali.so
So first i'd ask on whatever communication channels Debian Linaro has, how to install the binary drivers.

Vulkan SDK detects only 1 GPU at a time

I have an Optimus notebook (meaning it has two graphics cards; one integrated and one discrete (dedicated)). Both of them support Vulkan and I can use each of them individually on my code. But there is a problem, I can't list or use them both on the same program. I must select on which GPU it runs before running my code (on Windows: right click on "myProgram.exe" -> Run with graphics processor, on Linux: ./"myProgram" for integrated GPU and primusrun ./"myProgram" for discrete) and it detects only the one I run my code on even when both GPUs are active at the same time.
My GPUs are Intel UHD Graphics 630 and NVIDIA GeForce GTX 1050 Ti. I am using LunarG Vulkan SDK 1.1.92, Intel driver version 25.20.100.6326, NVIDIA driver version 416.32 on Windows and 415.25 on Linux. As C compiler and operating system, MSVC 1912 on Windows 10 and gcc 8.2.1 on Arch Linux. Vulkan runtime and ICD loaders are installed and I get the same result on both OSs.
Here is my code:
uint32_t deviceCount;
vkEnumeratePhysicalDevices(instance, &deviceCount, NULL);
printf("Found: %d\n", deviceCount);
VkPhysicalDevice *devices = malloc(deviceCount * sizeof(VkPhysicalDevice));
vkEnumeratePhysicalDevices(instance, &deviceCount, devices);
for(uint32_t deviceIndex = 0; deviceIndex < deviceCount; deviceIndex++)
{
VkPhysicalDeviceProperties deviceProperties;
vkGetPhysicalDeviceProperties(devices[deviceIndex], &deviceProperties);
printf("%s\n", deviceProperties.deviceName);
}
Here is the outputs I get:
If I run on integrated GPU:
Found: 1
Intel(R) UHD Graphics 630
If I run on dedicated GPU:
Found: 1
GeForce GTX 1050 Ti
What I am expecting is:
Found: 2
Intel(R) UHD Graphics 630
GeForce GTX 1050 Ti
And I should be able to pick either of them to use on my program without hassling with some driver level code or setting it on my OS before running. Vulkan is relatively low level API after all. Is there any way to force list all of the active GPUs on my system?
I'm not sure what you mean by
If I run on integrated GPU
versus
If I run on dedicated GPU"...
If you're going into the nVidia control panel and specifying a target GPU for your application, then you're seeing pretty much what I would expect... only that GPU exposed to your app.
I believe what you should be doing is setting it to auto-detect, and then ensuring that you're exporting the "Optimus Aware" flag in your binary. You should have something like this in your test code
extern "C" {
_declspec(dllexport) uint32_t NvOptimusEnablement = 0x00000001;
}
That should either cause Vulkan to see both GPUs, or force your application to automatically see only the discrete GPU, but without you having to do anything in the control panel, not sure which.

OpenCL, my GPU it's not capable?

I have an old computer, then I don't know if I can execute OpenCL codes on my PC; I've checked my GPU and I get this output:
When I execute OpenCL code, I get this error:
Finally, if I run clinfo, i get this:
I really don't know..It's a problem of libraries?Or my GPU cannot execute OpenCL codes?
Your GPU predates OpenCL. Beignet supports Ivybridge and later (https://www.freedesktop.org/wiki/Software/Beignet/#supportedtargets).
Your CPU also predates OpenCL. Intel's first release of their CPU-only OpenCL driver requires SSE4.1, but your CPU only has SSE3. If you really really need to get OpenCL to work on this machine, you may be able to install an old version (2.8) of the AMD OpenCL CPU driver if you can find it. Quote from http://boinc.berkeley.edu/wiki/OpenclCpu:
Intel's OpenCL support requires the SSE4.1 CPU feature (BOINC's event log shows you the list of your CPU's features).
If your host does not have SSE4.1 support, then you can install the AMD APP SDK 2.8 and it will install the AMD OpenCL CPU driver. Note that the AMD APP SDK v2.9 will NOT install it. You have to use 2.8 or earlier as they now bundle the OpenCL driver with the video driver instead of with the APP SDK. As AMD only keeps the last several versions on their archive page, you may want to grab both the 32 and 64 bit version of the v2.8 APP SDK now and keep them in a safe place.
Or maybe POCL or FreeOCL might cover you for the CPU.

ARM NetBSD5.1 Pthread support

I have NetBSD5.1 source. I have compiled the kernel and userland with the source. When I native compile a sample C program with pthread_create() in ARM NetBSD5.1, it is crashing. Same program is running successfuly in my Linux PC. Want to know if Pthread is supported in ARM machine which run NetBSD5.1 OS?
Note: other sample C programs native compiled in ARM machine runs successfully.
It should work, I think. (I don't have an ARM system running 5.1 at the moment -- mine are running a pre-7.0 -current.)
If you can show some more details about the crash, e.g. stack backtraces from the debugger, then perhaps I or someone else can provide more help.

Resources