My application is OpenCL 1.1 compatiable and I want to check whether each of the device has drivers for that version. There are 2 ways for this:
clGetDeviceInfo() ->CL_DEVICE_VERSION
clGetPlatformInfo() ->CL_PLATFORM_VERSION
I have following doubts:
I do not understand why method 1 is provided as method 2 seems the
correct way to me?
Is it possible that the version given by the platform will not
match with the version given by a device from the same platform?
What is clGetDeviceInfo::CL_DRIVER_VERSION for?
From all these options which one should I use to check if a device
can run my OpenCL 1.1 code?
There are some features in OpenCL that have hardware requirements. This means that even if a particular vendor's OpenCL implementation (the platform) supports an OpenCL version, the device might not. So, it is entirely possible for the versions returned from the CL_DEVICE_VERSION and CL_PLATFORM_VERSION queries to differ.
This will probably start to happen more frequently when OpenCL 2.0 implementations start appearing, as there is plenty of hardware on the market that doesn't have the necessary support for OpenCL 2.0 features. Imagine a system that has two devices from Vendor X: a new Device A that can run OpenCL 2.0, and a much older Device B that can't. In this instance, the platform version may be OpenCL 2.0, but the device version could be OpenCL 2.0 for Device A and OpenCL 1.2 for Device B.
The CL_DRIVER_VERSION is for getting a vendor specific version number for the implementation. This number could using any version numbering system that the vendor uses to keep track of different software releases, and is completely independent from OpenCL version numbers (although some vendors may well include the OpenCL version here too).
So, in order to be sure that both the device and platform support your required OpenCL version, you should just need to check CL_DEVICE_VERSION.
Related
Specifically, I have single platform version 2.1 with single device version 2.0 and I want to use C++14 features which supported only in OpenCL 2.1. Should I be able to? What matters when it comes to capabilities limitation: platform or device? What's even the point of platform version since it always comes down to using device anyway?
What's even the point of platform version since it always comes down to using device
anyway?
Platform = version of the codebase and API etc.
Device = Capabilities of the hardware.
The sense is that a platform update may change the way you write your code USING the API, while the device capabilities may change with the hardawre chip.
I need to implement a truly working platform version filter targeted to version 1.2 for my open-source project:
https://github.com/tugrul512bit/Cekirdekler
I don't have 150$ to buy an OpenCL2.0 capable graphics card for now so I'm working on a pure-1.2 version system and not sure about other (new)systems.
Question: How does a list of platforms looks like when there are only opencl 2.0 capable gpus and both 1.2(max) and 2.0(max) capable gpus exist in same system?
Lets assume I'm using this
clGetPlatformIDs()
to get a list. Should I suppose it gives only single version platforms per device or,
For example, a GTX-Titan XP(opencl 2.0 capable?) can list two platforms:
OpenCL 1.2
OpenCL 2.0
separately for same device? Or it just gives 2.0 version?
What about a GTX-TitanXP and a GT-640?
OpenCL 1.2 (TitanXP + GT-640)
OpenCL 2.0 (TitanXP)
or
OpenCL 2.0 (TitanXP)
OpenCL 1.2 (GT-640)
which one happens?
Can this change with drivers?
What about OpenCL version 2.3 GPUs? Do they seem as 2.0 in OpenCL API or correctly give 3 as minor version?
If anyone could share his/hers experience, I appreciate.
For now, project can take 1.2 or 2.0 versions (Intel drivers I installed have an experimental version 2.1 with bugs so I filter-out with minor version checking, I'm not sure if Nvidia or Amd can do similar or opposite things in OpenCL-2.x capable cards). I can also filter for platform names "experimental"/"beta" to elliminate such platforms but I'm not sure if there are multiple versions for same GPUs.
I assume 2.0 devices have backwards compatilibity for 1.2 but do I need anything extra to enable 1.2 spec? For now I'm not doing anything extra for 1.2 devices. Maybe 2.0 needs some?
Each platform returns its own version number independently of the others. You can have a mix, for example a GPU at 1.2 and a CPU driver at 2.0.
If you make only OpenCL 1.2 API calls you can use either. If you make OpenCL 2.0 API calls you can only use 2.0 or higher platforms.
Likewise, devices within a platform can return their own version numbers, although I don't think they can be larger than their parent platform number. An example of this is an older GPU, which might only be OpenCL 1.1 even though the platform is 1.2.
Separate from this is the version of OpenCL kernel language each device supports. For backwards compatibility if you don't pass compile options you are getting OpenCL C 1.x. If you are on a 2.x device you can pass an option string when compiling your kernel to get new language features.
I wonder how we can have OpenCl "seeing" my K20. Xeon, and Xeon Phi at the same time?
Especially I'm confused about the use of two libraries here (from NVidia and Intel).
How to do it, if possible at all?
The OpenCL Installable Client Driver (ICD) takes care of this for you. It is the same regardless of whose implementation you have installed, and exposes all implementations as separate OpenCL "Platforms".
When you call clGetPlatformIDs it will tell you how many platforms you have installed. There could be one for AMD, one for NVIDIA, and one for Intel, for example.
Then within each platform you call clGetDeviceIDs which will return the number of devices within that platform. On your NVIDIA platform you'll find your K20, and within your Intel platform you'll find your Xeon CPU and Xeon Phi co-processor.
If you build or download the clInfo utility you'll see a nice dump of all the installed platforms and devices and the capabilities of each.
The problem is solved.
Looking at the key directory:
/etc/OpenCL/vendors/*.icd
I noticed that for Nvidia the library in used was a link which was duplicated in difference places and pointing to two different releases.
I just replace the former one by the most recent one, the one I've installed recently, and here we go.
Opencl did not know which one to use I guess.
It's like the installation location has changed between the two nividia versions.
When I was supposed to have removed it before reinstalling that was actually not true.
Thank you all for your hell.
In my computer with Windows 7 OS I have three versions of OpenCL SDKS's from this vendors:
Intel
NVIDIA
AMD.
I build my application with each of them.
As the output I have three different binaries.
For example: my_app_intel_x86, my_app_amd_x86, my_app_nvidia_x86
This binaries are different on this:
They use different SDK's in likange process
They try to find different OpenCL platform name in runtime
Can I use only one SDK and check platform on running time?
SDK's give debuggings tools, a platform, and possibly extensions, the OpenCL API remains the same regardless. You can link to any SDK you want, and it'll produce an executable compatible with any OpenCL runtimes you can find. Remember those are SDK's, meant for the developer - the end-user will probably only have his graphics driver (OpenCL-enabled) which doesn't care what SDK you used to build the software.
Ideally you should use a default platform for your program, but let the user override it (you can select various platforms at runtime!). You can also use heuristics to figure out which device is the fastest, e.g.:
iterate over each available platform
for each platform, iterate over each device
benchmark this device somehow in a relevant way
select the fastest one
Also, if you are using specific extensions, make sure to only accept devices which support them...
Can I use only one SDK and check platform on running time?
Yes, you absolutely can and should do that, but I am worried about what you mean by "check platform" - as I stated above, the SDK bears absolutely no influence on the platforms you can run your built program on. I can build my code with the AMD SDK, and run the executable on a system with an nVidia graphics card or an Intel processor just fine (the only difference is that I may not have access to AMD-specific extensions which will be provided by my SDK, but the extensions will be recognized by an AMD driver, so you don't even need the SDK installed to run the code - but you will to build it though).
I have a system with an NVidia graphics card and I'm looking at using openCL to replace openMP for some small on CPU tasks (thanks to VS2010 making openMP useless)
Since I have NVidia's opencl SDK installed clGetPlatformIDs() only returns a single platform (NVidia's) and so only a single device (the GPU).
Do I need to also install Intel's openCL sdk to get access to the CPU platform?
Shouldn't the CPU platform always be available - I mean, how do you NOT have a cpu?
How do you manage to build against two openCL SDKs simultaneously?
You need to have a SDK which provides interface to CPU. nVidia does not, AMD and Intel's SDKs do; in my case the one from Intel is significantly (something like 10x) faster, which might due to bad programming on my part however.
You don't need the SDK for programs to run, just the runtime. In Linux, each vendor installs a file in /etc/OpenCL/vendors/*.icd, which contains path of the runtime library to use. That is scanned by the OpenCL runtime you link to (libOpenCL.so), which then calls each of the vendor's libs when querying for devices on that particular platform.
In Linux, the GPU drivers install OpenCL runtime automatically, the Intel runtime is likely to be downloadable separately from the SDK, but is part of the SDK as well, of course.
Today i finally got around to trying to start doing openCl development and wow... it is not straight forward at all.
There's an AMD sdk, there's an intel sdk, there's an nvidia sdk, each with their own properties (CPU only vs GPU only vs specific video card support only perhaps?)
There may be valid technical reasons for it having to be this way but i really wish there was just one sdk, and that when programming perhaps you could specify GPU / CPU tasks, or that maybe it would use whatever resources made most sense / preformed best or SOMETHING.
Time to dive in though I guess... trying to decide though if i go CPU or GPU. I have a pretty new 4000$ alienware laptop with SLI video cards, but then also an 8 core cpu so yeah... guess ill have to try a couple sdk's and see which preforms best for my needs?
Not sure what end users of my applications would do though... it doesnt seem like they can flip a switch to make it run on cpu or gpu instead.
The OpenCL landscape really needs some help...