[Parallel_libs-commits] [PATCH] D25701: Initial check-in of Acxxel (StreamExecutor renamed)

Jason Henline via Parallel_libs-commits parallel_libs-commits at lists.llvm.org
Mon Oct 17 14:38:32 PDT 2016


jhen created this revision.
jhen added reviewers: jlebar, jprice.
jhen added a subscriber: parallel_libs-commits.
Herald added subscribers: modocache, mgorny, beanz.

Acxxel is basically a simplified redesign of StreamExecutor.

Here are the major points where Acxxel differs from the current StreamExecutor
design:

- Acxxel doesn't support the kernel and kernel loader types designed for emission by the compiler to support type-safe kernel launches. For CUDA, kernels in Acxxel can be seamlessly launched using the standard CUDA triple-chevron kernel launch syntax that is available with clang and nvcc. For OpenCL, kernel arguments will be passed in the old-fashioned way, as one array of pointers to arguments and another array of argument sizes. OpenCL does still get the benefit of all the memory management wrappers, and clang may add support for triple-chevron OpenCL kernel launches in the future.
- Acxxel has no fluent interface for Stream launches (i.e. Stream.Init().ThenThis().ThenThat()), but it still supports streams in a way that more closely matches the way it is done in OpenCL and the CUDA runtime library. This choice was made because the added complexity of adding kernel launch support to the fluent interface did not seem worth the benefit, and once kernel launches were not allowed, it was hard to build up strings of stream operations long enough to gain much benefit from the fluent interface. Furthermore, removing the fluent stream interface greatly simplifies error handling.
- Acxxel does not depend on any other code in LLVM, so it builds completely independently from LLVM.

Due to the shift in emphasis away from supporting type-safe kernel launches and
the movement of streams from being the central programming entities, it seemed
necessary to change the name of the project to something other than
StreamExecutor. The goal will be to check in Acxxel and remove StreamExecutor,
so I think Acxxel should be thought of as a new version of StreamExecutor, not
as a separate project.


https://reviews.llvm.org/D25701

Files:
  acxxel/.clang-format
  acxxel/.clang-tidy
  acxxel/CMakeLists.txt
  acxxel/Doxyfile.in
  acxxel/LICENSE.TXT
  acxxel/acxxel.cpp
  acxxel/acxxel.h
  acxxel/config.h.in
  acxxel/cuda_acxxel.cpp
  acxxel/customdoxygen.css
  acxxel/examples/CMakeLists.txt
  acxxel/examples/opencl_example.cpp
  acxxel/examples/simple_example.cu
  acxxel/fixed_vector.h
  acxxel/opencl_acxxel.cpp
  acxxel/span.h
  acxxel/status.h
  acxxel/tests/CMakeLists.txt
  acxxel/tests/acxxel_test.cpp
  acxxel/tests/opencl_test.cpp
  acxxel/tests/span_test.cpp
  acxxel/tests/status_test.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D25701.74906.patch
Type: text/x-patch
Size: 268532 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/parallel_libs-commits/attachments/20161017/9b38655b/attachment-0001.bin>


More information about the Parallel_libs-commits mailing list