I am trying to get a program that will run on both ATI and NVidia, and as such, I want to avoid using either SDK. Is it possible to do this without an SDK, using only VS2010 and Windows (XP or 7)?
If so, how can I go about configuring VS2010 Linker so that it will work?
Strictly speaking, no SDK is needed. In fact, no SDK is desired, as both the NVIDIA and AMD/ATI SDKs tie the code to their environments, and, by extension, their hardware. What you do need is:
1) A GPU that will run OpenCL code. See this Question: List of OpenCl Compliant CPU/GPU
2) The OpenCL library (libOpenCL.so on Linux); this is usually included and installed with the Graphics driver, which may be downloaded from AMD or NVIDIA.
3) The OpenCL header files. These may be obtained from Khronos.org, but are included with all OpenCL SDKs that I am aware of. On a Linux system these typically go in the directory /usr/include/CL
The NVIDIA and AMD SDKs provide a number of utilities and wrappers that make using the OpenCL API easier, but they are not required for writing OpenCL code, or for making API calls. These wrappers and utilities are not poratble. If you're interested in writing portable code, stick to the OpenCL spec, also available from Khronos.org.
To write code, all that you need to do is include opencl.h in your host program, and then make the API calls that are necessary to set up the OpenCL environment and run your OpenCL program. Also, don't forget to link against the OpenCL library (give gcc the -lOpenCL flag under Linux).
OpenCL is a standard. It only defines conventions. To use it, you need a driver for your graphical card. NVidia, AMD (ATI) and Apple all provide such drivers. You definitively need a SDK.
#virtuallinux alludes to the right answer: If you're worried about accidentally using some vendor-specific extensions, get the Khronos SDK.
Related
I have a task on uni starts with setting the visual studio environment to :
OpenCL SDKs:
AMD – AMD APP (Accelerated Parallel Processing)
NVIDIA – CUDA (Compute Unified Device Architecture)
Intel – Intel SDK for OpenCL Applications
OpenCL uses an “Installable Client Driver” (ICD), model
To allow platforms from different vendors to co-exist
Applications can choose a platform at runtime
And I don't know how to do it ..
i need halp and thanks
I checked by running Regedit for the settings but I only found the default
In order to make OpenCL available for pre-compiled programs you simply need to install the Nvidia, AMD or Intel GPU drivers, depending on which GPU you have (not that older Intel integrated GPUs don't support OpenCL).
For CPU OpenCL support you can install the Intel runtime (Intel only) or POCL (open source, all modern CPUs supported, but you need to compile it from source). Unfortunately AMD does not provide APP SDK with CPU support anymore (although a simple web search will still get you the executables).
All of the above automatically register the respective ICD, so you don't have to do anything special about it.
For developing OpenCL applications you need a standalone OpenCL ICD loader (.lib/.a and .dll) and the OpenCL headers (.h), which you can get from those links, though you need to compile the former. These are also provided in ready to use, binary form in OpenCL SDKs such as the ones provided by Intel (which includes Intel's OpenCL CPU runtime) or AMD.
I'm a bit confused about when exactly I need to use an OpenGL function loader like GLEW. In general, it seems like you first obtain a window and valid OpenGL context and then attempt to load functions.
Sometimes these functions are referred to as extensions, sometimes they are called core functions as well. It seems like what's loaded and classified as 'core' and 'extension' is platform dependent. Are the functions that are loaded in addition to some base set?
Do you need to load functions in the same way on OpenGL ES platforms as well? Taking a quick look at GLEW, I don't see any explicit support for Open GL ES. Other GL function loader libs do explicitly mention support specifically for ES however (like https://github.com/Dav1dde/glad)
OpenGL functions (core or extension) must be loaded at runtime, dynamically, whenever the function in question is not part of the platforms original OpenGL ABI (application binary interface).
For Windows the ABI covers is OpenGL-1.1
For Linux the ABI covers OpenGL-1.2 (there's no official OpenGL ABI for other *nixes, but they usually require OpenGL-1.2 as well)
For MacOS X the OpenGL version available and with it the ABI is defined by the OS version.
This leads to the following rules:
In Windows you're going to need a function loader for pretty much everything, except single textured, shaderless, fixed function drawing; it may be possible to load further functionality, but this is not a given.
In Linux you're going to need a function loader for pretty much everything, except basic multitextured with just the basic texenv modes, shaderless, fixed function drawing; it may be possible to load further functionality, but this is not a given.
In MacOS X you don't need a function loader at all, but the OpenGL features you can use are strictly determined by the OS version, either you have it, or you don't.
The difference between core OpenGL functions and extensions is, that core functions are found in the OpenGL specification, while extensions are functionality that may or may be not available in addition to what the OpenGL version available provides.
Both extensions and newer version core functions are loaded through the same mechanism.
datenwolf's answer is great, but I wanted to clarify something you said in the first bullet point of your question.
Core and extension status is not platform-dependent or even mutually exclusive.
Core means that some feature was introduced in a certain version of OpenGL. There are core functions, which are things that are guaranteed to exist in version X.Y and there are even core extensions, which are extensions that were introduced alongside version X.Y. Core extensions provide the same functions, types, enums, etc. as the core feature only in an extension form that does not require a specific version.
Framebuffer Objects went core in OpenGL 3.0, and are slightly less restrictive than the EXT extension (GL_EXT_framebuffer_object) that predates OpenGL 3.0. However, it is not necessary to have an OpenGL 3.0 implementation to have access to the core version of FBOs - an OpenGL 2.1 implementation might offer the core functionality.
In the extension specification for GL_ARB_framebuffer_object, you will find:
Issues
(8) Why don't the new tokens and entry points in this extension have
"ARB" suffixes like other ARB extensions?
RESOLVED: Unlike most ARB extensions, this is a strict subset of
functionality already approved in OpenGL 3.0. This extension
exists only to support that functionality on older hardware that
cannot implement a full OpenGL 3.0 driver. Since there are no
possible behavior changes between the ARB extension and core
features, source code compatibility is improved by not using
suffixes on the extension.
That is the first mention of a core extension that I can recall, but it is not the last. Since then many ARB extensions have been created that "backport" (if you will) core functionality from a higher version.
Here is some sample output gathered by parsing gl.xml for another core extension:
>> Command: void glBufferStorage (GLenum target, GLsizeiptr size, const void *
data, GLbitfield flags)
* Provided by GL_ARB_buffer_storage (gl|glcore)
* Core in GL_VERSION_4_4 ( gl 4.4)
It is core in 4.4 (guaranteed to exist in a 4.4 implementation), but because the extension that provides it is glcore, this core function may be available in older implementations if the core extension is available.
The simple piece of software I wrote to parse gl.xml for this information can be found here if you are interested.
Function loaders are only needed on Windows and Linux. Here's a quick overview of how you build for various OpenGL versions on different platforms.
Windows
The Windows development tools only contain headers for OpenGL 1.1. The conspiracy theorists would probably claim that Microsoft is not interested in making the use of OpenGL easy because it wants developers to use a proprietary API instead.
For anything beyond 1.1, you need to load the entry points dynamically by calling wglGetProcAddress(). Libraries like GLEW provide header files for higher OpenGL versions, and encapsulate the logic for loading the entry points.
Linux
I haven't done OpenGL programming on Linux. From what I hear, it requires function loading similar to Windows. I'll defer to #datenwolf's answer for the details.
Mac OS
Mac OS supports two main OpenGL feature sets:
OpenGL 2.1 with legacy features. This is used by including <OpenGL/gl.h>.
OpenGL 3.x and higher, Core Profile only. Used by including <OpenGL/gl3.h>.
In both cases, you don't need any dynamic function loading. The header files contain all the declarations/definitions for the maximum version that can be supported, and the framework you link against (using -framework OpenGL) resolves the function names.
The maximum version you can use at build time is determined by the platform SDK you build against. By default, this is he platform SDK that matches the OS of your build machine. But you can change it by using the -isysroot build option.
At runtime, the machine has to run at least the OS matching the platform SDK used at build time, and you can only use features up to the version supported by the GPU. You can get an overview of what version is supported on which hardware on:
https://developer.apple.com/opengl/capabilities/
http://support.apple.com/en-us/HT202823
Android, NDK
With native code on Android, you choose the OpenGL version while setting up the context and surface. Your code then includes the desired header (like <GLES2/gl2.h> or <GLES3/gl3.h>) and links against the matching libraries. There is no dynamic function loading needed.
If the target device does not support the version you are trying to use, the context creation will fail. You can have an entry in the manifest that prevents the app from being installed on devices that will not support the required ES version.
Android, Java
This is very similar to the NDK case. The desired version is specified during setup, e.g. while creating a GLSurfaceView.
The GLES20 class contains the definitions for ES 2.0. GLES30 derives from GLES20, and adds the additional definitions for ES 3.0.
iOS
Not surprisingly, this is very similar to Mac OS. You include the header file that matches the desired OpenGL ES version (e.g. <OpenGLES/ES3/gl.h>), link against the framework, and you're all done.
Also matching Mac OS, the maximum version you can build against is determined by the platform SDK version you choose. Devices you want to run on then have to use at least the OS version that matches this platform SDK version, and support the OpenGL ES version you are using.
One main difference is obviously that you cross compile the app on a Mac. iOS uses a different set of platform SDKs with different headers and frameworks, but the overall process is pretty much the same as building for Mac OS.
I have an intel i7 haswell cpu, and I would like to start exploring OpenCL development. In particular, I am interested to run OpenCL code on the integrated GPU.
Unfortunately, by now, I was not able to find any SDK on Intel's site..
May you provide some links, together with a summary of the current status of OpenCL tools for the Linux platform and Intel hardware?
I think this would be useful to many other people..
Thanks a lot!
Intel does not provide free support for OpenCL on their iGPUs under Linux - you have to buy the Intel Media Server Studio, minimum $499. On Windows, you can download a free driver to get OpenCL capability for the iGPU: https://software.intel.com/en-us/articles/opencl-drivers#philinux.
Note that you can use any OpenCL SDK you want - it doesn't have to be Intel. The SDK is only useful for building your program. For running an OpenCL program, you need an appropriate runtime (driver) from the manufacturer. The AMD SDK will give you access to the CPU as an OpenCL device, but not the iGPU.
There is Open Source OpenCL implementation for Intel GPUs on Linux called Beignet, maintained by bunch of guys from Intel.
Sadly, couldn't personally try and check if Your's GPU is properly supported, but on their wiki they states:
Supported Targets
4th Generation Intel Core Processors "Haswell", need kernel patch currently, see the "Known Issues" section.
Beignet: self-test failed" and almost all unit tests fail. Linux 3.15 and 3.16 (commits f0a346b to c9224fa) enable the register whitelist by default but miss some registers needed for Beignet.
This can be fixed by upgrading Linux, or by disabling the whitelist:
# echo 0 > /sys/module/i915/parameters/enable_cmd_parser
On Haswell hardware, Beignet 1.0.1 to 1.0.3 also required the above workaround on later Linux versions, but this should not be required in current (after 83f8739) git master.
So, it's worth a shoot. Btw, it worked well on my 3rd generation HD4000.
Also, toolchain and driver in question includes bunch of GPU-support test cases.
For anyone who comes across this question as I did, the existing answers have some out-of-date information; Intel now offers free drivers for Linux on the site posted above: https://software.intel.com/en-us/articles/opencl-drivers#philinux
The drivers themselves are only supported on 5th, 6th and 7th gen Core processors (and a bunch of other Celerons and Xeons, see link), with earlier processors such as 4th gen still needing the Media Server Studio.
However, they now offer a Linux Community version of Media Server Studio which is free to download.
They also have a Driver Support Matrix for Intel Media SDK and OpenCL which has some useful information about compatibility: https://software.intel.com/en-us/articles/driver-support-matrix-for-media-sdk-and-opencl
You may check intel open source Beignet OpenCL library: http://arrayfire.com/opencl-on-intel-hd-iris-graphics-on-linux/
For me (ubuntu 15.10 + Intel i5 4th generation GPU) it works quite well.
P.S.
Also I must say that I managed to download "media server" for linux a couple of months ago (but didn't used it yet). So you may check it also.
I'm a bit confused about when exactly I need to use an OpenGL function loader like GLEW. In general, it seems like you first obtain a window and valid OpenGL context and then attempt to load functions.
Sometimes these functions are referred to as extensions, sometimes they are called core functions as well. It seems like what's loaded and classified as 'core' and 'extension' is platform dependent. Are the functions that are loaded in addition to some base set?
Do you need to load functions in the same way on OpenGL ES platforms as well? Taking a quick look at GLEW, I don't see any explicit support for Open GL ES. Other GL function loader libs do explicitly mention support specifically for ES however (like https://github.com/Dav1dde/glad)
OpenGL functions (core or extension) must be loaded at runtime, dynamically, whenever the function in question is not part of the platforms original OpenGL ABI (application binary interface).
For Windows the ABI covers is OpenGL-1.1
For Linux the ABI covers OpenGL-1.2 (there's no official OpenGL ABI for other *nixes, but they usually require OpenGL-1.2 as well)
For MacOS X the OpenGL version available and with it the ABI is defined by the OS version.
This leads to the following rules:
In Windows you're going to need a function loader for pretty much everything, except single textured, shaderless, fixed function drawing; it may be possible to load further functionality, but this is not a given.
In Linux you're going to need a function loader for pretty much everything, except basic multitextured with just the basic texenv modes, shaderless, fixed function drawing; it may be possible to load further functionality, but this is not a given.
In MacOS X you don't need a function loader at all, but the OpenGL features you can use are strictly determined by the OS version, either you have it, or you don't.
The difference between core OpenGL functions and extensions is, that core functions are found in the OpenGL specification, while extensions are functionality that may or may be not available in addition to what the OpenGL version available provides.
Both extensions and newer version core functions are loaded through the same mechanism.
datenwolf's answer is great, but I wanted to clarify something you said in the first bullet point of your question.
Core and extension status is not platform-dependent or even mutually exclusive.
Core means that some feature was introduced in a certain version of OpenGL. There are core functions, which are things that are guaranteed to exist in version X.Y and there are even core extensions, which are extensions that were introduced alongside version X.Y. Core extensions provide the same functions, types, enums, etc. as the core feature only in an extension form that does not require a specific version.
Framebuffer Objects went core in OpenGL 3.0, and are slightly less restrictive than the EXT extension (GL_EXT_framebuffer_object) that predates OpenGL 3.0. However, it is not necessary to have an OpenGL 3.0 implementation to have access to the core version of FBOs - an OpenGL 2.1 implementation might offer the core functionality.
In the extension specification for GL_ARB_framebuffer_object, you will find:
Issues
(8) Why don't the new tokens and entry points in this extension have
"ARB" suffixes like other ARB extensions?
RESOLVED: Unlike most ARB extensions, this is a strict subset of
functionality already approved in OpenGL 3.0. This extension
exists only to support that functionality on older hardware that
cannot implement a full OpenGL 3.0 driver. Since there are no
possible behavior changes between the ARB extension and core
features, source code compatibility is improved by not using
suffixes on the extension.
That is the first mention of a core extension that I can recall, but it is not the last. Since then many ARB extensions have been created that "backport" (if you will) core functionality from a higher version.
Here is some sample output gathered by parsing gl.xml for another core extension:
>> Command: void glBufferStorage (GLenum target, GLsizeiptr size, const void *
data, GLbitfield flags)
* Provided by GL_ARB_buffer_storage (gl|glcore)
* Core in GL_VERSION_4_4 ( gl 4.4)
It is core in 4.4 (guaranteed to exist in a 4.4 implementation), but because the extension that provides it is glcore, this core function may be available in older implementations if the core extension is available.
The simple piece of software I wrote to parse gl.xml for this information can be found here if you are interested.
Function loaders are only needed on Windows and Linux. Here's a quick overview of how you build for various OpenGL versions on different platforms.
Windows
The Windows development tools only contain headers for OpenGL 1.1. The conspiracy theorists would probably claim that Microsoft is not interested in making the use of OpenGL easy because it wants developers to use a proprietary API instead.
For anything beyond 1.1, you need to load the entry points dynamically by calling wglGetProcAddress(). Libraries like GLEW provide header files for higher OpenGL versions, and encapsulate the logic for loading the entry points.
Linux
I haven't done OpenGL programming on Linux. From what I hear, it requires function loading similar to Windows. I'll defer to #datenwolf's answer for the details.
Mac OS
Mac OS supports two main OpenGL feature sets:
OpenGL 2.1 with legacy features. This is used by including <OpenGL/gl.h>.
OpenGL 3.x and higher, Core Profile only. Used by including <OpenGL/gl3.h>.
In both cases, you don't need any dynamic function loading. The header files contain all the declarations/definitions for the maximum version that can be supported, and the framework you link against (using -framework OpenGL) resolves the function names.
The maximum version you can use at build time is determined by the platform SDK you build against. By default, this is he platform SDK that matches the OS of your build machine. But you can change it by using the -isysroot build option.
At runtime, the machine has to run at least the OS matching the platform SDK used at build time, and you can only use features up to the version supported by the GPU. You can get an overview of what version is supported on which hardware on:
https://developer.apple.com/opengl/capabilities/
http://support.apple.com/en-us/HT202823
Android, NDK
With native code on Android, you choose the OpenGL version while setting up the context and surface. Your code then includes the desired header (like <GLES2/gl2.h> or <GLES3/gl3.h>) and links against the matching libraries. There is no dynamic function loading needed.
If the target device does not support the version you are trying to use, the context creation will fail. You can have an entry in the manifest that prevents the app from being installed on devices that will not support the required ES version.
Android, Java
This is very similar to the NDK case. The desired version is specified during setup, e.g. while creating a GLSurfaceView.
The GLES20 class contains the definitions for ES 2.0. GLES30 derives from GLES20, and adds the additional definitions for ES 3.0.
iOS
Not surprisingly, this is very similar to Mac OS. You include the header file that matches the desired OpenGL ES version (e.g. <OpenGLES/ES3/gl.h>), link against the framework, and you're all done.
Also matching Mac OS, the maximum version you can build against is determined by the platform SDK version you choose. Devices you want to run on then have to use at least the OS version that matches this platform SDK version, and support the OpenGL ES version you are using.
One main difference is obviously that you cross compile the app on a Mac. iOS uses a different set of platform SDKs with different headers and frameworks, but the overall process is pretty much the same as building for Mac OS.
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.