<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I agree with what Hal wrote and irrespective of whether I'm
developing on OS X, iOS or Linux dealing with more hoops with a
cross-platform, platform agnostic language that OpenCL intended to
be, only to see it turn into a check list box ala OpenGL seems
detrimental to its success overall. It seems to me that ARM, Intel,
Apple, ImgTec and others would want to make it as painless as
possible.<br>
<br>
Just my 2 cents.<br>
<br>
- Marc<br>
<br>
On 08/08/2012 07:26 AM, Hal Finkel wrote:
<blockquote cite="mid:20120808092640.44e5eb96@sapling2" type="cite">
<pre wrap="">On Tue, 7 Aug 2012 23:40:32 +0100
"Anton Lokhmotov" <a class="moz-txt-link-rfc2396E" href="mailto:Anton.Lokhmotov@arm.com"><Anton.Lokhmotov@arm.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Phillip,
</pre>
<blockquote type="cite">
<pre wrap="">I'm trying to determine with some precision how much of OpenCL/C is
currently implemented by Clang? I find scattered posts and
references to simple examples and submissions/patches but nothing
comprehensive. Wouldn't something along the lines of the C++11
status webpage be useful?
</pre>
</blockquote>
<pre wrap="">
Having an OpenCL C 'dashboard' is an interesting idea. The question
is who is going to compile and maintain it, and according to which
criteria.
At ARM, we have several hundred OpenCL-specific tests (many of which
have combinatorial coverage leading to thousands of tests). Our
Clang-based frontend passes all the tests but relies on a large
number of patches to mainline Clang. Out of interest, we could
disable our patches and measure the pass rate (the number of tests
that would still pass divided by the number of all tests). I could
even tell you what the pass rate was for broadly defined categories
of tests, but I'm not sure how useful that would be without showing
you the actual tests...
</pre>
<blockquote type="cite">
<pre wrap="">It seems that a clear description of what is and isn't currently
implemented would save redundant effort of people trying to figure
this out and help converge on a complete implementation by focusing
would-be contributors on what remains.
</pre>
</blockquote>
<pre wrap="">
IMO, any efforts on implementing OpenCL C features that are currently
missing from Clang should better be used on reviewing. ARM, Intel
and Apple already have fully conformant implementations, and are all
willing to contribute their patches to mainline Clang.
</pre>
</blockquote>
<pre wrap="">
I understand what you're saying, but there is something about this that
seems immensely silly. Not only are the three of you (if not others)
duplicating work, but the result is less-than-complete public tools
environment for dealing with OpenCL codes. A number of us in
high-performance computing are deeply concerned about fighting vendor
lock-in with accelerator-based codes, and use of OpenCL over other
proprietary languages would be a great step in the right direction.
Unfortunately, the largest force directing new codes toward proprietary
languages is the enhanced tool support for those languages (driven by
their currently-larger market share). To increase the use of OpenCL we
need to lower the barrier of entry for OpenCL-capable tools, and making
the open-source version of clang fully compliant would be a huge step
in the right direction.
-Hal
</pre>
<blockquote type="cite">
<pre wrap="">It's just
that the implementers and the reviewers have limited bandwidth and
somewhat misaligned priorities. For example, I may want to
open-source code for a feature that's particularly painful to
maintain first, but even fellow implementers may not be interested in
this feature if supporting this feature is optional...
So, if you are interested in improving OpenCL C support in Clang, I
suggest you request a particular feature that you need via this list,
and we will try to respond quickly with a patch for that feature. In
this way, both the implementer and the reviewer will be perfectly
aligned in their desire to see support for this feature in mainline,
which should lead to faster review cycles and acceptance decisions.
We can even populate the dashboard as we go, marking features that
are deemed complete.
Does it make sense?
Best regards,
Anton.
_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
Marc J. Driftmeyer<br>
Email :: <a href="mailto:mjd@reanimality.com">mjd@reanimality.com</a><br>
Web :: <a href="http://www.reanimality.com">http://www.reanimality.com</a><br>
Cell :: (509) 435-5212
</div>
</body>
</html>