BTW, this issue directly connected with a way BOINC handles GPU types now on anonymous platform.
It separates GPU by vendor. So, on anonymous platform we have 3 GPU types, CUDA (NV), ATI (???), intel_gpu.
But what is ATI type? Actually it's mix of types. CAL and OpenCL. What will be if AMD decides to buy let say Parallella and start to sell new accelerator boards nothing in common with GPU. What type of this device will be? Accordingly current BOINC logic it will be ATI (vendor!) and "do users/devs with that what you want".
No matter what text label (though it should be apparent for user) is, what matter is what these text labels intended to separate! And they intended to separate different types of GPU (actually, accelerator) devices that uses different APIs (hence, require different programs to operate!). CUDA and OpenCL for NV (thanks god all CUDA are OpenCL too, but it should not be the case, it's just coincidence!), CAL and ATI OpenCL, Intel OpenCL, ... (some other accelerator types will/are available on non-windows platforms. For example, Cell blade)

Actually one can argue that there should be no NV OpenCL and ATi OpenCL (and no Intel OpenCL) devices, just OpenCL device no matter what vendor is. Such point of view have much more sense that to treat CAL and OpenCL just as "ATI" common type.
But we know that different architectures may and often are require different optimizations so it's convenient to have separate types for so different devices. But actually it's not "must have" (though useful) feature. Discrimination between CAL and OpenCL is "must have" one.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Charlie, GPU 1 or GPU 0 ? Both are mentioned in single string.
Also, what device (via -- device N) BOINC will report to science app ?
If it will be --device 1 while only single OpenCL-capable card in host and counting starts from 0 - it will be strange at least.

Sorry, I was rushing when I wrote that. It should have been:
OpenCL: AMD/ATI GPU 1: ATI Radeon HD 4600 series (R730) (driver version CAL 1.4.1734, device version OpenCL 1.0 AMD-APP (937.2), 1024MB, 992MB available, 960 GFLOPS peak)

Now here is where things start getting complicated:

The use of --device is deprecated and should never be used any more. All GPU applications should link with api/boinc_opencl.cpp and call the current version of boinc_get_opencl_ids() as described here. This was posted 4 months ago.

This is specifically because we now realize that an ATI CAL device number does not necessarily equal the corresponding ATI OpenCL device number on Windows and Linux. Similarly, an NVIDIA CUDA device number does not necessarily equal the corresponding NVIDIA OpenCL device number on the Mac (because the Mac OpenCL driver is provided by Apple while the CUDA driver is provided by NVIDIA, and Apple's OpenCL implementation does not recognize all the GPUs recognized by NVIDIA's CUDA implementation.)

So we now have both a GPU device number value (which refers to the index within GPUs of the same vendor: ATI/AMD, NVIDIA or Intel) and a separate OpenCL device number (which is the index of the GPUs from a given vendor which are recognized by OpenCL.)

Currently on Windows and Linux, the GPU device number) value is the same as the one reported by CAL or CUDA, because so far all devices recognized by OpenCL are also reported by CAL or CUDA. But CAL is not supported on the Mac, and CUDA is optional, but OpenCL is built in to OS X. So on the Mac, the GPU device number value is the same as that reported by CUDA when CUDA is installed, but only OpenCL devices are enumerated for ATI GPUs, and only OpenCL devices are enumerated for NVIDIA GPUs when CUDA is not installed.

As far as I know, there is no way to get the PCIe slot number or other identifier from either CAL or OpenCL; we only have a way to get this information from CUDA. If that information were available from CAL and OpenCL, the task of correlating the enumeration of OpenCL with CAL would be trivial.

Raistmer, I will have more to say on this whole issue of GPU enumeration in the boinc_project and boinc_dev lists later.

---

Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

Raistmer,

Please also note the newer opencl_ati_101 plan class described here.

---

Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

Raistmer,

Please also note the newer opencl_ati_101 plan class described here.

