I think the ease of support is the limiting factor here. Keep in mind that it has taken many, many, years to get another GPU project of any flavour running on WCG again. I suspect that the hurdles to porting applications to run efficiently on GPU's are not trivial or everyone would have done it by now.

Another factor is that even running using Open CL and with pauses in GPU usage, there is still not enough GPU work available to meet the demand. So arguing that CUDA is better/faster than Open CL is pointless for this project. Improved performance through better coding or porting to CUDA would take time and resources, but would not process a single extra unit per day since the volume of units available is already the limiting factor, not the code.

WCG and the researchers are both working with tight budgets. Personally I feel that if the researchers or WCG have any spare development resources, the maximum benefit would come from increasing the volume of GPU work to fully use the existing GPU capacity rather than improve the app so we had even more unused capacity.

Good evening,

It appears that I have raised a few eyebrows with my statement that the OpenCL is faster than the CUDA version. This is in fact true, the CUDA version of the code runs about 20% slower on average and in some cases up to 2x slower than the OpenCL version. These are specific numbers given to me from the researchers. My statement wasn't that CUDA isn't faster than OpenCL in general, it was specific to this application. I do not know the time allotment from the researchers on the GPU code as to how much effort they put into the two different paths that are needed.

I do not claim to know how much effort would be needed to get the CUDA version to the state of OpenCL, but the code in the current state allows for OpenCL to run faster than CUDA.

As for the "it's good enough" approach, I agree that there are some things that can be improved upon. At the moment, I am making sure this current version works properly. I do have in my mind a possible way to keep the GPU running more consistently, but it is a major change to how jobs are submitted and generated. This initial version was created with the original idea to keep it as similar to the CPU version for keeping consistency between the entire pipeline scripts. By keeping it similar allows us to compare results and groupings to make sure things operate properly. Also, I would like to correct the checkpointing issue where it is not following the checkpoint rules and possibly a way to write to disk less frequently. Again, these are not minor changes and require changes to the code as well as testing from scratch.

Thanks,
-Uplinger

Confucius: "Better a diamond with a flaw than a pebble without..."

I think it is not limited by WCG app but BOINC suite which manages apps.
By default setting BOINC use just one GPU for crunching (fastest / most capable one).
There is an BOINC option to allow run of GPU apps on all GPUs simultaneously located in "cc_config.xml" file in BOINC data root dir (not app dir where executables are located, but data dir):

But also check project settings here(in WCG profile): if Intel GPU is allowed to run? There are 3 independent switches in the project setting for each major GPU vendor - NV, AMD and Intel).