[arrayfire] 37/61: interop tweaks temporarily remove external opencl context from interop tutorial. add cuda stream topic
Ghislain Vaillant
ghisvail-guest at moszumanska.debian.org
Tue Dec 8 11:55:08 UTC 2015
This is an automated email from the git hooks/post-receive script.
ghisvail-guest pushed a commit to branch dfsg-clean
in repository arrayfire.
commit 516c36e08bcd225b13f5d3568f5449ede1d9696e
Author: syurkevi <stefan at arrayfire.com>
Date: Tue Dec 1 18:15:25 2015 -0500
interop tweaks
temporarily remove external opencl context from interop tutorial.
add cuda stream topic
---
docs/pages/interop_cuda.md | 91 ++++++++++++++++++++++++++++++--------------
docs/pages/interop_opencl.md | 36 ++++--------------
2 files changed, 70 insertions(+), 57 deletions(-)
diff --git a/docs/pages/interop_cuda.md b/docs/pages/interop_cuda.md
index e20cf66..f2e4e39 100644
--- a/docs/pages/interop_cuda.md
+++ b/docs/pages/interop_cuda.md
@@ -1,7 +1,13 @@
Interoperability with CUDA {#interop_cuda}
========
-As extensive as ArrayFire is, there are a few cases where you are still working with custom [CUDA] (@ref interop_cuda) or [OpenCL] (@ref interop_opencl) kernels. For example, you may want to integrate ArrayFire into an existing code base for productivity or you may want to keep it around the old implementation for testing purposes. Arrayfire provides a number of functions that allow it to work alongside native CUDA commands. In this tutorial we are going to talk about how to use native C [...]
+As extensive as ArrayFire is, there are a few cases where you are still working
+with custom [CUDA] (@ref interop_cuda) or [OpenCL] (@ref interop_opencl) kernels.
+For example, you may want to integrate ArrayFire into an existing code base for
+productivity or you may want to keep it around the old implementation for testing
+purposes. Arrayfire provides a number of functions that allow it to work alongside
+native CUDA commands. In this tutorial we are going to talk about how to use native
+CUDA memory operations and integrate custom CUDA kernels into ArrayFire in a seamless fashion.
# In and Out of Arrayfire
@@ -15,8 +21,6 @@ int main() {
float *d_x = x.device<float>();
float *d_y = y.device<float>();
- af::sync();
-
// Launch kernel to do the following operations
// y = sin(x)^2 + cos(x)^2
launch_simple_kernel(d_x, d_y, num);
@@ -34,36 +38,45 @@ int main() {
## Breakdown
Most kernels require an input. In this case, we created a random uniform array **x**.
-We also go ahead and prepare the output array. The necessary memory required is allocated in array **y** before the kernel launch.
+We also go ahead and prepare the output array.
+The necessary memory required is allocated in array **y** before the kernel launch.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
af::array x = randu(num);
af::array y = randu(num);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-In this example, the output is the same size as in the input. Note that the actual output data type is not specified. For such cases, ArrayFire assumes the data type is single precision floating point ( af::f32 ). If necessary, the data type can be specified at the end of the array(..) constructor. Once you have the input and output arrays, you will need to extract the device pointers / objects using array::device() method in the following manner.
+In this example, the output is the same size as in the input. Note that the actual
+output data type is not specified. For such cases, ArrayFire assumes the data type
+is single precision floating point ( af::f32 ). If necessary, the data type can
+be specified at the end of the array(..) constructor. Once you have the input and
+output arrays, you will need to extract the device pointers / objects using
+array::device() method in the following manner.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
float *d_x = x.device<float>();
float *d_y = y.device<float>();
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Accesing the device pointer in this manner internally sets a flag prohibiting the arrayfire object from further managing the memory. Ownership will need to be returned to the af::array object once we are finished using it.
+Accesing the device pointer in this manner internally sets a flag prohibiting the
+arrayfire object from further managing the memory. Ownership will need to be
+returned to the af::array object once we are finished using it.
-Before launching your custom kernel, it is best to make sure that all ArrayFire computations have finished. This can be called by using af::sync(). The function ensures you are not unintentionally doing out of order executions.
-af::sync() is not strictly required if you are not using streams in CUDA.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
- af::sync();
-
// Launch kernel to do the following operations
// y = sin(x)^2 + cos(x)^2
launch_simple_kernel(d_x, d_y, num);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The function **launch_simple_kernel** handles the launching of your custom kernel. We will have a look at how to do this in CUDA and OpenCL later in the post.
+The function **launch_simple_kernel** handles the launching of your custom kernel.
+We will have a look at how to do this in CUDA later in the post.
-Once you have finished your computations, you have to tell ArrayFire to take control of the memory objects.
+Once you have finished your computations, you have to tell ArrayFire to take
+control of the memory objects.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
x.unlock();
y.unlock();
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-This is a very crucial step as ArrayFire believes the user is still in control of the pointer. This means that ArrayFire will not perform garbage collection on these objects resulting in memory leaks. You can now proceed with the rest of the program. In our particular example, we are just performing an error check and exiting.
+This is a very crucial step as ArrayFire believes the user is still in control
+of the pointer. This means that ArrayFire will not perform garbage collection on
+these objects resulting in memory leaks. You can now proceed with the rest of the program.
+In our particular example, we are just performing an error check and exiting.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
// check for errors, should be 0,
@@ -73,7 +86,34 @@ This is a very crucial step as ArrayFire believes the user is still in control o
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Launching a CUDA kernel
-Integrating a CUDA kernel into your ArrayFire code base is a fairly straightforward process. You need to set the launch configuration parameters, launch the kernel and wait for the computations to finish. This is shown below.
+Arrayfire provides a collection of CUDA interoperability functions for additional
+capabilities when working with custom CUDA code. To use them, we need to include
+the appropriate header.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+#include <af/cuda.h>
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The first thing these headers allow us to do are to get and set the active device
+using native CUDA device ids. This is achieved through the following functions:
+> **static int getNativeId (int id)**
+> -- Get the native device id of the CUDA device with id in the ArrayFire context.
+
+> **static void setNativeId (int nativeId)**
+> -- Set the CUDA device with given native id as the active device for ArrayFire.
+The headers also allow us to retrieve the CUDA stream used internally inside Arrayfire.
+> **static cudaStream_t afcu::getStream(int id)**
+> -- Get the stream for the CUDA device with id in ArrayFire context.
+These functions are available within the afcu:: namespace and equal C variants
+can be fund in the full [cuda interop documentation.](\ref cuda_mat.htm)
+
+To integrate a CUDA kernel into an ArrayFire code base, we first need to get the
+CUDA stream associated with arrayfire. Once we have this stream, we need to make
+sure Arrayfire is done with all computation before we can call our custom kernel
+to avoid out of order execution. We can do this with some variant of
+**cudaStreamQuery(af_stream)** or **cudaStreamSynchronize(af_stream)** or instead,
+we could add our kernel launch to Arrayfire's stream as shown below. Once we get
+the associated stream, all that is left is setting up the usual launch configuration
+parameters, launching the kernel and wait for the computations to finish:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
__global__
@@ -95,24 +135,17 @@ void inline launch_simple_kernel(float *d_y,
const float *d_x,
const int num)
{
+ // Get Arrayfire's internal CUDA stream
+ int af_id = af::getDevice();
+ cudaStream_t af_stream = afcu::getStream(af_id);
+
// Set launch configuration
const int threads = 256;
const int blocks = (num / threads) + ((num % threads) ? 1 : 0);
- simple_kernel<<<blocks, threads>>>(d_y, d_x, num);
- // Synchronize and check for error
- cudaDeviceSynchronize();
-}
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-# Additional interop functions and CUDA Streams
-
-Arrayfire provides a collection of CUDA interoperability functions for additional capabilities when working with custom CUDA code. To use them, we need to include the appropriate header.
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
-#include <af/cuda.h>
+ // execute kernel on Arrayfire's stream,
+ // ensuring all previous arrayfire operations complete
+ simple_kernel<<<blocks, threads, 0, af_stream>>>(d_y, d_x, num);
+}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The first thing these headers allow us to do are to get and set the active device using native CUDA device ids. This is achieved through the following functions:
- **static int getNativeId (int id)** -- Get the native device id of the CUDA device with id in the ArrayFire context.
- **static void setNativeId (int nativeId)** -- Set the CUDA device with given native id as the active device for ArrayFire.
-
-These functions are available within the afcu:: namespace and equal C variants can be fund in the full [cuda interop documentation.](group__cuda__mat.htm)
diff --git a/docs/pages/interop_opencl.md b/docs/pages/interop_opencl.md
index 2b81972..6e270a9 100644
--- a/docs/pages/interop_opencl.md
+++ b/docs/pages/interop_opencl.md
@@ -22,8 +22,6 @@ int main() {
float *d_x = x.device<float>();
float *d_y = y.device<float>();
- af::sync();
-
// Launch kernel to do the following operations
// y = sin(x)^2 + cos(x)^2
launch_simple_kernel(d_x, d_y, num);
@@ -62,12 +60,7 @@ Accesing the device pointer in this manner internally sets a flag prohibiting
the arrayfire object from further managing the memory. Ownership will need to be
returned to the af::array object once we are finished using it.
-Before launching your custom kernel, it is best to make sure that all ArrayFire
-computations have finished. This can be called by using af::sync(). The function
-ensures you are not unintentionally doing out of order executions.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
- af::sync();
-
// Launch kernel to do the following operations
// y = sin(x)^2 + cos(x)^2
launch_simple_kernel(d_x, d_y, num);
@@ -152,10 +145,9 @@ We start to use these functions by getting Arrayfire's context and queue. For th
C++ api, a **true** flag must be passed for the retain parameter which calls the
clRetainQueue() and clRetainContext() functions before returning. This allows us
to use Arrayfire's internal OpenCL structures inside of the cl::Context and
-cl::CommandQueue objects from the C++ api.
-Once we have them, we can proceed to set up and enqueue the kernel like we would
-in any other OpenCL program. The kernel we are using is actually simple and can
-be seen below.
+cl::CommandQueue objects from the C++ api. Once we have them, we can proceed to
+set up and enqueue the kernel like we would in any other OpenCL program.
+The kernel we are using is actually simple and can be seen below.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
std::string CONST_KERNEL_STRING = R"(
@@ -178,21 +170,9 @@ void simple_kernel(__global float *d_y,
# Reversing the workflow: Arrayfire arrays from OpenCL Memory
-Arrayfire's interoperability functions don't limit us to working with memory
-managed by Arrayfire. We could take the reverse route and start with completely
-custom OpenCL code, then transfer our results into an af::array object. This is
-done rather simply with a special set of construction functions.
-
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
-cl::Buffer my_cl_buffer(context, CL_MEM_READ_WRITE, sizeof(float) * SIZE);
-//work and computations with OpenCL buffer
-
-//kernel(my_cl_buffer, queue);
+Unfortunately, Arrayfire's interoperability functions don't yet allow us to work with
+external OpenCL contexts. This is currently an open issue and can be tracked here:
+https://github.com/arrayfire/arrayfire/issues/1002
+Once the issue is addressed, it will be possible to take the reverse route and start with
+completely custom OpenCL code, then transfer our results into af::array objects.
-//construct af::array from OpenCL buffer
-af::array my_array = afcl::array(SIZE, my_cl_buffer(), f32);
-af_print(my_array);
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Please note: the \ref af::array constructors are not thread safe.
-You may create and upload data to `cl_mem` objects from separate threads,
-but the thread which instantiated ArrayFire must do the `cl_mem` to \ref af::array conversion.
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/debian-science/packages/arrayfire.git
More information about the debian-science-commits
mailing list