Well, it may be mentioned there, but it's hardly described.

Peeking in as an outsider (non-developer), I find it hard to identify what exactly the benefits of opencl_ati_101 might be, from any combination of
AppPlan
AppPlanSpec
PlanClassFunc

Charlie, I'm sure you're aware that there is a long tradition of running applications under anonymous platform at this project, and - I'm sorry to have to tell you - many members are resistant to upgrading to the BOINC v7.0.12 necessary to support plan_class opencl_ati_101. Part of the complications with ATI cards has been the attempt to provide ongoing support to v6.10.x and v6.12.x users under anonymous platform.

It sounds as if it would be helpful to draw Eric Korpela into this conversation (or transfer the discussion to Beta), so that a proper roadmap for ATI support at SETI (server, client and application together) can be pulled together.

Charlie, I'm sure you're aware that there is a long tradition of running applications under anonymous platform at this project, and - I'm sorry to have to tell you - many members are resistant to upgrading to the BOINC v7.0.12 necessary to support plan_class opencl_ati_101. Part of the complications with ATI cards has been the attempt to provide ongoing support to v6.10.x and v6.12.x users under anonymous platform.

I must admit that I am no expert about plan classes and the operation of the scheduler. But I do know that BOINC did not add OpenCL support until version 7.0.x. From the complexities I have seen in matching the GPUs reported by CAL and OpenCL (or CUDA and OpenCL on the Mac), it seems risky at best to try to create OpenCL applications to run with BOINC 6.12.x.

It sounds as if it would be helpful to draw Eric Korpela into this conversation (or transfer the discussion to Beta), so that a proper roadmap for ATI support at SETI (server, client and application together) can be pulled together.

I have alerted him to this thread.

---

Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

The use of --device is deprecated and should never be used any more. All GPU applications should link with api/boinc_opencl.cpp and call the current version of boinc_get_opencl_ids() as described here. This was posted 4 months ago.

As was already mentioned, do you know that with this statement you cut off all pre-BOINC 7.x clients?
Do you know that service XP/2003 installation with operational GPU is supported for BOINC 6.10.60 (for example) but not supported for BOINC 7.x ?
Hence, this statement will cut off all server installations too.
And for what reason ? I see not adequate reason to reject --device.
Each accelerator type should be enumerated separately and --device should just return that number. How BOINC will track device interaction is problem of BOINC, not science apps that use it. And --device N is consistent and (that IMPORTANT) backward compatible way to supply needed info.
Also, what about Brook+ what file should such app link ?

But better to move to dev list indeed. All these questions about fundamental BOINC design flaw, not about SETI@home.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Raistmer,

Please also note the newer opencl_ati_101 plan class described here.

And how this can help with GPU type of just ATI ?
Anonymous platform ignores plan classes as Claggy described few posts before.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

The newer boinc_get_opencl_ids() API is fully backward-compatible for BOINC 6.10.x and 6.12.x clients, though it can't deal with situations such as TBar's when running on these older clients because they don't provide enough information. For more details, please see my post today in the boinc_dev email list.

I checked with David Anderson, and Claggy is correct that the plan classes only affect the server and won't work with anonymous platform.

Also, as Richard pointed out, the new opencl_ati_101 and opencl_nvidia_101 plan classes work only with BOINC version 7.0.12 and above, because that is the first version with code to deal with the issue that OpenCL device indexes can be different from CUDA device indexes. (You would want to use it as a template and modify it to accept OpenCl 1.0 device.)

The new code I have been testing here with TBar is the first to deal with the same isssue for CAL and OpenCL device indexes. So the existing boinc_get_opencl_ids() API will also handle this for ATI/AMD GPUs in future releases of the client.

Using the new plan classes will ensure that BOINC servers do not send the application to a system with GPUs that have CAL or CUDA capability but not OpenCL capability. But that does not help for an anonymous platform application intended to extend OpenCL support to BOINC 6.12.x or earlier clients, which did not have built-in OpenCL detection.

