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. Понедельник, 15 апреля 2013, 12:28 +04:00 от "Raistmer" <[email protected]>: >I would like to attract BOINC devs attention to this issue described here: >http://setiathome.berkeley.edu/forum_thread.php?id=71192&postid=1357117 > >In short, current BOINC accelerator separation by vendor names is >inappropriate and already caused issues. >Type of accelerator API - that's what matters, not vendor name. >If device supports few APIs it should be listed under all supported types. But >different API should mean different type (it's possible/convenient to have few >types for same API like in case of OpenCL, but in no circumstances different >APIs should share same type as in the case of "ATI" type currently). >_______________________________________________ >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.
