>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:
It's not. When I call it under older BOINC I get no valid CL context so ap will failt to execute if it will not create own CL context. > >// 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. Plan classes are of no use with anonymous platform - another design flaw. > >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 Unfortunately, not. Actually it's not a questions. It's direct proposals what need to be changed. Current BOINC accelerator type handling is inconstintent and that inconsistency should be chamged, not explained. We dont' need "ATI" GPU type. We don't need NV GPU type. We need: CAL GPU type, we need CUDA GPU type, OpenCL type (for convenience and backward compatibility there should be: OpenCL, OpenCL_NV, OpenC_ATi, OpenCL_Intel, OpenCL_CPU, OpenCL_GPU). If we should go into Unix there should be CELL_BLADE type too. Maybe others even more exotic. These classes can have intersections on physical devices. BOINC client should track such intersections. BOINC API should report --device to scientific app where N is offset in accelerators array of corresponding type. With such rules we will have much more consistent accelerator support than we have now. No any "double indexing" needed. ONLY inside BOINC scheduler (and it can be reported to stdout for user, but not to scientific app). > >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.