It is critical that any new OpenCL applications use the new plan classes if they are distributed directly by project servers. However, since a user has to specifically install an anonymous platform application, we can leave it to the user's judgement to install it only on systems with OpenCL capable GPUs. So you can get away without using the new plan classes there.

But there is a problem in a situation like TBar's where there is a mix of CAL capable GPUs with and withuot OpenCL support. This will normally be resolved because BOINC normally uses only what it finds to be the most powerful GPU, unless this is defeated by the user setting the <use_all_gpus> option.

---

Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

But there is a problem in a situation like TBar's where there is a mix of CAL capable GPUs with and withuot OpenCL support. This will normally be resolved because BOINC normally uses only what it finds to be the most powerful GPU, unless this is defeated by the user setting the <use_all_gpus> option.

This harm host performance, in some causes in a big degree so most of users (who caresabout host performance) tend to use that switch and to crunch on all available compute devices.

I read your post on dev list, perhaps habit to answer while reading not so good cause information near the end of mail maybe helps to avoid additional arguments I wrote answerring on begin of mail :)

Summarizing looks like it's required to rebuild with latest BONC API lib - the thing I'm trying to avoid as much as i can to not introduce any possible new bugs in system.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

This latest code allows my 4670 to work when installed in the upper PCIe slot, whereas previously it didn't. Previously I had to move the 4670 to the lower slot to work SETI tasks when both cards were installed. However, all the other problems are still present. I still have to use Exclude to keep BOINC from starting tasks on the 3650, BOINC is still trying to download over twice as many tasks for the 4670 as it should, and the 'AstroPulse v6 (anonymous platform, ATI GPU)' statistics are still not being updated for that host.

Any idea on how to solve the remaining problems? More new BOINC code? Recompiled AstroPulse Apps?

This latest code allows my 4670 to work when installed in the upper PCIe slot, whereas previously it didn't. Previously I had to move the 4670 to the lower slot to work SETI tasks when both cards were installed. However, all the other problems are still present. I still have to use Exclude to keep BOINC from starting tasks on the 3650, BOINC is still trying to download over twice as many tasks for the 4670 as it should, and the 'AstroPulse v6 (anonymous platform, ATI GPU)' statistics are still not being updated for that host.

Any idea on how to solve the remaining problems? More new BOINC code? Recompiled AstroPulse Apps?

[boinc_dev] Accelerator type identification issue

The anonymous platform mechanism gives fine-grained control
over how GPUs are used:

cc_config.xml can include <coproc> elements that describe coprocessor
types (e.g. GPUs).
You pick the name and give the device numbers.
http://boinc.berkeley.edu/wiki/Client_configuration#Options

app_info.xml can include <coproc> elements saying what coprocessor
type the app version needs.
The <type> can refer to coprocessors specified in cc_config.xml.

So if you have 1 GPU that can run OpenCL apps and 1 that can't,
put 2 <coproc> elements in your cc_config.xml
(call them, say, ati_opencl and ati_no_opencl).
Set up your app_info.xml so the OpenCL app uses <ati_opencl>
and the CAL app uses <ati_no_opencl>

Note: these features probably require a version 7 client.

-- David

Claggy

This latest code allows my 4670 to work when installed in the upper PCIe slot, whereas previously it didn't. Previously I had to move the 4670 to the lower slot to work SETI tasks when both cards were installed. However, all the other problems are still present. I still have to use Exclude to keep BOINC from starting tasks on the 3650, BOINC is still trying to download over twice as many tasks for the 4670 as it should, and the 'AstroPulse v6 (anonymous platform, ATI GPU)' statistics are still not being updated for that host.

Any idea on how to solve the remaining problems? More new BOINC code? Recompiled AstroPulse Apps?

[boinc_dev] Accelerator type identification issue

The anonymous platform mechanism gives fine-grained control
over how GPUs are used:

