I have downloaded and installed AMD APP SDK 3.0. When I try using it with mingw I get an error because CL/cl.hpp has #include <intrin.h> in it (this header is exclusive to VC++).
Is there a different set of header files for mingw? How do I fix it?
I use both MSVC and MinGw 5.3.0 (bundled with QtCreator) to build OpenCL apps on both Intel and AMD Windows 10 systems using AMD APP SDK 3.0 and I have never experienced a build problem that wasn't in my own code!
However, I use the standard C CL/cl.h header file, not the C++ CL/cl.hpp header file...
The cl.hpp and cl2.hpp files provide C++ bindings for the standard C functions, see OpenCL C++ Bindings. If you don't require C++ bindings, the AMD APP SDK 3.0 CL/cl.h header file works fine.
If you want to use C++ Bindings then note that cl.hpp is obsolete; you should use cl2.hpp instead (which doesn't try to include intrin.h unless _MSC_VER is defined)...
An alternative OpenCL C++ binding (that also compiles with MinGw and AMD APP SDK 3.0) is boost compute.
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'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.
As i have already programmed with opengl on java I tried to switch to c++ using Visual Studio 2015 Community
I currently have opengl version 4.5 installed (cout << glGetString(GL_VERSION))
I normally have included all libraries I need for programming but for some reason there is no "glGenVertexArrays" and "glGenBufferArrays" available
Could it be that I forgot a library?
On windows, the default header files and libs do only support OpenGL 1.1. When you want to use a higher version, you have to load the extensions manually or use an extension loading library like glew (which I would recommend).
I was trying to use the boost library first time. Using as an environment Eclipse 4.3 with CDT and as compiler gcc 3.4 and boost 1.53.
I was browsing various sites to find info on how to setup boost, but it doesn't seem to work. When I compile trying to include boost/asio.hpp I get the error:
You must add -D__USE_W32_SOCKETS to your compiler options
However, I don't want to use windows sockets, I want to use posix, so I don't really know what is wrong. As I need the project to run on HP-UX later, I dont want to get to Windows specific. If I use now windows sockets will the program later be easily portable to Unix, or are all the details encapsulated in boost, and I don't have to care anyway?
I tested a simple testprogram using FOREACH loop to confirm that boost itself works, and this is the case.
I also found this: https://svn.boost.org/trac/boost/ticket/7881 so does it mean that this problem is currently currently not supported, or am I doing something wrong?
It seems what you're trying to do is not supported by the library, the documentation states the following under supported platforms
The following platforms and compilers have been tested:
Win32 and Win64 using Visual C++ 7.1 and Visual C++ 8.0.
Win32 using MinGW.
Win32 using Cygwin. (__USE_W32_SOCKETS must be defined.)
Linux (2.4 or 2.6 kernels) using g++ 3.3 or later.
Solaris using g++ 3.3 or later.
Mac OS X 10.4 using g++ 3.3 or later.
added emphasis is mine. If that's not possible, you might try the patch suggested in the linked ticket. However, grepping through the source code I see several occurrences of #if !defined(BOOST_WINDOWS) && !defined(__CYGWIN__) so it's not obvious that simply patching io_service.hpp will resolve anything. You might try adding -U__CYGWIN__ to your CXXFLAGS, though the cygwin toolchain may not like that.
Full disclosure: I am not a Windows guy so hopefully someone else will chime in.
The libboost-devel package in the Cygwin distribution includes patches to not use Winsock on Cygwin in Boost.Asio. I suggest trying that in conjunction with the gcc4 packages, which provide more recent versions of GCC.
Using the AMD C++ binding and SDK (the most recent one) running an OpenCL program that gets a platform, a GPU, then compiles 4 kernels has the above error upon startup. It works fine on my computer, whose GPU only supports up to 1.1, but other computers seem to have the above error. Is this a problem in the compilation (As in, I have to define some macros), in the lack of a driver, the C++ binding, or something else? I don't explicitly call clRetainDevice in my own code—is it part of the binding somewhere?
It happens when you use the C++ bindings header file with OpenCL 1.2 header. For instance, when you run an application compiled with AMD SDK (OpenCL 1.2) on NVIDIA platform (OpenCL 1.1 only).
As fast and dirty work around, you can just edit the AMD SDK cl.h header and undef "CL_VERSION_1_2" preprocessor symbol. If you are not interested to 1.2 features, it should fix your problem.