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. Charlie, for what we need separate handling of OpenCL API ? There are other APIs as well. Approach always should be as generic as possible! Treat them all uniformly! --device N is enough for that if device meaning changed accordingly my proposal. There are CAL devices that are not OpenCL compatible, but there are OpenCL devices that are not CAL compatible too! So, you will need something like this function to properly enumerate CAL devices in mixed environment and all this complexity - for what reason ?
> >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.