cc_config.xml can include <coproc> elements that describe coprocessor
types (e.g. GPUs).
You pick the name and give the device numbers.
http://boinc.berkeley.edu/wiki/Client_configuration#Options

app_info.xml can include <coproc> elements saying what coprocessor
type the app version needs.
The <type> can refer to coprocessors specified in cc_config.xml.

So if you have 1 GPU that can run OpenCL apps and 1 that can't,
put 2 <coproc> elements in your cc_config.xml
(call them, say, ati_opencl and ati_no_opencl).
Set up your app_info.xml so the OpenCL app uses <ati_opencl>
and the CAL app uses <ati_no_opencl>

Note: these features probably require a version 7 client.

-- David

Claggy

Anyway you could give me an example of what I need to enter into cc_config.xml to make this work? Otherwise, I would be using trial & error which would probably require many trials and produce many errors.
Thanks.

This is the App_Info. My guess would be to call the 4670 'ati_opencl_100' and the 3650 'ati_no_opencl', or maybe call the 3650 the class type for what the Brook+ App uses. From the above posts, the device numbers are inverted;

<app_info>
    <app>
        <name>astropulse_v6</name>
    </app>
    <file_info>
        <name>AP6_win_x86_SSE2_OpenCL_ATI_r1761.exe</name>
        <executable/>
    </file_info>
    <file_info>
        <name>libfftw3f-3.dll</name>
        <executable/>
    </file_info>
    <file_info>
        <name>ap_cmdline_win_x86_SSE2_OpenCL_ATI.txt</name>
    </file_info>
    <app_version>
        <app_name>astropulse_v6</app_name>
        <version_num>604</version_num>
        <platform>windows_intelx86</platform>
        <avg_ncpus>0.08</avg_ncpus>
        <max_ncpus>0.12</max_ncpus>
        <flops>75600000000</flops>
        <plan_class>ati_opencl_100</plan_class>
        <coproc>
            <type>ATI</type>
            <count>1</count>
        </coproc>
        <file_ref>
            <file_name>AP6_win_x86_SSE2_OpenCL_ATI_r1761.exe</file_name>
            <main_program/>
        </file_ref>
        <file_ref>
            <file_name>libfftw3f-3.dll</file_name>
        </file_ref>
        <file_ref>
            <file_name>ap_cmdline_win_x86_SSE2_OpenCL_ATI.txt</file_name>
            <open_name>ap_cmdline.txt</open_name>
        </file_ref>
    </app_version>
    <app>
        <name>astropulse_v6</name>
    </app>
    <file_info>
        <name>AP6_win_x86_SSE_CPU_r1797.exe</name>
        <executable/>
    </file_info>
    <file_info>
        <name>libfftw3f-3.dll</name>
        <executable/>
    </file_info>
    <file_info>
        <name>ap_cmdline_win_x86_SSE_CPU.txt</name>
    </file_info>
    <app_version>
        <app_name>astropulse_v6</app_name>
        <version_num>601</version_num>
        <flops>40000000000</flops>
        <platform>windows_intelx86</platform>
         <file_ref>
            <file_name>AP6_win_x86_SSE_CPU_r1797.exe</file_name>
            <main_program/>
         </file_ref>
        <file_ref>
            <file_name>libfftw3f-3.dll</file_name>
        </file_ref>
        <file_ref>
            <file_name>ap_cmdline_win_x86_SSE_CPU.txt</file_name>
            <open_name>ap_cmdline.txt</open_name>
        </file_ref>
    </app_version>
</app_info>

So for the 4670, maybe, change the App_Info type to 'ati_opencl_100', then add;
<coproc>
<type>ati_opencl_100</type>
<count>1</count>
<device_nums>0</device_nums>
</coproc>
to the cc_config.xml?

Summarizing looks like it's required to rebuild with latest BONC API lib - the thing I'm trying to avoid as much as i can to not introduce any possible new bugs in system.

Raistmer, I undertand your hesitation to change working code. But to be fully backward compatible, you do need to use the new API:

