Commit Graph

2 Commits

Author SHA1 Message Date
Jason Henline bdc410baba [Acxxel] Remove setActiveDeviceForThread
Summary:
After experimenting with CUDA, I realized that we really only need to
set the active context right before creating an object such as a stream
or a device memory allocation. When we go on to use these objects later,
it is fine if the context that created them is no longer active,
operations with those objects will succeed anyway.

Since it turns out that we don't have to check the active context for
every operation, it makes sense to hide this active context from users
(by removing the "ActiveDeviceForThread" setter and getter) and to
change the Acxxel API to explicitly pass in the device ID to create
objects.

This change improves the Acxxel API and greatly simplifies the CUDA and
OpenCL implementations because they no longer require thread_local data.

Reviewers: jlebar, jprice

Subscribers: mgorny, parallel_libs-commits

Differential Revision: https://reviews.llvm.org/D26050

llvm-svn: 285372
2016-10-28 00:54:02 +00:00
Jason Henline ac232ddc23 Initial check-in of Acxxel (StreamExecutor renamed)
Summary:
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 CUDA and OpenCL, kernel arguments can be passed in the
  old-fashioned way, as one array of pointers to arguments and another
  array of argument sizes. Although OpenCL doesn't get a type-safe
  kernel launch method, it does still get the benefit of all the memory
  management wrappers. In the future, clang may add support for
  triple-chevron OpenCL kernel launchs, or some other type-safe OpenCL
  kernel launch method.
* Acxxel does not depend on any other code in LLVM, so it builds
  completely independently from LLVM.

The goal will be to check in Acxxel and remove StreamExecutor, or
perhaps to remove the old StreamExecutor and rename Acxxel to
StreamExecutor, so I think Acxxel should be thought of as a new version
of StreamExecutor, not as a separate project.

Reviewers: jlebar, jprice

Subscribers: beanz, mgorny, modocache, parallel_libs-commits

Differential Revision: https://reviews.llvm.org/D25701

llvm-svn: 285111
2016-10-25 20:18:56 +00:00