I installed ArrayFire successfully, and the example helloworld works fine when I choose the Visual Studio configuration CUDA_x64. However when I change to OpenCL_x64, the compilation is successful, but I get the running error as below:
/*********************************************************************/
ArrayFire Exception (Internal error:998):
In function __cdecl opencl::DeviceManager::DeviceManager(void)
In file src\backend\opencl\platform.cpp:329
OpenCL Error (-2): Device Not Available when calling clCreateContext
In function void __cdecl af::setDevice(const int)
In file src\api\cpp\device.cpp:91
/*********************************************************************/
Any answers will be appreciated. Thanks in advance.
-2 is CL_DEVICE_NOT_AVAILABLE which occurs "if a device in devices is currently not available even though the device was returned by clGetDeviceIDs". You can Google for the name of the error and find a number of web pages which describe cases where this can happen; two common ones are using the Intel CPU driver on an older chip (The latest Intel OpenCL SDK requires SSE 4.2), or requesting OpenCL/OpenGL interop when it is not available.
Related
I have a Java 9 app that I'm trying to package for the Windows Store. The strange thing is that it works as expected when I run the exe-launcher directly, but I get the following strange error when I run the launcher via the APPX package:
Exception in thread "Swing-Shell" java.lang.InternalError: Could not
initialize COM: HRESULT=0x80010106
at java.desktop/sun.awt.shell.Win32ShellFolderManager2.initializeCom(Native Method)
at java.desktop/sun.awt.shell.Win32ShellFolderManager2$ComInvoker$1.run(Unknown Source at java.base/java.lang.Thread.run(Unknown Source)
HRESULT=0x80010106 means RPC_E_CHANGED_MODE which I guess means that COM is somehow already initialized in MTA mode. But why is this only an issue in the Windows Bridge sandbox? Does the Windows Bridge somehow pre-initialize COM somehow for some reason?
I'm not sure if this is a Java 9 issue, or a Desktop Bridge issue, or both. Does anybody have any ideas on how to identify the cause of the issue or workaround?
I have made a minimal Sample Project to reproduce the issue
The application works when executed directly, but not when executed via the APPX launcher. Why?
Analysis
The JDK parts, that rely on COM being initialized (D3DPipeline, Sound and windows shellfolder access) all follow the same pattern:
the run the code in a separate thread
for this thread CoInitialize is called
at the end of the user level code CoUnitialize is called
This is in line with the documentation the MSDN holds for COM and the analysis is correct, the error indicates, that the COM subsystem is already initialized to be MTA threaded.
So I modified the java launcher (jvm.dll) and inserted
debugging statements into some of the native methods in os_windows.cpp.
I focused on the threading methods. What I found was this:
create_main_thread, create_os_thread, pd_start_thread all
run with COM not yet initialized
the native thread initializer (thread_native_entry) is already
running with COM initialized
I looked more into in _beginthreadex and indeed I finally found a lead
on stackoverflow. That pointed me to the sourcecode of threadex.c,
which is part of the Visual Studio 2013 Express Installation.
There you find, that _beginthreadex does not directly start the
supplied thread function, but runs a library initializer
(_threadstartex) first. Part of this initializer reads:
_ptd->_initapartment = __crtIsPackagedApp();
if (_ptd->_initapartment)
{
_ptd->_initapartment = _initMTAoncurrentthread();
}
_callthreadstartex();
_crtIsPackagedApp detects via a kernel function if the application is
run as a "PackagedApp" (i.e. AppX package) and if so, then the
RoInitialize function is called, which from my understanding acts like the big
brother of CoInitialize.
Long story short: If your application is build with Visual Studio 2013
and run as a packaged application, you get a broken environment.
It was confirmed, that the working versions of the Oracle JDK were build with VS2010 SP1 and the broken version was build with VS2013SP4.
Workaround
With the above information google finally found a reference, that supports the analysis:
https://blogs.msdn.microsoft.com/vcblog/2016/07/07/using-visual-c-runtime-in-centennial-project/
Quote from that article:
Note that the existing VC++ 12.0 libraries created during the
Windows 8 timeframe have runtime checks to determine whether the
app is running under the app container or not. When running
desktop apps as a packaged app, these checks might limit the
functionality of the desktop app or cause it to behave like a UWA
(Universal Windows Application) (limited file system access or
create thread initializing MTA etc.). We have fixed this behavior
in the VC++ libraries contained in these framework packages and
thus removing the modern app limitations from your desktop
applications.
So I see to options to fix applications, that shall be distributed as AppX packages:
either force the users to have the updates VC++ 12.0 binaries installed (by introducing the dependency cited in the blog post) or
replace the msvcr120.dll that is bundled with Java 9 (and I assume also Java 10) with the fixed version from the update packages
I would go with the second version and I tested this. Starting with a clean up-to-date Windows 10 System, I installed JDK 9.0.4, I cloned the supplied testcase, modified it use the locally installed JRE (not the JDK!) and build the appx package. Running this, I reproduced the problem. I then replaced the msvcr120.dll's in the JRE folder of my systems installation with the one contained in the APPX container from:
https://www.microsoft.com/en-us/download/details.aspx?id=53176
Hint: *.appx are just ZIP files with additional signatures, so you can
just rename them and extract the contents.
I rebuild the testcase and it is working as it should (no COM
initialization errors anymore).
I have installed Desktop App Converter from the Windows store.
When I try to run the app (literally just launch it), I get the message:
[Window Title]
C:\Program Files\WindowsApps\Microsoft.DesktopAppConverter_2.0.2.0_x64__8wekyb3d8bbwe\DACTileLauncher.exe
[Content]
C:\Program Files\WindowsApps\Microsoft.DesktopAppConverter_2.0.2.0_x64__8wekyb3d8bbwe\DACTileLauncher.exe
The data area passed to a system call is too small.
I have tried running the Troubleshooter for Windows Apps, it tells me that "Windows Store cache and licenses may be corrupt" and tries to fix them, but running the troubleshooter a second time gives the same issue.
Each time I try to run the Desktop App Converter, I get 2 errors in Event Viewer:
%1: Cannot create the Desktop AppX container for package %2 because an error was encountered configuring the runtime.
%4: Cannot create the process for package %1 because an error was encountered while configuring runtime. %5
... both from AppModel-runtime
Any ideas how I can troubleshoot from here?
If you have problems with the Microsoft DAC you try this new converter, it is much easier to use, it has a GUI (no command line), built-in support for digital signing and allows you to customize the list of files that get inside your AppX.
Also, you can generate AppX packages for applications which do not (cannot) install silently.
It runs on Windows 7 too, not just Windows 10 (recommended).
This is a very strange situation. Why do I get error
CL_PLATFORM_NOT_FOUND_KHR
when I'm calling this function:
clGetPlatformIDs(0, NULL, &platformCount);
Earlier this error was not. I have installed the driver and SDK from Intel and Nvidia. Are there any suggestions?
Here is explained why such error can occur. clGetPlatformIDs returns CL_SUCCESS if the function is executed successfully and there are a non-zero number of platforms available. Otherwise it can return CL_PLATFORM_NOT_FOUND_KHR if the cl_khr_icd extension is enabled and no platforms are found.
You are in luck. Well sort of... Seeing this is 3 years later.
Disclaimer: I HAVE NO CLUE WHY THIS WORKS:
Machine: x64 windows 10.
Graphics Card: Geforce GTX 960
Total Failure To Load Library : LoadLibraryA( "OpenCL64.dll" )
WRONG (but loads) : LoadLibraryA( "C:/Program Files/NVIDIA Corporation/OpenCL/OpenCL64.dll" )
WRONG (but loads) : LoadLibraryA( "C:/Program Files/NVIDIA Corporation/OpenCL/OpenCL.dll" )
CORRECT: LoadLibraryA( "OpenCL.dll" )
Here is the really insideous thing: Both of my "WRONG" answers will let you
grab function pointers, but when you call clGetPlatformIDs the return status
will be 0xFFFFFC17 ( CL_PLATFORM_NOT_FOUND_KHR ).
Then you'll be examining your function call correctness.
Maybe you'll even look at the calling convention. Maybe you'll check
the header files and make sure there are not any typos there. And yet,
you are looking in all the wrong places because the original problem happened
more steps back than you think.
Because of this problem, I build into my programs code that reads a file:
"OPEN_CL_SEARCH_PATHS.TXT" so the user of the software can change what DLL file
the program attempts to load.
While I am here, I would also like to add that there seems to be a bug with the
driver that makes it so OpenCL <==> OpenGL sharing is NOT a zero-copy share and
is incredibly laggy. Now I've got to go figure out Vulkan to make my fractal
rendering engine even though OpenCL's abstraction better suits the problem.
It is probably important to note that I am NOT using an SDK or any
validation layers. In fact, I am not even using
windows.h.
I wrote assembly code to grab the address of GetProcAddress and LoadLibrary by navigating the PEB file. I am also not using cl.h or cl_platform.h.
I reconstruct the structs I need from the documentation. I am also not
bothering with prototypes for function signatures either. For example,
I call "clGetPlatformIDs" by casting it to type "F_03" and then
calling it that way.
typedef void* (F_03)( void, void*, void* );
My machine doesn't have GPU and so had to use hashcat with OpenCL for CPU alone. My machine was Intel core i3, so I have downloaded the OpenCL softwares from Intel website and installed manually and the error gone.
Source: https://youtu.be/AieYqNQ6ADM
I am using Intel DE2i-150 board where I have Intel atom processor with yocto os and fpga with Nios II processor. I am trying to access the fpga board from yocto. Initially I was able to communicate but due to some other installation now the PCIE_open is not working and it is giving me an error: "Counld not open device". This phrase is not anywhere defined in my code. I have used the driver code also but ended up with the same error. Previously it was working. I have no idea what is going on. Please help me regarding this.
It was my mistake. In alt_up_pci_lib.c the device name was alt_up_pci0 and I was trying to open alt_up_pci. That is why the error was coming.
I'm developing an application with openCL on an imx6q (freescale - Vivante gc200 with openCL EP) with a Linux suse 13.1 distribution adapted for armv7.
I'm based on the following tutorial : https://community.freescale.com/docs/DOC-93984#comment-12585. I installed the following package : gpu-viv-bin-mx6q.
When I try the example code, it works on a laptop version, but on the imx6, it gives me a segmentation fault when calling the function clGetDeviceIds.
The program is compiled correctly but not work when running;
I tried by passing different null variables in the function. I'm not sure if it's due to memory allocation (as the same code work on my laptop, i can suppose this is not the problem). When I launch it in debug mode, the program seems not to find the file : "gc_hal_user_query.c" (hal is for Hardware Abstraction Layer).
I can't find sufficient documentation on the web, and i'm quite newbie on linux and openCL, so if anybody could help me. Thanks in advance.
I guess the issue is that, when you call
clGetPlatformIDs(1, &cpPlatform, NULL);
cpPlatform receives 0 if no platform is detected. This leads to a segmentation fault during the next call to
clGetDeviceIDs(cpPlatform, CL_DEVICE_TYPE_GPU, 1, &cdDevice, NULL);
I unfortunately can't help further, I have the same problem.
You are running with insufficient permissions. Try running as root.