I asked about CPU OpenCL but that will require a re-write of everything implemented so far. Instead of setting up OpenCL as a separate entity, they decided to make opencl an attribute of the AMD and nVidia corprocessor and don't report CPU OpenCL at all. The bad implementation has led to problems since OpenCL doesn't care whether it is AMD or nVidia. It just says there are X devices that support OpenCL. Unfortunately, device 1 in OpenCL may be device 0 in nVidia and so the client may schedule the nVidia WU to run on the same device that is already busy running an OpenCL WU. They think that have that problem solved. It would have been a lot easier to solve if they had just made OpenCL a new coprocessor type. Then it would have much easier to allow it to handle CPU tasks. Why is that important? From my testing, I've found that the Collatz OpenCL for CPU app works better than the OpenMP version - at least with the AMD driver. I haven't tried the Intel OpenCL for CPU driver yet. I would expect that to be as good or better. So, for now, the OpenCL for CPU apps have to be installed as opt apps using the "mt" plan class (multi-threaded) like AQUA WUs. Since there is no way to know whether the machine supports OpenCL on the CPU because the BOINC client doesn't report it, the only other way to handle it is to assume that if the user has AMD Catalyst drivers and the CPU supports SSE, then send the OpenCL CPU app and if the customer has nVidia or Itel drivers, then they are S.O.L.
(1st Place) 
Reply With Quote
Originally Posted by zombie67
