"CAL" and "CUDA" are the names we chose a long time ago to describe ATI (now AMD) and NVIDIA GPUs. We should have called them ATI and NVIDIA instead.
The problem with having a separate OpenCL coproc type is that then the client would run 2 jobs on 1 GPU. The client's job is to schedule hardware; for the most part it doesn't care about what APIs applications use. I think there's a way to handle a situation where there 2 AMD GPUs, one of which can't do OpenCL, using anonymous platform. I'll describe this in another email. -- David On 15-Apr-2013 4:00 PM, Jon Sonntag wrote:
I believe the concept is that OpenCL should have been a separate coproc type rather than a subset of ATI or CUDA. If not, I would make the case that OpenCL should also be a subset of CPU so that it allows "mt" apps to use OpenCL instead of OpenMP which is very easy to do if you already have OpenCL apps for the GPUs. For a specific example, , HD 7xxx hardware uses a different IL instruction set such that using the Brook+ apps in Collatz on HD 7xxx GPUs causes invalid results even though there are no errors while processing. (It literally skips half the work but reports success.) Given that the Catalyst 13.x drivers seem to have dropped CAL support (they've been promising to do that for a while), it confuses the volunteers in that they complain that their ATI GPU works OK on project X but not on Collatz when they really mean that their AMD GPU works fine running OpenCL apps on project X but don't run the Brook+/CAL apps on Collatz. So, it isn't about the vendor, it is about the API (CUDA, CAL, Brook+, OpenCL, etc.). While a project could choose to run one API or another, I don't know if BOINC would be able to enumerate the devices properly. CUDA/OpenCL and CAL/OpenCL don't have a common data field in their APIs that contains the coprocessor type/id which would make it quite difficult for BOINC to know which device number is already in use. If not done as a subset of coproc types, then each time a new GPU is released, it would have to be mapped from one API to another and a new BOINC version built. Or would it? Jon Sonntag On Mon, Apr 15, 2013 at 5:29 PM, David Anderson <[email protected] <mailto:[email protected]>> wrote: I don't understand the following. Can you give me example of how you think the anonymous platform mechanism should be changed? -- David On 15-Apr-2013 3:04 PM, Raistmer the Sorcerer wrote: Not quite. It was just extrapolation. Current situation with "ATI" type is poor enough even w/o any additional accelerator types. BOINC treats 2 completely different GPU types (different API = different GPU type) as single one - "ATI". If stock app can solve this by app plan classes, anonymous platform app has no such possibility. "ATI" accelerator type does't discriminate between CAL and OpenCL APIs. Понедельник, 15 апреля 2013, 12:17 -07:00 от David Anderson <[email protected] <mailto:[email protected]>>: I think there's a misunderstanding. If AMD started selling a different type of coprocessor, we'd treat it as a new coprocessor type, not as an ATI GPU. -- David On 15-Apr-2013 1:28 AM, Raistmer wrote: > I would like to attract BOINC devs attention to this issue described here: > http://setiathome.berkeley.__edu/forum_thread.php?id=71192&__postid=1357117 <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] <mailto:[email protected]> <sentmsg?compose&To=boinc_dev@__ssl.berkeley.edu <mailto:[email protected]>> > http://lists.ssl.berkeley.edu/__mailman/listinfo/boinc_dev <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] <mailto:[email protected]> <sentmsg?compose&To=boinc_dev@__ssl.berkeley.edu <mailto:[email protected]>> http://lists.ssl.berkeley.edu/__mailman/listinfo/boinc_dev <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] <mailto:[email protected]> http://lists.ssl.berkeley.edu/__mailman/listinfo/boinc_dev <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.
