To further clarify how the newer API is backward compatible: int boinc_get_opencl_ids(int argc, char** argv, int type, cl_device_id* device, cl_platform_id* platform)
First it tries to get the GPU "type" (vendor): ATI, NVIDIA or Intel, from the init_data.xml file. If that fails, it gets it from the type argument to the function, if present. Next it tries to get the gpu_opencl_dev_index and gpu_device_num from the init_data.xml file. If that fails, it gets the gpu_device_num from the --device argument. Cheers, --Charlie On Apr 15, 2013, at 4:09 PM, Charlie Fenton wrote: > BOINC's GPU device number as displayed in the Event Log is for a physical > GPU. In the case to which Raistmer refers, the first ATI GPU (GPU 0) is > capable of (and recognized by) CAL but not OpenCL. The second ATI GPU (GPU > 1) is recognized by and capable of both CAL and OpenCL. > > Thus, BOINC _correctly_ reports that ATI GPU 1 is the only OpenCL capable ATI > GPU: >> CAL: ATI GPU 0: ATI Radeon HD 2600 (RV630) (CAL version 1.4.1734, 1024MB, >> 992MB available, 348 GFLOPS peak) >> CAL: ATI GPU 1: ATI Radeon HD 4600 series (R730) (CAL version 1.4.1734, >> 1024MB, 992MB available, 960 GFLOPS peak) >> 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) > > The reason BOINC _must_ use the same index for the same physical GPU is to > prevent assigning the same physical GPU to more than one task at a time. > This is the number reported by --device, and is the same as the index of CAL > or CUDA capable GPUs. > > As of BOINC version 7.0.12, we have added a second index, which is the index > of only openCL-capable GPUs. In the above example, this would have the value > 0 for the HD 4600, and this value provides the API-specific index Raistmer > requests. > > The reasons that we have deprecated the use of --device and now require GPU > applications to instead call boinc_get_opencl_ids(int argc, char** argv, int > type, cl_device_id* device, cl_platform_id* platform). It also optionally > allows an application to offer a plan class allowing it to run on all OpenCL > capable GPUs, not just from one vendor. > > The reason for the change is that this newer API deals automatically with the > possible difference between the CAL or CUDA device index and the OpenCL > device index. As the comments in the source file explain: > // A few complicating factors: > // Windows & Linux have a separate OpenCL platform for each vendor > // (NVIDIA, AMD, Intel). > // Mac has only one platform (Apple) which reports GPUs from all vendors. > // > // In all systems, opencl_device_indexes start at 0 for each platform > // and device_nums start at 0 for each vendor. > // > // On Macs, OpenCL does not always recognize all GPU models detected by > // CUDA, so a device_num may not correspond to its opencl_device_index > // even if all GPUs are from NVIDIA. > > I will add to this that we have recently learned that AMD's OpenCL does not > always recognize all GPU models detected by CAL, so a device_num may not > correspond to its opencl_device_index even if all GPUs are from ATI/AMD. > > NOTE: The new boinc_get_opencl_ids() API is 100% backward compatible with > older versions of the BOINC client. From the source file's comments: > > // This version is compatible with older clients. > // Usage: > // Pass the argc and argv received from the BOINC client > // type: may be PROC_TYPE_NVIDIA_GPU, PROC_TYPE_AMD_GPU or PROC_TYPE_INTEL_GPU > // (it may also be 0, but then it will fail on older clients.) > // > // The argc, argv and type arguments are ignored for 7.0.12 or later clients. > // > // returns > // - 0 if success > // - ERR_FOPEN if init_data.xml missing > // - ERR_XML_PARSE if can't parse init_data.xml > // - CL_INVALID_DEVICE_TYPE if unable to get gpu_type information > // - ERR_NOT_FOUND if unable to get opencl_device_index or gpu device_num > // - an OpenCL error number if OpenCL error > > Finally, we have added two new prototype plan classes: opencl_nvidia_101 and > opencl_ati_101 for app versions that run on NVIDIA or ATI GPUs using OpenCL > 1.1, using at most 256MB of GPU RAM. You can modify sched_customize.cpp to > change these parameters or add your own plan classes, such as for OpenCL 1.0 > or 1.2. These plan classes are not backward compatible and require BOINC > 7.0.x. > > Information about all of the above can be found at > <http://boinc.berkeley.edu/trac/wiki/OpenclApps>. > > I hope this answers your questions. > > Cheers, > --Charlie > > On Apr 15, 2013, at 6:48 AM, Raistmer the Sorcerer wrote: >> Regarding deprecation of --device N option: >> can anyone provide description for what reason it was done? >> >> Each API contains own enumeration. >> Each enumeration (in particular device class) starts from zero (0). >> What prevents BOINC to report --device N to app correctly if BOINC knows for >> what accelerator class designed ? >> In view of recent CAL/OpenCL issue (or in view OSX CUDA OpenCL issue, no >> matter): >> --device N for CAL should be 1 and 0 (2 CAL enabled devices installed); >> --device N for OpenCL should be only 0 (1 OpenCL capable device installed). >> BOINC keeps track what device is what physical device, app just need device >> number in own API enumeration scheme. >> For what reason (for example) my OpenCL app should know that there are >> another, non-OpenCL device in system ? It should not. Hence, no "device 1", >> but "device 0". It doesn't kere about keyboard or mouse, it should not care >> about CAL GPU too. It's BOINC mission not to allocate same physical device >> both as CAL and OpenCL in the same time. >> Currently app recives OpenCL context handler. Ok, no probs with that. But >> (!) ensure back compatibility! such OpenCL context should contain same >> device as OpenCL enumeration API would provide if --device contains offset >> in device list. What particular issues do you see with this? But providing >> both --device _and_ OpenCL context (for what reason context - separrate >> question but perhaps sometimes it's convenient indeed) you provide at least >> partial backward compatibility. If one can provide backward compatibility it >> should be done! >> All this (BOINC) about using AVAILABLE user resources, already available >> ones. Not about requesting users to upgrade OS, but new hardware and so on. >> Backward compatibility should be keystone of BOINC concept. And all these >> nor really needed "deprecations" will play badly with existing userbase. > _______________________________________________ > 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. > _______________________________________________ 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.
