>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.
BOINC - yes (inside scheduler), but should BOINc report that physical number to scientific apps? No. It should not! For what reason --device N should mean PHYSICAL DEVICE ? What I propose is to set --device N meaning as next: index to device array, recived by that enumeration API that app of corresponding type uses. That is, if app is CAL app than --device N means index into array of CAL devices. If it's CUDA app then --device is index to array of OpenCL devices (of correspnding type NV, ATi, or intel_gpu). And so on. Look! Currently we can have NV GPU + ATI GPU in the same OS. So, 2 physical devices. But each of NV and ATi apps will recive --device 0 ! As it should be if device will be defined as I propose, not as just "physical device". There are 2 physical devices of different types. In case of CAL and OpenCL there are too 2 different physocal devices. 2 devices of CAL type and 1 device of OpenCL type. BOINC (and ONLY BOINC CLIENT) should know that device X from CAL list is same as device Y from OpenCL list. > >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.
