"So, it isn't about the vendor, it is about the API (CUDA, CAL, Brook+,
OpenCL, etc.)."
EXACTLY! Vendor name means nothing for app that calls corresponding API
functions to use device. It's API that matters.
And CAL API completely differs from OpenCL API. And make both GPU to be of same
type ("ATI") (hence, to launch same app on both GPUs) is logical error. Hence
=> BOINC has big design flaw currently.
Понедельник, 15 апреля 2013, 18:00 -05:00 от Jon Sonntag <[email protected]>:
>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] >
>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] >:
>>>
>>> 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
>>> >
>>> > 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] <sentmsg?compose&To= boinc_dev@
>>>ssl.berkeley.edu >
>>>
>>> > 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] <sentmsg?compose&To= boinc_dev@
>>>ssl.berkeley.edu >
>>>
>>> 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.
_______________________________________________
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.
