Since OpenCL implementations currently sit in separate .DLLs, an OpenCL app will load the first OpenCL.dll it finds, right? If so, how can we have multiple vendors on a single system (like an Intel/AMD implementation for the CPU and NV/AMD implementation for GPU)?
I think I remember hearing that the current version of OpenCL spec doesn’t include any provisions for multi-vendor apps. Is this correct? If so, will it be possible in the future to have several platforms available to an app? When?
You could install as many OpenCL SDKs as you want - these go to the different install directories, and won’t mix with each other. Drivers are needed, at the moment, for the GPU platforms only, but I guess you’re going to have single vendor GPU(s) on your system anyway, so driver installation should not mix either. NVIDIA driver installation is storing OpenCL header/library files in the system directories, so it will be picked by default. But it should not be hard to point your compiler to corresponding include/library directories of CPU platform SDK, in cases when you’d build (in Linux, -I and -L flags for g++ will do the job) or run (in Linux, LD_LIBRARY_PATH environment variable will do the job) for this kind of platform. Lots of people here (myself included) seem to be using NVIDIA SDK for GPU platform, and AMD SDK for CPU platform, without any issues.
CPU implementations need OpenCL.dll as well so ATM it’s impossible to have an app that runs some kernels on, say, an NVIDIA GPU and some on AMD CPU. I do have the AMD SDK and NVIDIA SDK installed on a single system.
The API suggests you could have many platforms within a system, since querying for platforms returns an array of them and creating contexts requires passing a platform ID instead of defaulting to a single one. But there’s no way to physically have a program actually use several implementations.
Currently both AMD and NVIDIA uses OpenCL ICD from Khronos. However, for some reason they are currently not compatible with each other, but I think this will change in the future. Then I think it would be possible to have both implementations on the same system.
(Basically, the OpenCL ICD has a registry key in the system which points to multiple DLLs of each vendor’s OpenCL implementation. For example, NVIDIA’s implementation is in nvcuda.dll, while ATI’s is in atiocl.dll. The OpenCL ICD will enumerate each DLL as different OpenCL platforms.)
Thanks for the info. Any ideas about the nature of the incompatibility problem and when it might get fixed?
It’s mainly vendors locking down each-other on Windows platform.
You could see OpenCL fully working on Mac OS X 10.6 Snow Leopard platform, even with GPU from different vendors on the same computer, as well as CPU.
Can you point me to actual examples of that working in practice on OS X?
I can see why it wouldn’t work on XP or Vista (it has to do with the display driver model), but Windows 7 uses WDDM 1.1, which allows multiple graphics device drivers to be loaded (and both NVidia’s and ATI’s drivers are WDDM 1.1 drivers). I ordered some ATI hardware the other day (for testing purposes), so I’ll try it out when it gets here.
I actually use it on my MacBook Pro, using my 2-cpu core, the GeForce 9400M MCP79 IGP (1.1Ghz 16SP) and GeForce 9600M GT (1.25Ghz 32SP); as well as on my hackintosh with GeForce 8800 GTS (96 SP) and Radeon 4670 (320 vec5). But painfully slow on 4670 due to Radeon 4xxx architecture haven’t unified read-write on shared memory, mapping it to global videocard memory instead (memory bottleneck and incredible latencies).