----- Original Message ----- From: "Raistmer" <[email protected]> > Is OpenCL plan class already functional? (can it be used in app_info ? ) > W/o it BOINC can't support properly hosts with mixed ATI CA:-only and ATI > OpenCL devices.
This question arose out of a lengthy testing and problem-evaluation session at SETI: http://setiathome.berkeley.edu/forum_thread.php?id=63294 The issue is not really one of plan_classes, but of whether the construct <coproc> <type>OpenCL</type> </coproc> is recognised by the client: no, it isn't, according to coproc_detect.cpp Whether or not OpenCL is detected and managed by the BOINC platform, it exists, and developers (such as Raistmer) are starting to program for it and shoehorn it into the current framework. Doing so reveals some of the difficulties which BOINC will encounter when adding native support. In the SETI case, we encountered two instances of hosts with dual graphics adapters: both ATI devices detected and enumerated by BOINC. But the GPUs were of very different capabilities: ATI device 0 was a low-spec motherboard integrated video output device which the users wished to use for general-purpose display output, and ATI device 1 was a high-performance device which they wished to use as a true co-processor. The additional problem with the most recent user was that they had installed the still-recommended BOINC v6.10.58, which has no ati_compare function: despite the disparity between the cards (HD3300 @ 56 GFLOPS peak vs. HD5800 @ 2720 GFLOPS peak), BOINC attempts to schedule and use both devices. (that problem should be eliminated in BOINC v6.12: we have advised the user to test v6.12.18, but there has been no feedback as yet) Whilst OpenCL has no native support in BOINC, project applications have to do their own OpenCL device enumeration and management. Of the two devices above, only the HD5800 is OpenCL-capable - so OpenCL enumerates it as Device 0. BOINC, meanwhile, is instructing the application to use ATI device 1. This mis-match between enumerations appears to be leading to the application errors which Raistmer, as programmer, may or may not be able to overcome for such mixed environments. In the medium term, surely BOINC needs to be able to perform the OpenCL device enumeration and pass a validated OpenCL device ID for OpenCL applications to use. Without that, applications have to pick their own device to run on, which will make a mockery of BOINC's scheduling decisions. The scheduling problem transfers to BOINC. In the example above, the same physical device equates to ATI (1) and OpenCL (0). The host might be attached to two projects, one of which has an application which uses the device in its native ATI mode, and the other has an application which uses it in OpenCL mode. Presumably BOINC needs to avoid scheduling both projects to run at once on the 'different' devices, although on a 'symmetrical' host with two OpenCL-capable GPUs, one might be running a native-mode project/app, and the other an OpenCL-mode project/app. Without BOINC support, the increasing number of OpenCL applications are going to run into major scheduling problems like that. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