int boinc_get_opencl_ids(int argc, char** argv, int type, cl_device_id* device, cl_platform_id* platform);

as described here. Be sure to check the returned value for a possible error code. If the GPU assigned by the client is not OpenCL capable, you will get an error.

The older API

int boinc_get_opencl_ids(cl_device_id* device, cl_platform_id* platform);

won't work with older clients (versions before we added the gnu_type and gpu_device_num fields to the init_data.xml file.)

Unfortunately, the <use_all_gpus> option is only a quick and dirty fix to allow users to take advantage of all their GPUs when they are not identical. It treats them as if they were all identical to the most powerful GPU from that same vendor, and so makes them all appear to be OpenCL capable. Even my latest code (which will appear in future versions of BOINC) can't fix that situation with the <use_all_gpus> option. But the new boinc_get_opencl_ids() API will return an error code if the assigned GPU is not OpenCL capable.

We are very much aware that this needs to be fixed, but it requires a very major change in BOINC's software architecture, which may cause incompatibility with existing clients, servers and applications. Just as you are hesitant to upgrade to the latest API when you have something which works for most users, we realize the need to be very careful making major changes to BOINC's underlying infrastructure. But we do have this on our list of things to do in the long term.

Cheers,
--Charlie

---

Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

This latest code allows my 4670 to work when installed in the upper PCIe slot, whereas previously it didn't. Previously I had to move the 4670 to the lower slot to work SETI tasks when both cards were installed. However, all the other problems are still present. I still have to use Exclude to keep BOINC from starting tasks on the 3650, BOINC is still trying to download over twice as many tasks for the 4670 as it should, and the 'AstroPulse v6 (anonymous platform, ATI GPU)' statistics are still not being updated for that host.

Any idea on how to solve the remaining problems? More new BOINC code? Recompiled AstroPulse Apps?

[boinc_dev] Accelerator type identification issue

The anonymous platform mechanism gives fine-grained control
over how GPUs are used:

cc_config.xml can include <coproc> elements that describe coprocessor
types (e.g. GPUs).
You pick the name and give the device numbers.
http://boinc.berkeley.edu/wiki/Client_configuration#Options

app_info.xml can include <coproc> elements saying what coprocessor
type the app version needs.
The <type> can refer to coprocessors specified in cc_config.xml.

So if you have 1 GPU that can run OpenCL apps and 1 that can't,
put 2 <coproc> elements in your cc_config.xml
(call them, say, ati_opencl and ati_no_opencl).
Set up your app_info.xml so the OpenCL app uses <ati_opencl>
and the CAL app uses <ati_no_opencl>

Note: these features probably require a version 7 client.

-- David

Claggy

Anyway you could give me an example of what I need to enter into cc_config.xml to make this work? Otherwise, I would be using trial & error which would probably require many trials and produce many errors.
Thanks.

This is the App_Info. My guess would be to call the 4670 'ati_opencl_100' and the 3650 'ati_no_opencl', or maybe call the 3650 the class type for what the Brook+ App uses. From the above posts, the device numbers are inverted;

