I have been running BOINC for years, am currently in the middle of trying to upgrade a dual GPU system. Quick summary:

Have two GPUs - GPU1 and GPU2. GPU1 and GPU2 are detected on their own just fine. GPU1 is detected fine together with any other GPU. GPU2, however, isn't detected in combination with GPU1 (have swapped physical PCIe slots with the same result).

coproc_debug doesn't give much info. I pulled the OpenCL detection routines (gpu_opencl.cpp) from BOINC into a stand-alone application for debugging purposes (I didn't have the time to compile and debug the entire BOINC application). The crazy thing is that even with the hardware set-up that BOINC doesn't detect correctly, my stand-alone application does.

Running current releases of NV and AMD drivers respectively. Another curiosity is that clinfo doesn't appear to detect GPU2, but an older version of clinfo does. Both GPUs concerned here are current generation, current architectures.

I have to rush off now but I'll provide more details later - just wondering if anyone has any ideas/thoughts on this because I'm starting to run out of them.

Edit: I'll add that stand-alone OpenCL applications work just fine as well. BOINC just isn't detecting the GPU for some reason.

It would help if you said what the two GPUs are as some GPU are "rather fussy" about the particular version of driver deployed.

There is a pre-compiled clinfo.zip available for download.

There was no specific change in the GPU detection routines in v7.10.2

Thanks for the quick responses - I didn't have time to go into too much detail earlier.

I don't recall ever having an issue with GPU detection in Windows, only in Linux and that was years ago - I think the driver situation has improved much since then.

Under BOINC I've run NV Pascal, Maxwell, Kepler, and Fermi of all sizes without issue in Windows (OpenCL as well as CUDA), and AMD Fiji, Hawaii, Bonaire, Tahiti, Pitcairn, and even pre-GCN Cayman, Barts, RV730 and RV630. I don't remember BOINC having issues detecting any of those under Windows. In my current case, GPU1 is NV Pascal and GPU2 is AMD Vega. Vega has been around for nearly a year now, so I'd be surprised if there's something wrong with the driver side - as I said I can run OpenCL applications off-line apart from BOINC just fine, plus my cobbled-together stand-alone BOINC GPU detection could read both the Pascal and the Vega.

That pre-compiled clinfo reproduced the curious scenario I described earlier - the May 2018 clinfo that was put into my Windows/System32 directory (I think that's from the AMD installation) only picks up the NV Pascal and the CPU. The 2011 copy you linked to picks up those two as well as the AMD Vega.

I also did a quick test under Linux with AMD Fiji and AMD Vega together. Only the Fiji was detected by BOINC so I doubt mixed-vendor set-up is a relevant concern. Really puzzled why BOINC is having difficulty with Vega when there is more than one GPU involved.

So I managed to compile the boinc client from branch client_release/7/7.10.2 (commit f6033b09) and it's detecting the Vega while the BOINC 7.10.2 binary release does not. I'm getting quite confused by now. Does anyone have any information on who does the compilation for the releases on boinc.berkeley.edu?

Okay, totally bizarre but I've found why my compilation didn't match the BOINC release - my compilations were 32-bit only while the BOINC release I was using was the 64-bit version. I just tried a 32-bit release and the GPUs are being detected okay.

Might anyone know why 64-bit BOINC can't detect Vega properly (apparently)?

For future reference: for whatever reason, in my particular dual-GPU set-up, a 64-bit compilation fails in COPROCS::get_opencl(), gpu_opencl.cpp:343. After finding two OpenCL GPU platform IDs, it fails when attempting to find the AMD GPU Device ID:

        ciErrNum = (*p_clGetDeviceIDs)(
            platforms[platform_index],
            (CL_DEVICE_TYPE_GPU | CL_DEVICE_TYPE_ACCELERATOR),
            MAX_COPROC_INSTANCES, devices, &num_devices
        );

        if (ciErrNum == CL_DEVICE_NOT_FOUND) continue;  // No devices

It doesn't seem like it should be necessary, but I'll stick with 32-bit compilation as a work-around.