One thing at a time, I think. You’re correct that each platform will eventually need a coherent host-side opencl subsystem for heterogeneous device management, but I expect there will be competing implementations, at least for the first while.
As for saving driver writers effort; I suspect the host-opencl->device interface will be a lot like current graphics drivers: very dependent on the platform architecture for graphics at the higher level, and very dependent on how the hardware works at the low level. OpenCL itself should help by making a lot of mid-level driver code more portable though.
This is a very valid point… and requires immediate attention.
We are a software company working on offering OpenCL support in the near future. We are dealing with the practical issue of how we are going to efficiently ship our product to work with any installed version of OpenCL.
Currently on Windows we can dynamically link to either NVIDIA’s or to ATI/AMD’s OpenCL.dll. However,we are still having problems on how to currently just ship one set of binaries that uses either NVIDIA’s or ATI’s DLL, due to an inherent limitation in the DLL design + linker, that needs to know the ordinals for the function calls. One solution is to potentially statically load the DLL with LoadLibrary, get the ordinal for the functioncall and invoke each of the 80 something function calls via proxies.
To make matters more challenging, it is possible to have concurrent installations: an OpenCL CPU driver and the GPU driver, for example.
As OpenCL starts to mature as a product, and the community starts using it, there will be a need for a better solution.
The platform layer is supposed to take care of this. I believe that the vendors, through Krhonos, are supposed to release a single platform layer that will take care of loading the appropriate libraries for the given platform you choose. However, as far as I know this hasn’t been finished yet. Your best bet is to push the vendors to get together and get this finished.
Thanks for making me aware of the other thread. I actually discovered it myself a bit later and I also posted a reply into it. I looks like a guy from NVIDIA confirmed that with the next release of their binaries they will have the same naming convention. I am hopeful that by the beginning of next year there will be a graceful solution to this issue.
No, he said they would use the same calling convention.
That still doesn’t mean they’ll use the same naming convention aswell.
That’s why I think a standardized .def file is very important. That will make sure that all the exported symbols (and their ordinals) will be the same. Currently AMD exports fully decorated stdcall names, which I think is wrong. You don’t want to have to import “_clReleaseMemObject@4” when you can just import “clReleaseMemObject”. OpenGL also doesn’t export fully decorated names, I don’t think OpenCL should.
But nVidia hasn’t said anything about what they’re going to do. Currently they’re using cdecl, so you’d get an exported symbol such as “clReleaseMemObject” by default. So I’m not sure if their undecorated exported names are just ‘by accident’. If they are, then moving to stdcall will automatically make them the same as AMD’s. If they’re not, then you still don’t get the same exported symbols.
And obviously if Khronos decides that you need to export undecorated names (which I think they will, it’s the preferred way on Windows), then at least AMD, and possibly also nVidia will have to release yet another version before it all works well.
Ah yes, I hadn’t checked their beta4 release yet. Just installed it, and indeed, they have clean names now.
So I guess it’s now up to nVidia, their next release needs to have stdcall AND undecorated names, then the problem is solved for now. And if Khronos then doesn’t change the name OpenCL.dll to something else (not OpenCL32.dll or something, to be in line with OpenGL32.dll), and sticks to this calling and naming scheme, the ICD model will be a drop-in.
That would be the best for all of us.