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.
Related
What is the difference between Qt versions with dynamic and desktop OpenGL? http://tver-soft.org/qt64
It is likley that this refers to the configure option that was set when they compiled Qt.
This option is explained in detail here: https://blog.qt.io/blog/2014/11/27/qt-weekly-21-dynamic-opengl-implementation-loading-in-qt-5-4/
To summarise, Qt can be compiled to use ether the desktop OpenGL (a direct interface to the graphics driver provided OpenGL version) or to use Angle (a version of OpenGL that uses directX to provide hardware GL support).
Using 'desktop' gives you the latest (and deprecated) OpenGL features where available, but some drivers do not work properly.
Qt now relies on OpenGL to do important 2D rendering and can be badly affected by faulty drivers. For this reason you have the safer option of Angle, safer but limited to OpenGL ES 2.0 functionality.
Dinamic is a new option that will select between them automatically at runtime on the user's machine. It does however mean that you will need to use the Qt OpenGL API (rather than e.g. GLEW) to access OpenGL.
If you are not going to use OpenGL directly in your code then you should chose dynamic.
You should also consider compiling the code for yourself, as you are trusting your and your user's security to tver-soft.org. Even without malicious intent these files may be a security risk.
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.
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...
I have to develop an application which requires Bluetooth and profile change functionality for Symbian phones. After spending sometime I found that following options:
Java: but java does not allow to change profile
Symbian C++: I read basics for Symbian C++ and created some basic stuffs. Symbian extended APIs provide simple APIs for Profile and Bluetooth (I haven't tested yet). But its required lot of efforts to grab these. Specially certificate singing problem. I want to test my application on different devices and wish to give my friends whom having different cellphones. But couldn't due to signing problem.
QT: I am still confused on this. Whether this platform capable to fulfill my requirement or not. Secondly which phone supports QT or not...
Honestly, I am bit frustrated while writing this. I am looking someone, experience in these matter, to guide me in this situation.
You can combine native C++ with Qt. Though you'll lose some of the cross-platform nature of Qt by mixing native C++ with it.
See the XQProfile example on Forum Nokia Wiki for mixing Qt and native Symbian C++ for profile changing.
Qt can be installed to practically all devices from S60 3rd Edition FP1 (S60 3.1) onwards. Newer device models ship with Qt preinstalled. Forum Nokia has device specifications that you can filter based on Qt availability.
QT (+ QML) is the language of choice going forward. I believe it is currently on the following phones: N8,C7,C6,E7. i version 4.6.1 with version 4.7 which has the QML support due shortly.
However if you need to target current and older devices then your only choice is Symbian C++.