I am looking for an implementation of the OpenCL language that supports the cl_khr_fp16 extension. To my knowledge, no publicly available implementation supports this at present.
I think you're right, no implementation supports this at this time.
But since cl_khr_fp16 ext is part of v1.1 (AFAIK) and v1.1 is coming very soon, you shouldn't have to wait too much.
Roadmap from AMD:
http://img251.imageshack.us/img251/1507/roadmapf.jpg http://img251.imageshack.us/img251/1507/roadmapf.jpg
And NVIDIA already have pre-released v1.1 drivers:
http://developer.nvidia.com/object/opencl.html
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.
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.
There is a feature in OpenCL 2.0 that I would like to use.
I dual boot Ubuntu and Mac OS (Graphics: GTX 670 + HD Graphics 4600). Is it possible to install OpenCL 2.0?
This may be a dumb question - from what I have read, it seems like 2.0-compatible drivers may not be written yet? And also possibly my hardware will not support the new spec?
Basically, when will OpenCL 2.0 be easy/available?
You mentioned you have an NVidia GTX 670; you should note that NVidia's drivers only support OpenCL 1.1, not 1.2.
NVidia have(*) refrained over the past several years from updating their drivers to support the newer OpenCL standard, even though the hardware obviously supports it and CUDA has all the relevant functionality... so don't expect 2.0 to happen so soon on your hardware.
(*) - Due to being Evil™.
There are no OpenCL 2.0 drivers yet. The specification just became final yesterday. I don't believe any public statements have been made yet about when drivers will become available, and for what hardware. You'll have to wait for whatever fun new feature you wanted. Better yet, let your favorite vendors know that you'd like them to support OpenCL 2.0!
There is some support for OpenCL in Clang 3.0 and from the LLVM organisation.
See the CLang 3.0 release notes
http://llvm.org/releases/3.0/docs/ClangReleaseNotes.html
Here's an LLVM presentation on OpenCL
http://llvm.org/devmtg/2009-10/OpenCLWithLLVM.pdf
Here's another Stackoveflow answer on Clang 3.0 for OpenCL
How to use clang to compile OpenCL to ptx code?
So there are some good folks working on an open source version of OpenCL that compiles to PTX for NVida cards. Not having used it and not being familiar with these efforts, I can't say if there are plans or when when they can get to the OpenCL 2.0 spec.
Is there a libm (libmath) that is optimised for ARM(v6) processors?
I was looking at the GNU implementation and it doesn't seem to be optimised (but it does have x86 ones). It seems that most implementations of libm do not have ARM specific optimisation.
The closest option i found was using libm for ARM in the AOSP Android's repositories (or the manufacturers if they are providing optimized version of android for your cpu).
There are many math libraries available from the official ARM library. Depends on which application you have.
https://developer.arm.com/solutions/hpc/hpc-software/categories/math-libraries
I googled this topic and didn't find anything new. I am aware of Nvidia's FFT implementation which is great, but for CUDA only. AMD just released their implementation, but it doesn't work on Nvidia cards. Apple has an older and slower implementation. Are there any other good FFT libraries out there? It would be nice if there was an implementation that was meant to work on Nvidia and AMD cards and other possible platforms and is being actively maintained.
The AMD clAmdFft library should work on NVidia GPUs.
I was involved in the development and I know that was the intention. The code was written to the OpenCL standard and doesn't use any proprietary tricks. Of course, AMD didn't do QA testing on NVidia hardware. It could be that NVidia's OpenCL implementation isn't quite 100% compliant to the standard yet. Or it could be something about your particular video card.
Please post more details here as to exacly what is happening. You should also post that information in the AMD developer forums as a bug.
AMD recently released an OpenCL SDK for their CPUs as wel as GPUs. Included in it are FFT and BLAS libraries. You can go to the bottom of the page to find out about the supported devices.
But I am not really sure about the performance.
Not yet - but there is a project to port the GSL (Gnu Scientific Library) to opencl
http://gsl-cl.sourceforge.net/
I know Apple has released an OpenCL FFT package, but I don't know much about it. I've heard that they make the source available.