<app_info>
    <app>
        <name>astropulse_v6</name>
    </app>
    <file_info>
        <name>AP6_win_x86_SSE2_OpenCL_ATI_r1761.exe</name>
        <executable/>
    </file_info>
    <file_info>
        <name>libfftw3f-3.dll</name>
        <executable/>
    </file_info>
    <file_info>
        <name>ap_cmdline_win_x86_SSE2_OpenCL_ATI.txt</name>
    </file_info>
    <app_version>
        <app_name>astropulse_v6</app_name>
        <version_num>604</version_num>
        <platform>windows_intelx86</platform>
        <avg_ncpus>0.08</avg_ncpus>
        <max_ncpus>0.12</max_ncpus>
        <flops>75600000000</flops>
        <plan_class>ati_opencl_100</plan_class>
        <coproc>
            <type>ATI</type>
            <count>1</count>
        </coproc>
        <file_ref>
            <file_name>AP6_win_x86_SSE2_OpenCL_ATI_r1761.exe</file_name>
            <main_program/>
        </file_ref>
        <file_ref>
            <file_name>libfftw3f-3.dll</file_name>
        </file_ref>
        <file_ref>
            <file_name>ap_cmdline_win_x86_SSE2_OpenCL_ATI.txt</file_name>
            <open_name>ap_cmdline.txt</open_name>
        </file_ref>
    </app_version>
    <app>
        <name>astropulse_v6</name>
    </app>
    <file_info>
        <name>AP6_win_x86_SSE_CPU_r1797.exe</name>
        <executable/>
    </file_info>
    <file_info>
        <name>libfftw3f-3.dll</name>
        <executable/>
    </file_info>
    <file_info>
        <name>ap_cmdline_win_x86_SSE_CPU.txt</name>
    </file_info>
    <app_version>
        <app_name>astropulse_v6</app_name>
        <version_num>601</version_num>
        <flops>40000000000</flops>
        <platform>windows_intelx86</platform>
         <file_ref>
            <file_name>AP6_win_x86_SSE_CPU_r1797.exe</file_name>
            <main_program/>
         </file_ref>
        <file_ref>
            <file_name>libfftw3f-3.dll</file_name>
        </file_ref>
        <file_ref>
            <file_name>ap_cmdline_win_x86_SSE_CPU.txt</file_name>
            <open_name>ap_cmdline.txt</open_name>
        </file_ref>
    </app_version>
</app_info>

So for the 4670, maybe, change the App_Info type to 'ati_opencl_100', then add;
<coproc>
<type>ati_opencl_100</type>
<count>1</count>
<device_nums>0</device_nums>
</coproc>
to the cc_config.xml?

The above doesn't work....

I receive;

4/16/2013 8:01:25 PM |  | Starting BOINC client version 7.0.62 for windows_intelx86
4/16/2013 8:01:25 PM |  | OS: Microsoft Windows 8: Professional with Media Center x86 Edition, (06.02.9200.00)
4/16/2013 8:01:25 PM |  | CAL: ATI GPU 0: ATI Radeon HD 2600 (RV630) (CAL version 1.4.1734, 1024MB, 992MB available, 348 GFLOPS peak)
4/16/2013 8:01:25 PM |  | CAL: ATI GPU 1: ATI Radeon HD 4600 series (R730) (CAL version 1.4.1734, 1024MB, 992MB available, 992 GFLOPS peak)
4/16/2013 8:01:25 PM |  | OpenCL: AMD/ATI GPU 1: ATI Radeon HD 4600 series (R730) (driver version CAL 1.4.1734, device version OpenCL 1.0 AMD-APP (937.2), 1024MB, 992MB available, 992 GFLOPS peak)
4/16/2013 8:01:25 PM | SETI@home | Found app_info.xml; using anonymous platform
4/16/2013 8:01:25 PM |  | app version refers to missing GPU type ati_opencl_100
4/16/2013 8:01:25 PM |  | app version refers to missing GPU type ati_opencl_100
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_30no12ae_B5_P0_00139_20130331_19812.wu_0
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_30no12ae_B5_P0_00098_20130331_19812.wu_0
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_31oc12aa_B1_P1_00109_20130331_21193.wu_1
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_30no12ae_B6_P0_00018_20130331_22506.wu_0
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_31oc12aa_B1_P1_00069_20130331_21193.wu_0
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_31oc12aa_B1_P1_00141_20130331_21193.wu_1
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_31oc12aa_B6_P0_00014_20130331_15703.wu_0
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_30no12ae_B5_P0_00215_20130331_19812.wu_1
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_30no12ae_B5_P0_00216_20130331_19812.wu_0
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_02jn12af_B6_P0_00022_20130408_24705.wu_0
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_02jn12af_B6_P1_00022_20130408_24870.wu_1
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_01au12aa_B1_P1_00271_20130407_11794.wu_2
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_04my12ab_B0_P1_00251_20130408_19914.wu_1
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_02jn12af_B6_P0_00021_20130408_24705.wu_1
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_02jn12af_B6_P0_00061_20130408_24705.wu_1
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_03au12af_B3_P0_00052_20130408_25816.wu_1
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_04my12ab_B0_P1_00348_20130408_19914.wu_1
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_02jn12af_B6_P1_00240_20130408_24870.wu_0
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_03au12af_B2_P0_00325_20130408_29946.wu_2
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_03au12af_B3_P0_00211_20130408_25816.wu_0
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_02jn12af_B5_P0_00116_20130408_06537.wu_2
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_04my12ab_B1_P0_00059_20130408_31688.wu_0
4/16/2013 8:01:25 PM | SETI@home | Missing coprocessor for task ap_03au12af_B3_P0_00210_20130408_25816.wu_1
4/16/2013 8:01:25 PM | SETI@home | Config: excluded GPU.  Type: ATI.  App: astropulse_v6.  Device: 1
4/16/2013 8:01:25 PM | SETI@home | Restarting task ap_25fe13aa_B1_P1_00101_20130414_20647.wu_0 using astropulse_v6 version 601 in slot 0

