Now that CodeXL is open-source and openly developed, I'd expect it to support more than just AMD GPUs. Is this true?
Which GPUs does CodeXL support?
This information is buried deep in the GPUOpen site, in the Release Notes for the latest version - 2.2, the System Requirements section.
The document is lengthy and copyrighted so I won't reproduce the information from it here, except the piece that I was most interested in:
For GPU API-Level Debugging, a working OpenCL/OpenGL configuration is required (AMD or other)
So non-AMD GPUs are supported.
Related
I have installed Tensorflow-GPU version 1.9.0 and simple tensorflow import statement gives exception "Illegal instruction (core dumped)". If I downgrade tensorflow version to 1.5.0, it works fine. How to fix this issue for higher version as I need to work with it?
Thanks
Starting with v1.5.1 on Linux and v1.6.0 on other platforms, the official TensorFlow distribution is compiled with AVX instructions, meaning that older CPUs will not work with it (you can look up model compatibility, but it does not have to be an ancient CPU, it happened to me on an old Core i7).
If you want to use official releases, the only solution is to switch to a different hardware or to stick to the older version. There have been requests for support for older CPUs (and some people have uploaded their own build for a particular configuration, if it works for you and you trust it), but the general answer is that if you need specific support for your platform you can always build it yourself, disabling AVX optimizations (see the installation guide).
My MacBook Pro doesn't have a NVIDIA gpu. So it's not possible to run CUDA. I'm wondering which of the earlier versions of TensorFlow have gpu support for Mac OS? And how can I install on Anaconda?
As stated on the official site:
Note: As of version 1.2, TensorFlow no longer provides GPU support on
Mac OS X.
..so installing any earlier version should be fine. But since your hardware does not have NVIDIA graphics card with CUDA support, it doesn't matter anyway.
In terms of installing TensorFlow on Mac OSX using Anaconda, you can just follow steps nicely described in the official docs
TensorFlow relies on CUDA for GPU use so you need Nvidia GPU. There's experimental work on adding OpenCL support to TensorFlow, but it's not supported on MacOS.
On anecdotal note, I've heard bad things from people trying to use AMD cards for deep learning. Basically AMD doesn't care about deep learning, they change their interfaces without notice so things break or run slower than CPU.
Does Google Tensorflow support OpenCL... or is it still only Cuda?
OpenCL does not appear to be supported yet (April 2017) per this open issue - https://github.com/tensorflow/tensorflow/issues/22 but I keep reading that support exists -- I might be missing something.
tf-coriander is an implementation of Tensorflow for OpenCL 1.2 GPUs. It's based on coriander, which is a general compiler to run NVIDIA® CUDA™ code on OpenCL 1.2 devices. Disclosure: I'm the author, of both projects.
There is OpenCL support via SYCL on Tensorflow, some features are in, others are in progress: https://github.com/tensorflow/tensorflow/issues/22#issuecomment-266050835
I have NVIDIA driver v 378.92 installed, and according to the nvidia website since driver version 377.14, driver supports vulkan api 1.0.42.1. My vulkan SDK api version is 1.0.42.2. However when I check for my device support info, using vkjson_info.exe in the vulkan SDK, there's stated that only apiVersion 1.0.37 is supported.
I'm a bit confused how this works, can anyone enlighten this?
The reported version could be limited by the Vulkan Loader/Runtime it finds. First is this Windows or Linux?
If you have the Vulkan SDK 1.0.42.2 installed, can you run the VIA tool? It should generate an HTML output. If you look at the "Runtimes" section, you should see which ones are available and which one it's using. For best results, try running it from the same folder as vkjson_info.exe. But, it should give you a good idea if you just run it anywhere.
"1.0.42.1" is not a Vulkan version. Vulkan only has three levels (i.e. major.minor.patch). So the "1.0.37" is likely correct and the "1.0.42.1" is likely the version of some LunarG Vulkan SDK or possibly Vulkan Runtime that comes with it.
There are usually several types of versions flying around:
The Vulkan driver version. It is of the major.minor.patch format and it is in VkPhysicalDeviceProperties::apiVersion or can be obtained by a tool such as VHCV.
Optionally SDK/Layers version on the runtime machine. LunarG Vulkan SDK versioning of the form vulkan_major.vulkan_minor.vulkan_patch.optionally_SDK_patch.
Vulkan Runtime of the runtime machine — It is basically The Vulkan Loader dll (if the application uses that). Both SDK and drivers install this (and coexist) and they use their own versioning scheme. The SDK version also installs the Validation Layers to the system.
SDK/Header on the application developer machine. Versioning as described above. The vulkan.h header is always 1.0 and so has only single number version — VK_HEADER_VERSION (which matches the Vulkan patch version — but does not have to in the future)
SDK/Header on the driver developer machine. Versioning as described above. Should really be the same as Vulkan driver version. And most likely the Vulkan RT installed by the driver will be the same version. But I think I have seen this to differ.
It should not matter, because all patch versions are supposed to be both-ways compatible (in reality not really — there were some changes, but driver makers seem to keep up so far providing updated drivers, so it is not an issue). And in fact that is the only thing I could find in the driver documentation: "Vulkan 1.0" support.
I hope you are so enlightened now that you reached the ultimate state of boredom.
377 is a beta version driver from https://developer.nvidia.com/vulkan-driver . There is no guarantee that beta feature will be carried over to the subsequent release version. And according to http://vulkan.gpuinfo.org/listreports.php it didn't (378 indeed have 1.0.37 and 377 have 1.0.42 and more importantly has the extensions you want to try). Continue to use the beta for now if you want the features within it. As for Layers and other SDK features you should not need newer drivers — in fact you should always use the latest to benefit from Validation Layer bugfixes and improvements.
Question 1
If I want to build an application with OpenCL support, do I have any guarantees that the OpenCL.lib implementation from my vendor is able to work with all devices from other Vendors? If yes what's the difference between the implementation?
Question 2
Is it possible to use different OpenCL versions in the same application? For example AMD has released a preview driver for OpenCL 2.0 support. On the other hand the lovely company called Nvidia is still trying to ignore everything past OpenCL 1.1. It would be nice if I could write platform specific code in different versions.
1: On Windows, OpenCL.lib is a static wrapper around OpenCL.dll, which is the ICD loader, and exposes all of the available platforms. It is provided by Khronos and redistributed by the OpenCL platform vendors. So go ahead and link to it; it will work with whatever is installed (although if nothing is installed your application won't run because it can't find OpenCL.dll; this is solved other ways).
2: Yes. As long as the ICD loader is the latest, you can get at the newer API on newer platforms / devices. Just don't use new API on old devices; that will crash or worse.