I am using Nvidia GPU Computing toolkit on Windows 7 x64 with the 64 bit Cygwin package and Eclipse. (I use the internal build tools because GNU make doesn't lik colons in Windows paths.) My code:
Here's the fairly basic piece of code:
#include
#include
using namespace std;
int main() {
cl_int error = 42;
cl_platform_id platform;
error = clGetPlatformIDs(1, &platform, NULL);
return 0;
}
C++ code both compiles and runs fine, and I can use OpenCL headers and cl_int and cl_device_id, but with clGetPlatformID I get the following compile error:
relocation truncated to fit: R_X86_64_32 against symbol
'__imp_clGetPlatformIDs' defined in .idata$5 section in
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v6.0\lib
\x64/OpenCL.lib(OpenCL.dll.b)
I have tried the following:
Uninstall/reinstall Cygwin tools
Uninstall/reinstall both 32 and 64 bit libraries in the Nvidia GPU Computing toolkit
Uninstall/reinstall Eclipse and checked most settings
Avoiding 32 bit memory restrictions by adding "-mcmodel=medium" or "-mcmodel=large". (According to searches, at some point 32 and 64 bit binaries are being mixed.)
Confirmed that I am only using 64 bit Nvidia libraries and Cygwin tools.
My guess is that the internal builder is to blame, but using it was the solution to another problem that caused the build to fail.
I've got a bit of an update on this:
Wiped and re-installed pretty much everything (CUDA toolkit, Cygwin, Eclipse) and it still gives me the same error even with the appropriate flags (which I used before Captain Obvious linked to a post suggesting it).
The progress I've made is that I've probably zeroed in on where the problem actually lies. Using relative paths solved the issues with GNU make not being able to deal with colons in paths. This basically clears the Eclipse internal builder. However I've got almost the exact same setup working on another machine, the differences being that this setup has an AMD card and thus uses the AMD App SDK rather than Nvidia's OpenCL toolkit.
My suspicion is that this might be a bug brought on by the recent released version 6.0 of the CUDA toolkit as it introduces some pretty major upgrades like unified memory and they might not have tested it so well without the NSight Visual Studio-plugin. After all they do recommend that you develop using Visual Studio with that plugin and I don't have (legal) access to Visual Studio right now.
Edit: I've pretty now much confirmed it... Installed the AMD App SDK on the Nvidia GPU machine and it runs flawlessly, so seems like Nvidia has actually fucked up OpenCL in version 6 of the CUDA Toolkit. Thou knowing that they're in competition with OpenCL trough CUDA i hardly find this surprising.
I had the same error, finally I have solved this problem and the latest what I have done is:
1) In cygwin install all packages containing opencl in name.
2) Next, in ...\cygwin\etc\OpenCL\vendors\ (I have found pocl.icd there) create nvidia.icd and place there one string "/cygdrive/c/Windows/System32/nvopencl.dll". The similar actions can be done for Intel OpenCL driver.
3) Finally do not make mistakes (as I did) in CMake file. Example of working code:
cmake_minimum_required(VERSION 3.6)
set(MODULE_NAME opencl-test)
project(${MODULE_NAME})
set(CMAKE_CXX_STANDARD 14)
find_package(OpenCL)
# set include directories
include_directories(${OpenCL_INCLUDE_DIRS})
# set source files
set(SOURCE_FILES main.cpp)
add_executable(${MODULE_NAME} ${SOURCE_FILES})
# linking
target_link_libraries(${MODULE_NAME} ${OpenCL_LIBRARY})
Related
I am trying to write Open CL programs in C++ using G++ compiler in Windows 10 but I am not able to find any SDK for my work.
Nvidia CUDA requires Visual Studio compilers to work and AMD AMP SDK seems to be discontinued saying that the libraries are included in the driver itself.
My PC has both AMD and Nvidia GPUs so any of the implementation should be fine with OpenCL. Can anyone suggest how can I carry on and also kindly clarify on how to use the libraries present in OpenCL driver in my C++ program as mentioned by AMD if possible?
Edit :
I found out that OpenCL libraries are already present in Windows as,
C:\Windows\System32\OpenCL.dll
We only need headers to compile our program using g++. It can be done as shown below.
Install OpenCL headers from below,
https://packages.msys2.org/package/mingw-w64-x86_64-opencl-headers
Once headers are present in include directory of MinGW64, I wrote my program normally and compiled the program using the below g++ command.
g++ main.cpp C:\Windows\System32\OpenCL.dll -o main.exe
And that's it. It worked !!!
http://arkanis.de/weblog/2014-11-25-minimal-opencl-development-on-windows was of great help to understand the OpenCL library implementation in Windows.
You don't need to install anything besides Visual Studio Community with the C++ compiler, and GPU drivers (these already contain the OpenCL runtimes).
For OpenCL development, you only need the OpenCL header files and the lib file. To setup Visual Studio, see here. This works for any OpenCL device, including Nvidia/AMD/Intel GPUs and even Intel CPUs if the CPU runtime is installed.
Alternatively, you can use my lightweight OpenCL-Wrapper. This comes with all Visual Studio settings already in the project file. OpenCL learning and developing with the wrapper is so much simpler than with the cumbersome OpenCL bindings directly.
I'd really appreciate some help getting HElib to work on Windows 10 x64 using the MSVC 2017 compiler. I successfully managed to compile its dependency, NTL, using the same compiler by following this tutorial and also ran its tests, so it seems to work well.
However, in the case of HElib I tried generating Visual Studio projects using cmake and then compiled it successfully (see NOTE below), but running it fails. For example, I ran the Test_binaryCompare.cpp_exe test (has its own vcproj generated by cmake), but it fails because it reaches a part of code I doubt it's supposed to (it attempts to do an operation called bootstrapping and it is disabled for that test). However, on Linux it works.
LINUX: The reason I'd really like to run this on Windows is because I find it a lot easier to debug using Visual Studio. I'm also more used to Windows overall..
NOTE: Compiling HElib successfully required some modifications like fixing broken tr1 includes (e.g it was trying to include <tr1/memory> instead of just memory although the latter was actually available), suppressing the 4146 error (I also had to do this for NTL) and fixing two instances of variable-length arrays which Microsoft's compiler sadly does not support.
Without any error messages I can't really help you figure out your exact issues but I ported HElib to Windows some time ago: https://github.com/AlexanderViand/HElib/tree/Windows
It's a bit out of date but if the tests works in that version you can check the changes I made against your changes.
There's also the option that you're simply running into this issue: https://github.com/shaih/HElib/issues/228
If your linux version of NTL is slightly older, it might just be that your windows version of NTL is the buggy one.
Finally, I'd very much recommend against running HElib on Windows because without GMP it seems painfully slow.
Instead I ended up setting up a docker virtual machine and SSH'd into that from visual studio: https://hub.docker.com/r/alexanderviand/visual-studio-linux-build-box-with-helib/
Currently I'm using WSL and CLion (which supports WSL quite well) when I'm working with HElib on Windows.
I'm trying to build a simple application with CUDA and I've been trying for hours on end and I just can't make it work on windows. nvcc absolutely refuses to compile without Visual Studio's compiler which doesn't support things I need. I tried building using nvcc with clang but It just asks me to use Visual Studio's compiler. I've also tried using clang directly since it now supports CUDA but I receive this error:
clang++.exe: error: Unsupported CUDA gpu architecture: compute_52
This makes no sense to me because I have the CUDA toolkit version 7.5 and my graphics card is a GTX 970 (two of them). I have googled this extensively and everywhere I come across the error the person always has is their CUDA toolkit is < 7.5. I'm on the brink of tears right now trying to get something as simple as VLA to work on this CUDA application and I just can't achieve it...
The CUDA windows toolchain requires the Visual Studio C++ compiler. You cannot use anything else on that platform. If the VS compiler doesn't support the language features you need within CUDA host code, you have no choice but to change platforms, or your expectations.
You can still potentially compile non-CUDA host code using another compiler and then link that code using NVCC and the VS toolchain.
Try to use clang-cl, --cubin=clang-cl.exe
It may be worth to work on a Linux VM or WSL2 within windows. As per the CUDA docs.
To compile new CUDA applications, a CUDA Toolkit for Linux x86 is
needed. CUDA Toolkit support for WSL is still in preview stage as
developer tools such as profilers are not available yet. However, CUDA
application development is fully supported in the WSL2 environment, as
a result, users should be able to compile new CUDA Linux applications
with the latest CUDA Toolkit for x86 Linux.
https://docs.nvidia.com/cuda/wsl-user-guide/index.html#:~:text=However%2C%20CUDA%20application%20development%20is,becomes%20available%20within%20WSL%202.
I've built OpenCV 2.4.8 in the past with the regularly distributed mingw32, but since I'm migrating to use newer C++11 standard functions and OpenCV3 formats and functionalities, I had to change my compiler to mingw32-builds.
It certainly supports the C++11 functions I want to use, but I can't compile OpenCV3 properly.
Some other questions suggested two approaches
Disabling WITH_IPP during CMake
Commenting out add_extra_compiler_option(-Werror=non-virtual-dtor) in the CMake configuration file
Although making these modifications made it compile, IPP is a performance enhancing library and that warning message is a high level warning which may lead to future bugs.
Is there anyway to compile OpenCV3.0.0 without these quirks?
Additional information:
I've already compiled the exact same build on Ubuntu and everything (from c++11 to opencv3) went fine, no errors, no high level warnings, no quirks
I am now working under Windows 8.1 64-bit, but focused on compiling 32-bit binaries (for compatibility)
I have a computer that has an Intel CPU and an NVIDIA GPU, running Windows 7. I have a software module that is written in NVIDIA CUDA, and another module written in OpenCL. I would like to run the OpenCL module on the CPU, using the Intel implementation of OpenCL, and at the same time, use the CUDA module.
In my system I installed first the CUDA SDK, and then the SDK from Intel.
I've compiled the program in Visual Studio 2012, instructing the linker to use the Intel's library (and I compiled against the OpenCL headers provided by intel).
However when I run a simple program to query the hardware I'm only able to see the NVIDIA card.
I've tried modifying the Windows Registry, and the PATH variable, with no look. When I query the dependencies with "Dependecy Walker" I see that the program depends on a dll located in c:\windows\system32, which is not the folder where the Intel dll is. I've tried deleting this dll but I still see this dependency, and I'm only able to access the GPU.
Any idea about what could be happening?
On Windows, "OpenCL.dll" is the ICD provided by Khronos and redistributed by AMD, NVIDIA and Intel.
The actual drivers are referenced by the Registry, and the ICD enumerates them all.
When you query the OpenCL platforms, you'll see one for each installed driver (AMD, NVIDIA, Intel).
Within each platform there will be devices (or device), for example, in the NVIDIA platform you'll find your NVIDIA GPU and under the Intel platform you'll find your CPU.
Don't replace OpenCL.dll
Run clinfo or GPU-Z to see what OpenCL platforms and devices it sees.
Re-install the Intel CPU driver (a new one was just posted 2 days ago) to make sure their driver is installed.
Note: Your CPU needs to have SSE 4.2 for the Intel CPU driver to work.
You could try the Installable Client Driver (ICD) Loader. However, I have no experience if it works on Windows.
Or:
Since you don't want to use the GPU with OpenCL you can simply copy the Intel OpenCL.dll into your working directory. The working directory is visited first when .dlls are loaded. So, even if the Nvidia OpenCL.dll is installed into your windows/system32 directory the Intel library is found first and therefore loaded. There may be better solutions maybe load the dll on demand as discussed here Dynamically load a function from a DLL but as a fast solution it should work.