The 4670 works with App_info set to type ATI and no CC_config.
The Exclude device 1 works preventing the 3650 from starting APs.
The new settings do not work...
<cc_config>
<log_flags>
<work_fetch_debug>0</work_fetch_debug>
</log_flags>
<options>
<coproc>
<type>ati_opencl_100</type>
<count>1</count>
<device_nums>0</device_nums>
</coproc>
<exclude_gpu>
<url>http://setiathome.berkeley.edu/</url>
[<device_num>1</device_num>]
[<type>ATI</type>]
[<app>astropulse_v6</app>]
</exclude_gpu>
</options>
</cc_config>

This line appears to be the problem;
"specify a GPU other than those detected and used by BOINC"
Both my GPUs are detected by BOINC.
This line, "<device_nums>0 2</device_nums>". They are looking for two numbers. I have tried the combinations 0 0, 0 1, 1 0, and 1 1 without success. I receive "app version refers to missing GPU type ati_opencl_100" each time.

Bueller?

This line, "<device_nums>0 2</device_nums>". They are looking for two numbers.

I believe the example is trying to illustrate a situation where one wants to use both GPU 0 and GPU 2 for the application some_name. I think in your case you only want 0 for the Brook app and only 1 for the OpenCL app. But I'm not sure.

I've asked Dr. Anderson to look at this thread and perhaps he can help you.

Note: the GPU number 0 returned by Raistmer's anonymous platform OpenCL app is the OpenCL device index, not the physical ATI GPU number used by the BOINC client, which is 1. I think you need

<device_nums>1</device_nums>

That said, I am puzzled why your <exclude_gpu> of 1 works for the OpenCl app.

---

Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

I was thinking maybe they were looking for an index & device number or something along those lines after reading your post;
"In all systems, opencl_device_indexes start at 0 for each platform and device_nums start at 0 for each vendor."

Currently, the 4670 is in the top slot, and an ATI Theater card is in between the top 16x slot and the bottom 16x slot. Of course, BOINC doesn't see the Theater card.

If the Event Log reports the 4670 as ATI GPU 1:

CAL: ATI GPU 1: ATI Radeon HD 4600 series (R730)
OpenCL: AMD/ATI GPU 1: ATI Radeon HD 4600 series (R730)

then the BOINC client should alway treats it as ATI device 1 for all external options.

But if the Event Log reports the 4670 as ATI GPU 0:

CAL: ATI GPU 0: ATI Radeon HD 4600 series (R730)
OpenCL: AMD/ATI GPU 0: ATI Radeon HD 4600 series (R730)

