Originally posted by: genetix_ Why are ATI opencl.dll files on final SDK at ATI Stream path where they are not identified nor found unless hardlinked to %SystemPath%\system32 / \SysWOW64 unlike NVIDIA who at least copied the DLLs to correct place?
Also would love to know why is my system still unable to load NVIDIA and ATI OpenCL.dll's at same time? I mean isn't OpenCL purpose to actually be an opensource standard to utilize as much possible which atm looks like NVIDIA as well as ATI are doing everything to prevent this happening. Hell, I don't know, if it's the bad coding or lame naming styles, but even if one would actually be able to put these side by side dynamicloading they still wouldn't work. |
Your questions are all spot on. What I would add to this is:
Why is it that both AMD/ATI's implementation of OpenCL.DLL and nVidia's implementation of OpenCL.DLL if you copy them into Windows/System32 will only find their own platform... Shouldn't both "Khronos" implementations of OpenCL be platform neutral and search for all the DLLs in the Khronos Vendors registry.
My point is that nVidia is just as broken with ATI's "ICD" as ATI is with nVidia's "ICD", except that nVidia knows where to put their "ICD" so that it gets hit first, so if you install both on a client machine, you're targetting nVidia.
Neither implementation is a true ICD, even though both put the appropriate Khronos registry keys in the registry. I've written some slightly non-trivial script to generate wrappers around OpenCL so that I don't have to care if either company makes a correct implementation of the ICD, but it means that any time I install my programs, they need to be sensitive to platform-specific problems.
As far as I'm concerned, the purpose of an ICD is so that software developers like myself can depend on companies like ATI/AMD and nVidia and Intel and Microsoft, etc to work together so that we don't have to do hacks to get our programs to install correctly on end users computers.
I spent about a day (a few weeks back) writing some script code to parse the OpenCL headers and generate a simple C++ class that can LoadLibrary any OpenCL DLL and forward all calls to it. I also made a stub OpenCL.DLL (just declare the appropriate exports symbol, etc) to test making a real OpenCL ICD with full path names to find the DLLs.
What I found doing this is that there are a few tricks to be careful about when trying to mix platforms. For example, each internal OpenCL implementation lives in its own vacuum. A memory object in one implementation is likely to not be compatible with a memory object in another, so if you have a true OpenCL ICD with memory from devices within multiple platforms, they won't work together.
You might also think that the queues and contexts would work together with devices from multiple platforms, but I would wager that's also a ton of work.
Don't get me wrong. I think the ICD model is heading down the right path, but unless ATI and nVidia do the legwork to actually support *and test* with the competitor's products, you're not going to have a standard OpenCL. Instead, you're going to have CUDA-OpenCL and CAL-OpenCL. This is basically what you have now, except that nVidia developers figured out the trick to defeat AMD by putting their DLLs into Windows\System32: http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