then the BOINC client should alway treats it as ATI device 0 for all external options.

The OpenCL index is only used internally by BOINC and applications.

---

Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

I did try to change Exclude to <type>ati_opencl_100</type>. BOINC said it wasn't a valid entry and suggested ATI. Maybe Exclude worries more about the Type than the device number. Conceivably, if I change the App_Info type to ati_opencl_100 I shouldn't need Exclude at all, one would think...

Tried it with;

<cc_config>
<log_flags>
<work_fetch_debug>0</work_fetch_debug>
</log_flags>
<options>
<coproc>
<type>ati_opencl_100</type>
<count>1</count>
<device_nums>1</device_nums>
</coproc>
</options>
</cc_config>

I receive,

4/17/2013 12:40:18 AM |  | Starting BOINC client version 7.0.62 for windows_intelx86
4/17/2013 12:40:18 AM |  | CAL: ATI GPU 0: ATI Radeon HD 2600 (RV630) (CAL version 1.4.1734, 1024MB, 992MB available, 348 GFLOPS peak)
4/17/2013 12:40:18 AM |  | CAL: ATI GPU 1: ATI Radeon HD 4600 series (R730) (CAL version 1.4.1734, 1024MB, 992MB available, 992 GFLOPS peak)
4/17/2013 12:40:18 AM |  | OpenCL: AMD/ATI GPU 1: ATI Radeon HD 4600 series (R730) (driver version CAL 1.4.1734, device version OpenCL 1.0 AMD-APP (937.2), 1024MB, 992MB available, 992 GFLOPS peak)
4/17/2013 12:40:18 AM | SETI@home | Found app_info.xml; using anonymous platform
4/17/2013 12:40:18 AM |  | app version refers to missing GPU type ati_opencl_100
4/17/2013 12:40:18 AM | SETI@home | Missing coprocessor for task ap_30no12ae_B5_P0_00098_20130331_19812.wu_0
4/17/2013 12:40:18 AM | SETI@home | Missing coprocessor for task ap_31oc12aa_B1_P1_00109_20130331_21193.wu_1
.
.

With;

<cc_config>
<log_flags>
<work_fetch_debug>0</work_fetch_debug>
</log_flags>
<options>
<coproc>
<type>ati_opencl_100</type>
<count>1</count>
<device_nums>0</device_nums>
</coproc>
</options>
</cc_config>

I get;

4/17/2013 12:54:32 AM |  | Starting BOINC client version 7.0.62 for windows_intelx86
4/17/2013 12:54:32 AM |  | CAL: ATI GPU 0: ATI Radeon HD 2600 (RV630) (CAL version 1.4.1734, 1024MB, 992MB available, 348 GFLOPS peak)
4/17/2013 12:54:32 AM |  | CAL: ATI GPU 1: ATI Radeon HD 4600 series (R730) (CAL version 1.4.1734, 1024MB, 992MB available, 992 GFLOPS peak)
4/17/2013 12:54:32 AM |  | OpenCL: AMD/ATI GPU 1: ATI Radeon HD 4600 series (R730) (driver version CAL 1.4.1734, device version OpenCL 1.0 AMD-APP (937.2), 1024MB, 992MB available, 992 GFLOPS peak)
4/17/2013 12:54:32 AM | SETI@home | Found app_info.xml; using anonymous platform
4/17/2013 12:54:32 AM |  | app version refers to missing GPU type ati_opencl_100
4/17/2013 12:54:32 AM |  | app version refers to missing GPU type ati_opencl_100
4/17/2013 12:54:32 AM | SETI@home | Missing coprocessor for task ap_30no12ae_B5_P0_00098_20130331_19812.wu_0
4/17/2013 12:54:32 AM | SETI@home | Missing coprocessor for task ap_31oc12aa_B1_P1_00109_20130331_21193.wu_1
.
.

Note there are two lines of; "app version refers to missing GPU type ati_opencl_100" this time, it wants to use both cards with this setting?