(6546,17796,'2014-09-05 18:21:14','2014-09-05 18:21:14','Triangle counting is a building block for many social analytics, especially for the widely used clustering coefficient analytic. Clustering coefficients is used for finding key players in a network based on their local connectivity which is expressed based on the number of triangles that they belong to. There are many ways for finding the triangles a vertex may belong to. One of the most popular approaches for finding the triangles, is to do an intersection of two adjacency lists. If a pair of vertices <em>(u,v) </em>have any common neighbors, these will be found in the intersection process.\r\n\r\nWhile the above may sound simple, implementing an efficient intersection on the GPU is not trivial or straightforward and requires smart partitioning of the work to make full use of the thousands of available threads that modern GPUs have. We just finished such an implementation that has multiple levels of parallelism which partitions the work to the multiprocessors and to the SIMT units.\r\n\r\nFor testing purposes, we used graphs taken from the <a href=\"http://www.cc.gatech.edu/dimacs10/\">DIMACS 10 Graph Challenge</a>. Our experiments were conducted on NVIDIA\'s K40 GPU. Our GPU triangle counting implementation achieves speedups in the range of $9X-32X$ over a CPU sequential implementation. These can be seen in the figure below.\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\n<a href=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu1.png\"><img class=\"alignnone wp-image-6544 size-full\" src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu1.png\" alt=\"gpu\" width=\"569\" height=\"286\" /></a>\r\n\r\n&nbsp;','Triangle Counting in Graphs On the GPU (Part 1)','','inherit','open','open','','6539-revision-v1','','','2014-09-05 18:21:14','2014-09-05 18:21:14','',6539,'http://sandbox.arrayfire.com/6539-revision-v1/',0,'revision','',0),(6550,17729,'2014-09-08 15:46:05','2014-09-08 15:46:05','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by Khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nLet\'s dive into the details now.\r\n\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following:\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\nOur next step is to abstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, \r\n<pre>\r\ntemplate<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);\r\n</pre>\r\nthe program\'s main body will look like the following:\r\n<pre>\r\nint main(int argc, char* argv[]) {\r\n    Context(CL_DEVICE_TYPE_GPU);\r\n\r\n    static const unsigned elements = 32;\r\n    vector<float> data(elements, 5);\r\n    vector<float> result(elements);\r\n    \r\n    addVectors<float>(result, data, data, elements);\r\n\r\n    vector<int> data2(elements, 5);\r\n    vector<int> result2(elements);\r\n\r\n    addVectors<int>(result2, data2, data2, elements);\r\n\r\n    // we shouldn\'t see any compile msgs for the below calls.\r\n    for(int i=0; i<100; ++i) {\r\n	addVectors<float>(result, data, data, elements);\r\n	addVectors<int>(result2, data2, data2, elements);\r\n    }\r\n\r\n    return 0;\r\n}\r\n</pre>\r\n\r\nNow, we are ready to work on the code that compiles our kernel source and enqueues it on the device. We shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a> to ensure single run time kernel compilation per data type. The body of the function <code>addVectors</code> will look like the following:\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n    static std::once_flag	compileFlag;\r\n\r\n    static cl::Program		addProg;\r\n    static cl::Kernel		addkernel;\r\n\r\n    std::call_once(compileFlag, []() {\r\n    	std::string kern = \"__kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n    	std::ostringstream options;\r\n    	options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n    	addProg		= cl::Program(kern, false);\r\n    	addProg.build(options.str().c_str());\r\n    	std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n    	addkernel	= cl::Kernel(addProg, \"add\");\r\n    });\r\n\r\n    Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n    auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n    cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types; more complicated algorithms would require further modifications to this sample.','Templating and Caching OpenCL Kernels','','publish','open','open','','templating-and-caching-opencl-kernels','','\nhttp://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/','2014-09-08 15:54:33','2014-09-08 15:54:33','',0,'http://sandbox.arrayfire.com/?p=6550',0,'post','',2),(6551,17729,'2014-09-08 01:15:44','2014-09-08 01:15:44','About a month ago, one of my colleagues has posted a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">blog</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. The sample code provided in that post definitely addresses the question at hand, however applying the new tricks that we have learned in real world applications is a completely different problem. \r\n\r\nIn today\'s post, we will be looking at one such situation which is most often encountered by library/middleware programmers. While programming using OpenCL, we often find ourselves in situations where the application needs to compile the kernels once and reuse the built binary later for different data types or different data sets. To reuse the same kernels for different data types, we would have to do some extra steps while building the kernel source itself. We will also take the help of C++ template programming to certain extent though the OpenCL compilers themselves doesn\'t support templates. Let\'s dive into the details now, we will modify the code sample from <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">this</a> blog to serve our purpose.\r\n\r\n<h4>First Step</h4>\r\nDeclare a struct with static method <code>getName</code> and add template specializations for the types you want your kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The corresponding code snippet will look as below.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a single <code>addVectors</code> function call. If <code>addVectors</code> has the following function signature <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nThere are two things we need to make sure during this stage.\r\n<ul>\r\n<li>Kernel should work out of the box with different data types</li>\r\n<li> Compile the kernels only once</li>\r\n</ul>\r\n\r\nThe first goal can be achieved by passing a compile option <code>-D T <typename></code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single time kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>. It is a fancy and secure way to do the task at hand. It is fancy because similar execution pattern can be achieved using a static boolean in a single threaded environment. It is secure because the code encapsulated by <code>std::call_once</code> works fine even in multi-threaded environment as per the documentation.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThe complete code sample is available <a href=\"\">here</a>.','Not sure abt it yet!','','inherit','open','open','','6550-revision-v1','','','2014-09-08 01:15:44','2014-09-08 01:15:44','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6552,17729,'2014-09-08 01:18:38','2014-09-08 01:18:38','About a month ago, one of my colleagues has posted a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">blog</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. The sample code provided in that post definitely addresses the question at hand, however applying the new tricks that we have learned in real world applications is a completely different problem. \r\n\r\nIn today\'s post, we will be looking at one such situation which is most often encountered by library/middleware programmers. While programming using OpenCL, we often find ourselves in situations where the application needs to compile the kernels once and reuse the built binary later for different data types or different data sets. To reuse the same kernels for different data types, we would have to do some extra steps while building the kernel source itself. We will also take the help of C++ template programming to certain extent though the OpenCL compilers themselves doesn\'t support templates. Let\'s dive into the details now, we will modify the code sample from <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">this</a> blog to serve our purpose.\r\n\r\n<h4>First Step</h4>\r\nDeclare a struct with static method <code>getName</code> and add template specializations for the types you want your kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The corresponding code snippet will look as below.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a single <code>addVectors</code> function call. If <code>addVectors</code> has the following function signature <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nThere are two things we need to make sure during this stage.\r\n<ul>\r\n<li>Kernel should work out of the box with different data types</li>\r\n<li> Compile the kernels only once</li>\r\n</ul>\r\n\r\nThe first goal can be achieved by passing a compile option <code>-D T \\<typename\\></code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single time kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>. It is a fancy and secure way to do the task at hand. It is fancy because similar execution pattern can be achieved using a static boolean in a single threaded environment. It is secure because the code encapsulated by <code>std::call_once</code> works fine even in multi-threaded environment as per the documentation.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThe complete code sample is available <a href=\"\">here</a>.','Not sure abt it yet!','','inherit','open','open','','6550-revision-v1','','','2014-09-08 01:18:38','2014-09-08 01:18:38','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6553,17729,'2014-09-08 01:18:59','2014-09-08 01:18:59','About a month ago, one of my colleagues has posted a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">blog</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. The sample code provided in that post definitely addresses the question at hand, however applying the new tricks that we have learned in real world applications is a completely different problem. \r\n\r\nIn today\'s post, we will be looking at one such situation which is most often encountered by library/middleware programmers. While programming using OpenCL, we often find ourselves in situations where the application needs to compile the kernels once and reuse the built binary later for different data types or different data sets. To reuse the same kernels for different data types, we would have to do some extra steps while building the kernel source itself. We will also take the help of C++ template programming to certain extent though the OpenCL compilers themselves doesn\'t support templates. Let\'s dive into the details now, we will modify the code sample from <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">this</a> blog to serve our purpose.\r\n\r\n<h4>First Step</h4>\r\nDeclare a struct with static method <code>getName</code> and add template specializations for the types you want your kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The corresponding code snippet will look as below.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a single <code>addVectors</code> function call. If <code>addVectors</code> has the following function signature <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nThere are two things we need to make sure during this stage.\r\n<ul>\r\n<li>Kernel should work out of the box with different data types</li>\r\n<li> Compile the kernels only once</li>\r\n</ul>\r\n\r\nThe first goal can be achieved by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single time kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>. It is a fancy and secure way to do the task at hand. It is fancy because similar execution pattern can be achieved using a static boolean in a single threaded environment. It is secure because the code encapsulated by <code>std::call_once</code> works fine even in multi-threaded environment as per the documentation.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThe complete code sample is available <a href=\"\">here</a>.','Not sure abt it yet!','','inherit','open','open','','6550-revision-v1','','','2014-09-08 01:18:59','2014-09-08 01:18:59','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6554,17729,'2014-09-08 01:21:21','2014-09-08 01:21:21','About a month ago, one of my colleagues has posted a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">blog</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. The sample code provided in that post definitely addresses the question at hand, however applying the new tricks that we have learned in real world applications is a completely different problem. \r\n\r\nIn today\'s post, we will be looking at one such situation which is most often encountered by library/middleware programmers. While programming using OpenCL, we often find ourselves in situations where the application needs to compile the kernels once and reuse the built binary later for different data types or different data sets. To reuse the same kernels for different data types, we would have to do some extra steps while building the kernel source itself. We will also take the help of C++ template programming to certain extent though the OpenCL compilers themselves doesn\'t support templates. Let\'s dive into the details now, we will modify the code sample from <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">this</a> blog to serve our purpose.\r\n\r\n<h4>First Step</h4>\r\nDeclare a struct with static method <code>getName</code> and add template specializations for the types you want your kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The corresponding code snippet will look as below.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a single <code>addVectors</code> function call. If <code>addVectors</code> has the following function signature <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nThere are two things we need to make sure during this stage.\r\n<ul>\r\n<li>Kernel should work out of the box with different data types</li>\r\n<li> Compile the kernels only once</li>\r\n</ul>\r\n\r\nThe first goal can be achieved by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single time kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>. It is a fancy and secure way to do the task at hand. It is fancy because similar execution pattern can be achieved using a static boolean in a single threaded environment. It is secure because the code encapsulated by <code>std::call_once</code> works fine even in multi-threaded environment as per the documentation.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThe complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>.','Not sure abt it yet!','','inherit','open','open','','6550-revision-v1','','','2014-09-08 01:21:21','2014-09-08 01:21:21','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6555,17729,'2014-09-08 01:36:57','2014-09-08 01:36:57','About a month ago, one of my colleagues has posted a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">blog</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. The sample code provided in that post definitely addresses the question at hand, however applying the new tricks that we have learned in real world applications is a completely different problem. \r\n\r\nIn today\'s post, we will be looking at one such situation which is most often encountered by library/middleware programmers. While programming using OpenCL, we often find ourselves in situations where the application needs to compile the kernels once and reuse the built binary later for different data types or different data sets. To reuse the same kernels for different data types, we would have to do some extra steps while building the kernel source itself. We will also take the help of C++ template programming to certain extent though the OpenCL compilers themselves doesn\'t support templates. Let\'s dive into the details now, we will modify the code sample from <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">this</a> blog to serve our purpose.\r\n\r\n<h4>First Step</h4>\r\nDeclare a struct with static method <code>getName</code> and add template specializations for the types you want your kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The corresponding code snippet will look as below.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a single <code>addVectors</code> function call. If <code>addVectors</code> has the following function signature <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nThere are two things we need to make sure during this stage.\r\n<ul>\r\n<li>Kernel should work out of the box with different data types</li>\r\n<li> Compile the kernels only once</li>\r\n</ul>\r\n\r\nThe first goal can be achieved by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single time kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>. It is a fancy and secure way to do the task at hand. It is fancy because similar execution pattern can be achieved using a static boolean in a single threaded environment. It is secure because the code encapsulated by <code>std::call_once</code> works fine even in multi-threaded environment as per the documentation.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThe complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>.','Templating OpenCL kernels with Single Runtime compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 01:36:57','2014-09-08 01:36:57','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6556,17729,'2014-09-08 01:49:17','2014-09-08 01:49:17','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at runtime</li>\r\n</ol>\r\nThe whole sample code required to achieve our goals will be split and explained in three steps.\r\n\r\n<h4>First Step</h4>\r\nDeclare a struct with static method <code>getName</code> and add template specializations for the types you want your kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The corresponding code snippet will look as below.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a single <code>addVectors</code> function call. If <code>addVectors</code> has the following function signature <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nThere are two things we need to make sure during this stage.\r\n<ul>\r\n<li>Kernel should work out of the box with different data types</li>\r\n<li> </li>\r\n</ul>\r\n\r\nThe first goal can be achieved by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single time kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>. It is a fancy and secure way to do the task at hand. It is fancy because similar execution pattern can be achieved using a static boolean in a single threaded environment. It is secure because the code encapsulated by <code>std::call_once</code> works fine even in multi-threaded environment as per the documentation.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThe complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>.','Templating OpenCL kernels with Single Runtime compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 01:49:17','2014-09-08 01:49:17','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6557,17729,'2014-09-08 01:51:31','2014-09-08 01:51:31','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at runtime</li>\r\n</ol>\r\nTo better understand the whole sample code required to achieve our goals, we shall split and explain it in three steps.\r\n<h4>First Step</h4>\r\nDeclare a struct with static method <code>getName</code> and add template specializations for the types you want your kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The corresponding code snippet will look as below.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a single <code>addVectors</code> function call. If <code>addVectors</code> has the following function signature <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nThere are two things we need to make sure during this stage.\r\n<ul>\r\n<li>Kernel should work out of the box with different data types</li>\r\n<li> </li>\r\n</ul>\r\n\r\nThe first goal can be achieved by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single time kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>. It is a fancy and secure way to do the task at hand. It is fancy because similar execution pattern can be achieved using a static boolean in a single threaded environment. It is secure because the code encapsulated by <code>std::call_once</code> works fine even in multi-threaded environment as per the documentation.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThe complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>.','Templating OpenCL kernels with Single Runtime compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 01:51:31','2014-09-08 01:51:31','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6558,17729,'2014-09-08 01:52:34','2014-09-08 01:52:34','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at runtime</li>\r\n</ol>\r\nTo better understand the whole sample code required to achieve our goals, we shall split and explain it in three steps.\r\n<h4>First Step</h4>\r\nDeclare a struct with static method <code>getName</code> and add template specializations for the types you want your kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The corresponding code snippet will look as below.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a single <code>addVectors</code> function call. If <code>addVectors</code> has the following function signature <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nThere are two things we need to make sure during this stage.\r\n<ul>\r\n<li>Kernel should work out of the box with different data types</li>\r\n<li> </li>\r\n</ul>\r\n\r\nThe first goal can be achieved by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single time kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>. It is a fancy and secure way to do the task at hand. It is fancy because similar execution pattern can be achieved using a static boolean in a single threaded environment. It is secure because the code encapsulated by <code>std::call_once</code> works fine even in multi-threaded environment as per the documentation.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThe complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 01:52:34','2014-09-08 01:52:34','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6559,17729,'2014-09-08 01:59:08','2014-09-08 01:59:08','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at runtime</li>\r\n</ol>\r\nTo better understand the whole sample code required to achieve our goals, we shall split and explain it in three steps.\r\n<h4>First Step</h4>\r\nDeclare a struct with static method <code>getName</code> and add template specializations for the types you want your kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The corresponding code snippet will look as below.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a function, <code>addVectors</code>. If <code>addVectors</code> has the following function signature <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nWe can template the OpenCL kernels by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single runtime kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 01:59:08','2014-09-08 01:59:08','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6560,17729,'2014-09-08 01:59:48','2014-09-08 01:59:48','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nTo better understand the whole sample code required to achieve our goals, we shall split and explain it in three steps.\r\n<h4>First Step</h4>\r\nDeclare a struct with static method <code>getName</code> and add template specializations for the types you want your kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The corresponding code snippet will look as below.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a function, <code>addVectors</code>. If <code>addVectors</code> has the following function signature <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nWe can template the OpenCL kernels by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single runtime kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 01:59:48','2014-09-08 01:59:48','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6561,17729,'2014-09-08 02:09:27','2014-09-08 02:09:27','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nTo better understand the whole sample code required to achieve our goals, we shall split and explain it in three steps.\r\n<h4>First Step</h4>\r\nDeclare a struct with static method <code>getName</code> and add template specializations for the types you want your kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The corresponding code snippet will look as below.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nWe can template the OpenCL kernels by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single runtime kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 02:09:27','2014-09-08 02:09:27','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6562,17729,'2014-09-08 02:21:58','2014-09-08 02:21:58','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nTo better understand the whole sample code required to achieve our goals, we shall split and explain it in three steps.\r\n<h4>First Step</h4>\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options to the kernel build step, we would nee a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations would like as below.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nWe can template the OpenCL kernels by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single runtime kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 02:21:58','2014-09-08 02:21:58','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6563,17729,'2014-09-08 02:22:48','2014-09-08 02:22:48','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nTo better understand the whole sample code required to achieve our goals, we shall split and explain it in three steps.\r\n<h4>First Step</h4>\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations would like as below.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nWe can template the OpenCL kernels by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single runtime kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 02:22:48','2014-09-08 02:22:48','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6564,17729,'2014-09-08 02:23:34','2014-09-08 02:23:34','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nTo better understand the whole sample code required to achieve our goals, we shall split and explain it in three steps.\r\n<h4>First Step</h4>\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nWe can template the OpenCL kernels by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single runtime kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 02:23:34','2014-09-08 02:23:34','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6565,17729,'2014-09-08 02:25:01','2014-09-08 02:25:01','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nTo better understand the whole sample code required to achieve our goals, we shall split and explain it in three steps.\r\n\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nWe can template the OpenCL kernels by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single runtime kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 02:25:01','2014-09-08 02:25:01','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6566,17729,'2014-09-08 02:25:23','2014-09-08 02:25:23','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\n\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nWe can template the OpenCL kernels by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single runtime kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 02:25:23','2014-09-08 02:25:23','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6567,17729,'2014-09-08 02:25:50','2014-09-08 02:25:50','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nLet\'s dive into the details now.\r\n\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\n<h4>Second Step</h4>\r\nAbstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the main program body will turn out as below.\r\n<pre>\r\nContext(CL_DEVICE_TYPE_GPU);\r\n\r\nstatic const unsigned elements = 32;\r\nvector<float> data(elements, 5);\r\nvector<float> result(elements);\r\n    \r\naddVectors<float>(result, data, data, elements);\r\n\r\nvector<int> data2(elements, 5);\r\nvector<int> result2(elements);\r\n\r\naddVectors<int>(result2, data2, data2, elements);\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nWe can template the OpenCL kernels by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single runtime kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 02:25:50','2014-09-08 02:25:50','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6568,17729,'2014-09-08 02:29:36','2014-09-08 02:29:36','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nLet\'s dive into the details now.\r\n\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\nOur next step is to abstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, <code>template<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);</code>, the program\'s main body will look like the following.\r\n<pre>\r\nint main(int argc, char* argv[]) {\r\n    Context(CL_DEVICE_TYPE_GPU);\r\n\r\n    static const unsigned elements = 32;\r\n    vector<float> data(elements, 5);\r\n    vector<float> result(elements);\r\n    \r\n    addVectors<float>(result, data, data, elements);\r\n\r\n    vector<int> data2(elements, 5);\r\n    vector<int> result2(elements);\r\n\r\n    addVectors<int>(result2, data2, data2, elements);\r\n    return 0;\r\n}\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nWe can template the OpenCL kernels by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single runtime kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 02:29:36','2014-09-08 02:29:36','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6569,17729,'2014-09-08 02:31:05','2014-09-08 02:31:05','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nLet\'s dive into the details now.\r\n\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\nOur next step is to abstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, \r\n<pre>\r\ntemplate<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);\r\n</pre>\r\nthe program\'s main body will look like the following.\r\n<pre>\r\nint main(int argc, char* argv[]) {\r\n    Context(CL_DEVICE_TYPE_GPU);\r\n\r\n    static const unsigned elements = 32;\r\n    vector<float> data(elements, 5);\r\n    vector<float> result(elements);\r\n    \r\n    addVectors<float>(result, data, data, elements);\r\n\r\n    vector<int> data2(elements, 5);\r\n    vector<int> result2(elements);\r\n\r\n    addVectors<int>(result2, data2, data2, elements);\r\n    return 0;\r\n}\r\n</pre>\r\n\r\n<h4>Final and Crucial Step</h4>\r\nWe can template the OpenCL kernels by passing a compile option <code>-D T typename</code> to the kernel compilation step. The code written in Step 1 will help us out here. To understand how step 1 is helping step 3, look at the places where the variable <code>options</code> is being used in the below code snippet.\r\n\r\nTo ensure single runtime kernel compilation, we shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a>.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n	static std::once_flag	compileFlag;\r\n\r\n	static cl::Program		addProg;\r\n	static cl::Kernel		addkernel;\r\n\r\n	std::call_once(compileFlag, []() {\r\n		std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n		std::ostringstream options;\r\n		options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n		addProg		= cl::Program(kern, false);\r\n		addProg.build(options.str().c_str());\r\n		std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n\r\n		addkernel	= cl::Kernel(addProg, \"add\");\r\n	});\r\n\r\n	Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n	auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n	cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\n<h4>Conclusion</h4>\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 02:31:05','2014-09-08 02:31:05','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6570,17729,'2014-09-08 02:34:37','2014-09-08 02:34:37','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nLet\'s dive into the details now.\r\n\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\nOur next step is to abstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, \r\n<pre>\r\ntemplate<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);\r\n</pre>\r\nthe program\'s main body will look like the following.\r\n<pre>\r\nint main(int argc, char* argv[]) {\r\n    Context(CL_DEVICE_TYPE_GPU);\r\n\r\n    static const unsigned elements = 32;\r\n    vector<float> data(elements, 5);\r\n    vector<float> result(elements);\r\n    \r\n    addVectors<float>(result, data, data, elements);\r\n\r\n    vector<int> data2(elements, 5);\r\n    vector<int> result2(elements);\r\n\r\n    addVectors<int>(result2, data2, data2, elements);\r\n    return 0;\r\n}\r\n</pre>\r\n\r\nWe shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a> to ensure single run time kernel compilation per data type. The body of the function <code>addVectors</code> will look like the following.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n    static std::once_flag	compileFlag;\r\n\r\n    static cl::Program		addProg;\r\n    static cl::Kernel		addkernel;\r\n\r\n    std::call_once(compileFlag, []() {\r\n    	std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n    	std::ostringstream options;\r\n    	options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n    	addProg		= cl::Program(kern, false);\r\n    	addProg.build(options.str().c_str());\r\n    	std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n    	addkernel	= cl::Kernel(addProg, \"add\");\r\n    });\r\n\r\n    Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n    auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n    cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 02:34:37','2014-09-08 02:34:37','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6571,17729,'2014-09-08 02:36:38','2014-09-08 02:36:38','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nLet\'s dive into the details now.\r\n\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\nOur next step is to abstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, \r\n<pre>\r\ntemplate<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);\r\n</pre>\r\nthe program\'s main body will look like the following.\r\n<pre>\r\nint main(int argc, char* argv[]) {\r\n    Context(CL_DEVICE_TYPE_GPU);\r\n\r\n    static const unsigned elements = 32;\r\n    vector<float> data(elements, 5);\r\n    vector<float> result(elements);\r\n    \r\n    addVectors<float>(result, data, data, elements);\r\n\r\n    vector<int> data2(elements, 5);\r\n    vector<int> result2(elements);\r\n\r\n    addVectors<int>(result2, data2, data2, elements);\r\n    return 0;\r\n}\r\n</pre>\r\n\r\nNow, we are ready to work on the code that compiles our kernel source and enqueues it on the device. We shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a> to ensure single run time kernel compilation per data type. The body of the function <code>addVectors</code> will look like the following.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n    static std::once_flag	compileFlag;\r\n\r\n    static cl::Program		addProg;\r\n    static cl::Kernel		addkernel;\r\n\r\n    std::call_once(compileFlag, []() {\r\n    	std::string kern = \"kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n    	std::ostringstream options;\r\n    	options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n    	addProg		= cl::Program(kern, false);\r\n    	addProg.build(options.str().c_str());\r\n    	std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n    	addkernel	= cl::Kernel(addProg, \"add\");\r\n    });\r\n\r\n    Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n    auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n    cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 02:36:38','2014-09-08 02:36:38','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6573,17729,'2014-09-08 02:48:06','2014-09-08 02:48:06','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nLet\'s dive into the details now.\r\n\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\nOur next step is to abstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, \r\n<pre>\r\ntemplate<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);\r\n</pre>\r\nthe program\'s main body will look like the following.\r\n<pre>\r\nint main(int argc, char* argv[]) {\r\n    Context(CL_DEVICE_TYPE_GPU);\r\n\r\n    static const unsigned elements = 32;\r\n    vector<float> data(elements, 5);\r\n    vector<float> result(elements);\r\n    \r\n    addVectors<float>(result, data, data, elements);\r\n\r\n    vector<int> data2(elements, 5);\r\n    vector<int> result2(elements);\r\n\r\n    addVectors<int>(result2, data2, data2, elements);\r\n    return 0;\r\n}\r\n</pre>\r\n\r\nNow, we are ready to work on the code that compiles our kernel source and enqueues it on the device. We shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a> to ensure single run time kernel compilation per data type. The body of the function <code>addVectors</code> will look like the following.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n    static std::once_flag	compileFlag;\r\n\r\n    static cl::Program		addProg;\r\n    static cl::Kernel		addkernel;\r\n\r\n    std::call_once(compileFlag, []() {\r\n    	std::string kern = \"__kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n    	std::ostringstream options;\r\n    	options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n    	addProg		= cl::Program(kern, false);\r\n    	addProg.build(options.str().c_str());\r\n    	std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n    	addkernel	= cl::Kernel(addProg, \"add\");\r\n    });\r\n\r\n    Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n    auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n    cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating OpenCL kernels and Achieving Single Runtime Compilation','','inherit','open','open','','6550-revision-v1','','','2014-09-08 02:48:06','2014-09-08 02:48:06','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6574,17729,'2014-09-08 02:57:43','2014-09-08 02:57:43','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nLet\'s dive into the details now.\r\n\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following.\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\nOur next step is to abstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, \r\n<pre>\r\ntemplate<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);\r\n</pre>\r\nthe program\'s main body will look like the following.\r\n<pre>\r\nint main(int argc, char* argv[]) {\r\n    Context(CL_DEVICE_TYPE_GPU);\r\n\r\n    static const unsigned elements = 32;\r\n    vector<float> data(elements, 5);\r\n    vector<float> result(elements);\r\n    \r\n    addVectors<float>(result, data, data, elements);\r\n\r\n    vector<int> data2(elements, 5);\r\n    vector<int> result2(elements);\r\n\r\n    addVectors<int>(result2, data2, data2, elements);\r\n    return 0;\r\n}\r\n</pre>\r\n\r\nNow, we are ready to work on the code that compiles our kernel source and enqueues it on the device. We shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a> to ensure single run time kernel compilation per data type. The body of the function <code>addVectors</code> will look like the following.\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n    static std::once_flag	compileFlag;\r\n\r\n    static cl::Program		addProg;\r\n    static cl::Kernel		addkernel;\r\n\r\n    std::call_once(compileFlag, []() {\r\n    	std::string kern = \"__kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n    	std::ostringstream options;\r\n    	options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n    	addProg		= cl::Program(kern, false);\r\n    	addProg.build(options.str().c_str());\r\n    	std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n    	addkernel	= cl::Kernel(addProg, \"add\");\r\n    });\r\n\r\n    Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n    auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n    cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating and Caching OpenCL Kernels','','inherit','open','open','','6550-revision-v1','','','2014-09-08 02:57:43','2014-09-08 02:57:43','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6575,17729,'2014-09-08 15:41:02','2014-09-08 15:41:02','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by Khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nLet\'s dive into the details now.\r\n\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following:\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\nOur next step is to abstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, \r\n<pre>\r\ntemplate<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);\r\n</pre>\r\nthe program\'s main body will look like the following:\r\n<pre>\r\nint main(int argc, char* argv[]) {\r\n    Context(CL_DEVICE_TYPE_GPU);\r\n\r\n    static const unsigned elements = 32;\r\n    vector<float> data(elements, 5);\r\n    vector<float> result(elements);\r\n    \r\n    addVectors<float>(result, data, data, elements);\r\n\r\n    vector<int> data2(elements, 5);\r\n    vector<int> result2(elements);\r\n\r\n    addVectors<int>(result2, data2, data2, elements);\r\n    return 0;\r\n}\r\n</pre>\r\n\r\nNow, we are ready to work on the code that compiles our kernel source and enqueues it on the device. We shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a> to ensure single run time kernel compilation per data type. The body of the function <code>addVectors</code> will look like the following:\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n    static std::once_flag	compileFlag;\r\n\r\n    static cl::Program		addProg;\r\n    static cl::Kernel		addkernel;\r\n\r\n    std::call_once(compileFlag, []() {\r\n    	std::string kern = \"__kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n    	std::ostringstream options;\r\n    	options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n    	addProg		= cl::Program(kern, false);\r\n    	addProg.build(options.str().c_str());\r\n    	std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n    	addkernel	= cl::Kernel(addProg, \"add\");\r\n    });\r\n\r\n    Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n    auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n    cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types, more complicated algorithms would require further modifications to this sample.','Templating and Caching OpenCL Kernels','','inherit','open','open','','6550-revision-v1','','','2014-09-08 15:41:02','2014-09-08 15:41:02','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6576,17729,'2014-09-08 15:45:24','2014-09-08 15:45:24','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by Khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nLet\'s dive into the details now.\r\n\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following:\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\nOur next step is to abstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, \r\n<pre>\r\ntemplate<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);\r\n</pre>\r\nthe program\'s main body will look like the following:\r\n<pre>\r\nint main(int argc, char* argv[]) {\r\n    Context(CL_DEVICE_TYPE_GPU);\r\n\r\n    static const unsigned elements = 32;\r\n    vector<float> data(elements, 5);\r\n    vector<float> result(elements);\r\n    \r\n    addVectors<float>(result, data, data, elements);\r\n\r\n    vector<int> data2(elements, 5);\r\n    vector<int> result2(elements);\r\n\r\n    addVectors<int>(result2, data2, data2, elements);\r\n    return 0;\r\n}\r\n</pre>\r\n\r\nNow, we are ready to work on the code that compiles our kernel source and enqueues it on the device. We shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a> to ensure single run time kernel compilation per data type. The body of the function <code>addVectors</code> will look like the following:\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n    static std::once_flag	compileFlag;\r\n\r\n    static cl::Program		addProg;\r\n    static cl::Kernel		addkernel;\r\n\r\n    std::call_once(compileFlag, []() {\r\n    	std::string kern = \"__kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n    	std::ostringstream options;\r\n    	options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n    	addProg		= cl::Program(kern, false);\r\n    	addProg.build(options.str().c_str());\r\n    	std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n    	addkernel	= cl::Kernel(addProg, \"add\");\r\n    });\r\n\r\n    Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n    auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n    cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types; more complicated algorithms would require further modifications to this sample.','Templating and Caching OpenCL Kernels','','inherit','open','open','','6550-revision-v1','','','2014-09-08 15:45:24','2014-09-08 15:45:24','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6577,17729,'2014-09-08 15:53:04','2014-09-08 15:53:04','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by Khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \n<ol>\n<li>Enable the kernel to work with different integral data types out of the box</li>\n<li>Ensure that the kernels compile only once at run time per data type</li>\n</ol>\nLet\'s dive into the details now.\n\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following:\n<pre>\ntemplate<typename T> struct CLTypes {\n	static const char * getName() { return \"Unsupported\"; }\n};\n\ntemplate<> struct CLTypes<int> {\n	static const char * getName() { return \"int\"; }\n};\n\ntemplate<> struct CLTypes<float> {\n	static const char * getName() { return \"float\"; }\n};\n\ntemplate<> struct CLTypes<unsigned> {\n	static const char * getName() { return \"unsigned\"; }\n};\n</pre>\n\nOur next step is to abstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, \n<pre>\ntemplate<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);\n</pre>\nthe program\'s main body will look like the following:\n<pre>\nint main(int argc, char* argv[]) {\n    Context(CL_DEVICE_TYPE_GPU);\n\n    static const unsigned elements = 32;\n    vector<float> data(elements, 5);\n    vector<float> result(elements);\n    \n    addVectors<float>(result, data, data, elements);\n\n    vector<int> data2(elements, 5);\n    vector<int> result2(elements);\n\n    addVectors<int>(result2, data2, data2, elements);\n\n    // we shouldn\'t see any compile msgs for the below calls.\n    for(int i=0; i<100; ++i) {\n	addVectors<float>(result, data, data, elements);\n	addVectors<int>(result2, data2, data2, elements);\n    }\n\n    return 0;\n}\n</pre>\n\nNow, we are ready to work on the code that compiles our kernel source and enqueues it on the device. We shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a> to ensure single run time kernel compilation per data type. The body of the function <code>addVectors</code> will look like the following:\n<pre>\ntemplate<typename T>\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\n{\n    static std::once_flag	compileFlag;\n\n    static cl::Program		addProg;\n    static cl::Kernel		addkernel;\n\n    std::call_once(compileFlag, []() {\n    	std::string kern = \"__kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\n		\n    	std::ostringstream options;\n    	options<<\"-D T=\"<< CLTypes<T>::getName();\n\n    	addProg		= cl::Program(kern, false);\n    	addProg.build(options.str().c_str());\n    	std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\n    	addkernel	= cl::Kernel(addProg, \"add\");\n    });\n\n    Buffer a(begin(in1), end(in1), true, false);\n    Buffer b(begin(in2), end(in2), true, false);\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\n\n    auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\n		\n    addOp(EnqueueArgs(nElems), a, b, c);\n\n    cl::copy(c, begin(out), end(out));\n}\n</pre>\n\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types; more complicated algorithms would require further modifications to this sample.','Templating and Caching OpenCL Kernels','','inherit','open','open','','6550-autosave-v1','','','2014-09-08 15:53:04','2014-09-08 15:53:04','',6550,'http://sandbox.arrayfire.com/6550-autosave-v1/',0,'revision','',0),(6578,17729,'2014-09-08 15:54:33','2014-09-08 15:54:33','About a month ago, one of my colleagues did a <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">post</a> on how to author the most concise OpenCL program using the C++ API provided by Khronos. In today\'s post, we shall further modify that example to achieve the following two goals. \r\n<ol>\r\n<li>Enable the kernel to work with different integral data types out of the box</li>\r\n<li>Ensure that the kernels compile only once at run time per data type</li>\r\n</ol>\r\nLet\'s dive into the details now.\r\n\r\nWe can template the OpenCL kernels by passing a build option <code>-D T=\"typename\"</code> to the kernel compilation step. To pass such options, we would need a construct that can give us a string literal that represents the corresponding integral type. Let us declare a struct with static method <code>getName</code> and add template specializations for the types we want our kernel to handle. For our example, let\'s add specializations for <code>int</code>, <code>float</code> and <code>unsigned int</code>. The entire code snippet with struct declaration and template specializations should look like the following:\r\n<pre>\r\ntemplate<typename T> struct CLTypes {\r\n	static const char * getName() { return \"Unsupported\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<int> {\r\n	static const char * getName() { return \"int\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<float> {\r\n	static const char * getName() { return \"float\"; }\r\n};\r\n\r\ntemplate<> struct CLTypes<unsigned> {\r\n	static const char * getName() { return \"unsigned\"; }\r\n};\r\n</pre>\r\n\r\nOur next step is to abstract out the OpenCL related code into a function, <code>addVectors</code>. Given the following function signature for <code>addVectors</code>, \r\n<pre>\r\ntemplate<typename T> void addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems);\r\n</pre>\r\nthe program\'s main body will look like the following:\r\n<pre>\r\nint main(int argc, char* argv[]) {\r\n    Context(CL_DEVICE_TYPE_GPU);\r\n\r\n    static const unsigned elements = 32;\r\n    vector<float> data(elements, 5);\r\n    vector<float> result(elements);\r\n    \r\n    addVectors<float>(result, data, data, elements);\r\n\r\n    vector<int> data2(elements, 5);\r\n    vector<int> result2(elements);\r\n\r\n    addVectors<int>(result2, data2, data2, elements);\r\n\r\n    // we shouldn\'t see any compile msgs for the below calls.\r\n    for(int i=0; i<100; ++i) {\r\n	addVectors<float>(result, data, data, elements);\r\n	addVectors<int>(result2, data2, data2, elements);\r\n    }\r\n\r\n    return 0;\r\n}\r\n</pre>\r\n\r\nNow, we are ready to work on the code that compiles our kernel source and enqueues it on the device. We shall use the C++11 feature <a href=\"http://en.cppreference.com/w/cpp/thread/call_once\">std::call_once</a> to ensure single run time kernel compilation per data type. The body of the function <code>addVectors</code> will look like the following:\r\n<pre>\r\ntemplate<typename T>\r\nvoid addVectors(vector<T> &out, vector<T> &in1, vector<T> &in2, std::size_t nElems)\r\n{\r\n    static std::once_flag	compileFlag;\r\n\r\n    static cl::Program		addProg;\r\n    static cl::Kernel		addkernel;\r\n\r\n    std::call_once(compileFlag, []() {\r\n    	std::string kern = \"__kernel void add(global const T * const a, global const T * const b, global T * restrict const c) { unsigned idx = get_global_id(0); c[idx] = a[idx] + b[idx]; }\";\r\n		\r\n    	std::ostringstream options;\r\n    	options<<\"-D T=\"<< CLTypes<T>::getName();\r\n\r\n    	addProg		= cl::Program(kern, false);\r\n    	addProg.build(options.str().c_str());\r\n    	std::cout<<\"vector addition kernel compiled for type: \"<<CLTypes<T>::getName()<<std::endl;\r\n    	addkernel	= cl::Kernel(addProg, \"add\");\r\n    });\r\n\r\n    Buffer a(begin(in1), end(in1), true, false);\r\n    Buffer b(begin(in2), end(in2), true, false);\r\n    Buffer c(CL_MEM_READ_WRITE, nElems * sizeof(T));\r\n\r\n    auto addOp = cl::make_kernel<Buffer, Buffer, Buffer>(addkernel);\r\n		\r\n    addOp(EnqueueArgs(nElems), a, b, c);\r\n\r\n    cl::copy(c, begin(out), end(out));\r\n}\r\n</pre>\r\n\r\nThat is all that needs to be done for using the same kernel source with different data types and compiling them only once at run time per data type. The complete code sample is available <a href=\"https://gist.github.com/9prady9/848e7774c86a03febe4a\">here</a>. This sample is merely an example on how you can parametrize kernel source with respect to types; more complicated algorithms would require further modifications to this sample.','Templating and Caching OpenCL Kernels','','inherit','open','open','','6550-revision-v1','','','2014-09-08 15:54:33','2014-09-08 15:54:33','',6550,'http://sandbox.arrayfire.com/6550-revision-v1/',0,'revision','',0),(6581,17795,'2014-09-17 14:51:13','2014-09-17 14:51:13','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">recent post</a>, I showed how to generate PTX files from both CUDA and OpenCL kernels. In this post I will address the issue of how a PTX file look, and more importantly, how to understand all those complicated instructions in a PTX files.\r\nIn this post I will use the same vector addition kernel from the the previous post <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a> (the complete code can be found <a href=\"https://github.com/pentschev/ptxtract\">here</a>).\r\n\r\nFor this post, I will focus on OpenCL PTX file. In a future post I will discuss the differences between PTX files of OpenCL and CUDA code. Let\'s start by looking at the complete PTX code:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n    add.s32         %r10, %r8, %r5;\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nThe file starts with a header showing some compiler information in comments, followed by three lines containing the 1) PTX ISA version, 2) target architecture (compute capability), and 3) address-mode that will used.\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n</pre>\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name.\r\n\r\n<pre>\r\n.entry add_vectors(\r\n...\r\n)\r\n</pre>\r\n\r\nThe parameters for this kernel are three pointers to 32-bit integers global memory arrays (notice that there isn\'t a distinction from constant to non-constant pointers and memory!), and one 32-bit integer argument (the length of input and output vectors).\r\n\r\nEach parameter of a function starts with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case. In this example, the compiler transformed all the function parameters into 32-bit unsigned integers (for extended information on data types, refer to <a href=\"http://docs.nvidia.com/cuda/parallel-thread-execution/\">PTX ISA documentation</a>). The pointer arguments are followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space), and finally the data alignment  which specifies the alignment (in this case <code>.align 4</code> represents 4 bytes alignment).\r\n\r\n<pre>\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n</pre>\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type and its name (note that references to registers are always preceded by the <code>%</code> sign). Registers defined with the <code>.pred</code> directive are used for conditional assignments, such as in the case of branch instructions. Since PTX is an intermediary language, the registers defined are virtual and do not necessarily have a one-to-one translation to hardware registers. A set of virtual registers can be defined by including the number N of virtual registers inside <code>< ></code>, with them being addressable as <code>r0, r1, ..., rN-1</code>, when <code>r</code> is the name given to the set of registers.\r\n\r\n<pre>\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n</pre>\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register. Because the second argument is an address, it must be inside brackets, as in <code>[add_vectors_param_3]</code>. Copying the parameter to a register is necessary as most PTX instructions can not handle function parameters directly. \r\n\r\n<pre>\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n</pre>\r\n\r\nLater, the values of some special registers are copied to GPU registers, they are:\r\n<ul>\r\n<li><code>envreg3</code>: read-only driver-defined special register;</li>\r\n<li><code>ntid.x</code>: number of threads per CTA, Cooperative Thread Array, in x dimension, equivalent to get_local_size(0);</li>\r\n<li><code>ctaid.x</code>: identifier of CTA within a grid, equivalent to get_group_id(0);</li>\r\n<li><code>tid.x</code>: thread identifier in the x dimension of CTA, equivalent to get_local_id(0).</li>\r\n</ul>\r\n\r\n<pre>\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n</pre>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since <code>envreg3</code> is not directly part of the code, but instead a driver-specific computation, I will not go into more details about it (note that <code>envreg</code> does not appear in PTX of the equivalent CUDA kernel).\r\n\r\n<pre>\r\n    add.s32         %r10, %r8, %r5;\r\n</pre>\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), this is done by multiplying the second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code>) and stored back to the first argument (<code>r4</code>).\r\n\r\n<pre>\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n</pre>\r\n\r\nThe first conditional instruction is then reached (the only one in this example), which consists of the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing the second argument (the global thread ID in this example) to the third argument (number of elements of input/output vectors) using the condition stated after <code>setp</code>, in this case <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target <code>BB0_2</code> (target must be a label or register pointing to the address of a label) and continues execution from there, if false, just continues execution without branching. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction that comes immediately after.\r\n\r\n<pre>\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n</pre>\r\n\r\nThe real data processing is done by the set of instructions under label <code>BB0_2</code>, which calculates data pointers, loads data from global memory, performs calculations and stores results back to global memory. Since we are dealing with 32-bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID. The result in <code>r11</code> is then added to the addresses pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code>), resulting in the addresses where the data that needs to be processed by the thread lies in memory.\r\n\r\n<pre>\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n</pre>\r\n\r\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the pointer to a memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is then stored into the register passed as the first argument. After the resulting value is calculated by adding both values read from memory, and memory address where result will be stored is calculated, it is stored in global memory with complimentary instruction to <code>ld.global</code>, that is <code>st.global</code>. In the storage to memory case, the first argument is the address, that is the argument inside brackets. Finally, the return instruction <code>ret</code> is called and the processing is finished.\r\n\r\n<pre>\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n</pre>\r\n\r\nWhile PTX code might not be as straightforward to understand as the C/C++ code, in my opinion is still easier to understand than pure assembly for most architectures, as we do not have to handle lots of interrupts, for example. Understanding PTX code can significantly help you understand what the compiler is actually doing with your C/C++ code, and how the program will flow through hardware. In some cases, this can be an important tool to put your GPU to full power.\r\n\r\n','Demystifying PTX Code','','publish','open','open','','demystifying-ptx-code','','\nhttp://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/','2014-09-17 15:18:09','2014-09-17 15:18:09','',0,'http://sandbox.arrayfire.com/?p=6581',0,'post','',3),(6582,17795,'2014-09-10 00:56:59','2014-09-10 00:56:59','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a>, I have shown how to generate a PTX file from both CUDA and OpenCL kernels. But how does a PTX file looks like, and more importantly, how can we understand and compare PTX files of both architectures?\r\n\r\nIn this post I will use the same vector addition kernel that was used before and show some peculiarities for each PTX file, let\'s start by looking at the PTX for the OpenCL case:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred  %p<2>;\r\n    .reg .s32   %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    // inline asm\r\n    mov.u32     %r5, %envreg3;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r6, %ntid.x;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r7, %ctaid.x;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r8, %tid.x;\r\n    // inline asm\r\n    add.s32     %r10, %r8, %r5;\r\n    mad.lo.s32  %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra    BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32     %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32     %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32     %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32     %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32     %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nIt starts with a header showing some compiler information in comments, followed by three lines containing the PTX ISA version, target architecture (compute capability) and addressing size being used.\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name. The parameters for these kernels are three pointers to 32-bit integers to global memory (notice that there is no distiction from constant to non-constant pointers), and one 32-bit integer argument (the length of our vectors).\r\n\r\nEach parameter start with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case, which in the example are all compiled into 32-bit unsigned integers. The arguments which are pointers are then followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space) and finally the data alignment, which is <code>.align 4</code> for 4 bytes alignment.\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type (note that references to registers are always preceded by the <code>%</code> sign. Registers with the data type defined by <code>.pred</code> directive are used for conditional assignments, to control a jump instruction, for example.\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register. This copy to a register is necessary as most of PTX instructions cannot handle function parameters directly. Note that all data related directives end with the data type that is being processed.\r\n\r\nLater, the values of some special registers are copied to the registers previously defined, they are:\r\n* <code>%envreg3</code>: (read-only driver-defined special register)\r\n* <code>ntid.x</code>: (number of threads per CTA in x dimension, Cooperative Thread Array, equivalent to get_local_size(0))\r\n* <code>ctaid.x</code>: (identifier of CTA within a grid, equivalent to get_group_id(0))\r\n* <code>tid.x</code>: (thread identifier in the x dimension of CTA, equilalent to get_local_id(0))\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>%envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since this is not directly part of the code but a driver-specific computation, I won\'t go into more details about it (note that this does not exist in PTX of the CUDA code). With the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculate (get_global_id(0)), which is done by multiplying second and third arguments, with the lower bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) being later added to the fourth argument and storing back to the first argument.\r\n','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-10 00:56:59','2014-09-10 00:56:59','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6583,17795,'2014-09-10 00:58:38','2014-09-10 00:58:38','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a>, I have shown how to generate a PTX file from both CUDA and OpenCL kernels. But how does a PTX file looks like, and more importantly, how can we understand and compare PTX files of both architectures?\r\n\r\nIn this post I will use the same vector addition kernel that was used before and show some peculiarities for each PTX file, let\'s start by looking at the PTX for the OpenCL case:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred  %p<2>;\r\n    .reg .s32   %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    // inline asm\r\n    mov.u32     %r5, %envreg3;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r6, %ntid.x;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r7, %ctaid.x;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r8, %tid.x;\r\n    // inline asm\r\n    add.s32     %r10, %r8, %r5;\r\n    mad.lo.s32  %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra    BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32     %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32     %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32     %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32     %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32     %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nIt starts with a header showing some compiler information in comments, followed by three lines containing the PTX ISA version, target architecture (compute capability) and addressing size being used.\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name. The parameters for these kernels are three pointers to 32-bit integers to global memory (notice that there is no distiction from constant to non-constant pointers), and one 32-bit integer argument (the length of our vectors).\r\n\r\nEach parameter start with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case, which in the example are all compiled into 32-bit unsigned integers. The arguments which are pointers are then followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space) and finally the data alignment, which is <code>.align 4</code> for 4 bytes alignment.\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type (note that references to registers are always preceded by the <code>%</code> sign. Registers with the data type defined by <code>.pred</code> directive are used for conditional assignments, to control a jump instruction, for example.\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register. This copy to a register is necessary as most of PTX instructions cannot handle function parameters directly. Note that all data related directives end with the data type that is being processed.\r\n\r\nLater, the values of some special registers are copied to the registers previously defined, they are:\r\n<ul>\r\n<li><code>%envreg3</code>: (read-only driver-defined special register)</li>\r\n<li><code>ntid.x</code>: (number of threads per CTA in x dimension, Cooperative Thread Array, equivalent to get_local_size(0))</li>\r\n<li><code>ctaid.x</code>: (identifier of CTA within a grid, equivalent to get_group_id(0))</li>\r\n<li><code>tid.x</code>: (thread identifier in the x dimension of CTA, equilalent to get_local_id(0))</li>\r\n</ul>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>%envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since this is not directly part of the code but a driver-specific computation, I won\'t go into more details about it (note that this does not exist in PTX of the CUDA code). With the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculate (get_global_id(0)), which is done by multiplying second and third arguments, with the lower bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) being later added to the fourth argument and storing back to the first argument.\r\n','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-10 00:58:38','2014-09-10 00:58:38','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6584,17795,'2014-09-10 01:18:52','2014-09-10 01:18:52','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a>, I have shown how to generate a PTX file from both CUDA and OpenCL kernels. But how does a PTX file looks like, and more importantly, how can we understand and compare PTX files of both architectures?\r\n\r\nIn this post I will use the same vector addition kernel that was used before and show some peculiarities for each PTX file, let\'s start by looking at the PTX for the OpenCL case:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred  %p<2>;\r\n    .reg .s32   %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    // inline asm\r\n    mov.u32     %r5, %envreg3;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r6, %ntid.x;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r7, %ctaid.x;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r8, %tid.x;\r\n    // inline asm\r\n    add.s32     %r10, %r8, %r5;\r\n    mad.lo.s32  %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra    BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32     %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32     %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32     %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32     %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32     %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nIt starts with a header showing some compiler information in comments, followed by three lines containing the PTX ISA version, target architecture (compute capability) and addressing size being used.\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name. The parameters for these kernels are three pointers to 32-bit integers to global memory (notice that there is no distiction from constant to non-constant pointers), and one 32-bit integer argument (the length of our vectors).\r\n\r\nEach parameter start with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case, which in the example are all compiled into 32-bit unsigned integers. The arguments which are pointers are then followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space) and finally the data alignment, which is <code>.align 4</code> for 4 bytes alignment.\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type (note that references to registers are always preceded by the <code>%</code> sign. Registers with the data type defined by <code>.pred</code> directive are used for conditional assignments, to control a jump instruction, for example.\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register. This copy to a register is necessary as most of PTX instructions cannot handle function parameters directly. Note that all data related directives end with the data type that is being processed.\r\n\r\nLater, the values of some special registers are copied to the registers previously defined, they are:\r\n<ul>\r\n<li><code>envreg3</code>: (read-only driver-defined special register)</li>\r\n<li><code>ntid.x</code>: (number of threads per CTA in x dimension, Cooperative Thread Array, equivalent to get_local_size(0))</li>\r\n<li><code>ctaid.x</code>: (identifier of CTA within a grid, equivalent to get_group_id(0))</li>\r\n<li><code>tid.x</code>: (thread identifier in the x dimension of CTA, equilalent to get_local_id(0))</li>\r\n</ul>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since this is not directly part of the code but a driver-specific computation, I won\'t go into more details about it (note that this does not exist in PTX of the CUDA code).\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), which is done by multiplying second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code) and stored back to the first argument (<code>r4</code>).\r\n\r\nThe first conditional case is then reached, which is composed by the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing second argument (in our case, the global thread ID) to the third argument (number of elements of input vector) using the condition the condition stated after <code>setp</code>, in this case being <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target and continue execution (target must be a label, or register pointing to address of a label), if false, just continues execution. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction.\r\n\r\n','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-10 01:18:52','2014-09-10 01:18:52','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6585,17795,'2014-09-10 01:19:14','2014-09-10 01:19:14','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a>, I have shown how to generate a PTX file from both CUDA and OpenCL kernels. But how does a PTX file looks like, and more importantly, how can we understand and compare PTX files of both architectures?\r\n\r\nIn this post I will use the same vector addition kernel that was used before and show some peculiarities for each PTX file, let\'s start by looking at the PTX for the OpenCL case:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred  %p<2>;\r\n    .reg .s32   %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    // inline asm\r\n    mov.u32     %r5, %envreg3;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r6, %ntid.x;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r7, %ctaid.x;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r8, %tid.x;\r\n    // inline asm\r\n    add.s32     %r10, %r8, %r5;\r\n    mad.lo.s32  %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra    BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32     %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32     %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32     %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32     %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32     %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nIt starts with a header showing some compiler information in comments, followed by three lines containing the PTX ISA version, target architecture (compute capability) and addressing size being used.\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name. The parameters for these kernels are three pointers to 32-bit integers to global memory (notice that there is no distinction from constant to non-constant pointers), and one 32-bit integer argument (the length of our vectors).\r\n\r\nEach parameter start with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case, which in the example are all compiled into 32-bit unsigned integers. The arguments which are pointers are then followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space) and finally the data alignment, which is <code>.align 4</code> for 4 bytes alignment.\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type (note that references to registers are always preceded by the <code>%</code> sign. Registers with the data type defined by <code>.pred</code> directive are used for conditional assignments, to control a jump instruction, for example.\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register. This copy to a register is necessary as most of PTX instructions cannot handle function parameters directly. Note that all data related directives end with the data type that is being processed.\r\n\r\nLater, the values of some special registers are copied to the registers previously defined, they are:\r\n<ul>\r\n<li><code>envreg3</code>: (read-only driver-defined special register)</li>\r\n<li><code>ntid.x</code>: (number of threads per CTA in x dimension, Cooperative Thread Array, equivalent to get_local_size(0))</li>\r\n<li><code>ctaid.x</code>: (identifier of CTA within a grid, equivalent to get_group_id(0))</li>\r\n<li><code>tid.x</code>: (thread identifier in the x dimension of CTA, equivalent to get_local_id(0))</li>\r\n</ul>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since this is not directly part of the code but a driver-specific computation, I won\'t go into more details about it (note that this does not exist in PTX of the CUDA code).\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), which is done by multiplying second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code) and stored back to the first argument (<code>r4</code>).\r\n\r\nThe first conditional case is then reached, which is composed by the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing second argument (in our case, the global thread ID) to the third argument (number of elements of input vector) using the condition the condition stated after <code>setp</code>, in this case being <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target and continue execution (target must be a label, or register pointing to address of a label), if false, just continues execution. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction.\r\n\r\n','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-10 01:19:14','2014-09-10 01:19:14','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6586,17795,'2014-09-10 13:15:03','2014-09-10 13:15:03','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a>, I have shown how to generate a PTX file from both CUDA and OpenCL kernels. But how does a PTX file looks like, and more importantly, how can we understand and compare PTX files of both architectures?\r\n\r\nIn this post I will use the same vector addition kernel that was used before and show some peculiarities for each PTX file, let\'s start by looking at the PTX for the OpenCL case:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred  %p<2>;\r\n    .reg .s32   %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    // inline asm\r\n    mov.u32     %r5, %envreg3;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r6, %ntid.x;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r7, %ctaid.x;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r8, %tid.x;\r\n    // inline asm\r\n    add.s32     %r10, %r8, %r5;\r\n    mad.lo.s32  %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra    BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32     %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32     %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32     %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32     %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32     %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nIt starts with a header showing some compiler information in comments, followed by three lines containing the PTX ISA version, target architecture (compute capability) and addressing size being used.\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name. The parameters for these kernels are three pointers to 32-bit integers to global memory (notice that there is no distinction from constant to non-constant pointers), and one 32-bit integer argument (the length of our vectors).\r\n\r\nEach parameter start with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case, which in the example are all compiled into 32-bit unsigned integers. The arguments which are pointers are then followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space) and finally the data alignment, which is <code>.align 4</code> for 4 bytes alignment.\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type (note that references to registers are always preceded by the <code>%</code> sign. Registers with the data type defined by <code>.pred</code> directive are used for conditional assignments, to control a jump instruction, for example.\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register, but the second argument is an address, so it must be inside brackets, as in <code>[add_vectors_param_3]</code>. This copy to a register is necessary as most of PTX instructions cannot handle function parameters directly. Note that all data related directives end with the data type that is being processed.\r\n\r\nLater, the values of some special registers are copied to the registers previously defined, they are:\r\n<ul>\r\n<li><code>envreg3</code>: (read-only driver-defined special register)</li>\r\n<li><code>ntid.x</code>: (number of threads per CTA in x dimension, Cooperative Thread Array, equivalent to get_local_size(0))</li>\r\n<li><code>ctaid.x</code>: (identifier of CTA within a grid, equivalent to get_group_id(0))</li>\r\n<li><code>tid.x</code>: (thread identifier in the x dimension of CTA, equivalent to get_local_id(0))</li>\r\n</ul>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since this is not directly part of the code but a driver-specific computation, I won\'t go into more details about it (note that this does not exist in PTX of the CUDA code).\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), which is done by multiplying second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code) and stored back to the first argument (<code>r4</code>).\r\n\r\nThe first conditional case is then reached, which is composed by the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing second argument (in our case, the global thread ID) to the third argument (number of elements of input vector) using the condition the condition stated after <code>setp</code>, in this case being <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target and continue execution (target must be a label, or register pointing to address of a label), if false, just continues execution. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction.\r\n\r\nThe real data processing is done by instructions under label BB0_2, which calculates data pointers, loads data from global memory, perform calculations and stores it back to global memory. Since we are dealing with 32 bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID, which is then added to the address pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code> to find the where the data that will be processed by the thread lies in memory.\r\n\r\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is the stored to the first argument, which is another register.','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-10 13:15:03','2014-09-10 13:15:03','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6587,17795,'2014-09-10 13:26:34','2014-09-10 13:26:34','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a>, I have shown how to generate a PTX file from both CUDA and OpenCL kernels. But how does a PTX file looks like, and more importantly, how can we understand and compare PTX files of both architectures?\r\n\r\nIn this post I will use the same vector addition kernel that was used before and show some peculiarities for each PTX file, let\'s start by looking at the PTX for the OpenCL case:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred  %p<2>;\r\n    .reg .s32   %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    // inline asm\r\n    mov.u32     %r5, %envreg3;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r6, %ntid.x;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r7, %ctaid.x;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r8, %tid.x;\r\n    // inline asm\r\n    add.s32     %r10, %r8, %r5;\r\n    mad.lo.s32  %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra    BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32     %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32     %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32     %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32     %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32     %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nIt starts with a header showing some compiler information in comments, followed by three lines containing the PTX ISA version, target architecture (compute capability) and addressing size being used.\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name. The parameters for these kernels are three pointers to 32-bit integers to global memory (notice that there is no distinction from constant to non-constant pointers), and one 32-bit integer argument (the length of our vectors).\r\n\r\nEach parameter start with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case, which in the example are all compiled into 32-bit unsigned integers. The arguments which are pointers are then followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space) and finally the data alignment, which is <code>.align 4</code> for 4 bytes alignment.\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type (note that references to registers are always preceded by the <code>%</code> sign. Registers with the data type defined by <code>.pred</code> directive are used for conditional assignments, to control a jump instruction, for example.\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register, but the second argument is an address, so it must be inside brackets, as in <code>[add_vectors_param_3]</code>. This copy to a register is necessary as most of PTX instructions cannot handle function parameters directly. Note that all data related directives end with the data type that is being processed.\r\n\r\nLater, the values of some special registers are copied to the registers previously defined, they are:\r\n<ul>\r\n<li><code>envreg3</code>: (read-only driver-defined special register)</li>\r\n<li><code>ntid.x</code>: (number of threads per CTA in x dimension, Cooperative Thread Array, equivalent to get_local_size(0))</li>\r\n<li><code>ctaid.x</code>: (identifier of CTA within a grid, equivalent to get_group_id(0))</li>\r\n<li><code>tid.x</code>: (thread identifier in the x dimension of CTA, equivalent to get_local_id(0))</li>\r\n</ul>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since this is not directly part of the code but a driver-specific computation, I won\'t go into more details about it (note that this does not exist in PTX of the CUDA code).\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), which is done by multiplying second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code) and stored back to the first argument (<code>r4</code>).\r\n\r\nThe first conditional case is then reached, which is composed by the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing second argument (in our case, the global thread ID) to the third argument (number of elements of input vector) using the condition the condition stated after <code>setp</code>, in this case being <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target and continue execution (target must be a label, or register pointing to address of a label), if false, just continues execution. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction.\r\n\r\nThe real data processing is done by instructions under label BB0_2, which calculates data pointers, loads data from global memory, perform calculations and stores it back to global memory. Since we are dealing with 32 bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID, which is then added to the address pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code> to find the where the data that will be processed by the thread lies in memory.\r\n\r\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is the stored to the first argument, a register. After the resulting value is calculated by adding both values read from memory, and memory address where result will be stored is calculated, it is stored in global memory with instruction <code>st.global</code>, in this case the first argument is the address, so that is the one inside brackets. Finally, the return instruction <code>ret</code> is called and the processing is finished.\r\n\r\nAs the PTX might not be as simple as the C/C++ code, it is still not very complicated, and it is very useful to understand it when you want to extract the most out of a GPU.','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-10 13:26:34','2014-09-10 13:26:34','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6589,17795,'2014-09-10 14:40:03','2014-09-10 14:40:03','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a>, I have shown how to generate PTX files from both CUDA and OpenCL kernels. But how does a PTX file looks like, and more importantly, how to understand all those complicated instruction on PTX files?\r\n\r\nIn this post I will use the same vector addition kernel that was used before and show some peculiarities for each PTX file, let\'s start by looking at the PTX for the OpenCL case:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred  %p<2>;\r\n    .reg .s32   %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    // inline asm\r\n    mov.u32     %r5, %envreg3;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r6, %ntid.x;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r7, %ctaid.x;\r\n    // inline asm\r\n    // inline asm\r\n    mov.u32     %r8, %tid.x;\r\n    // inline asm\r\n    add.s32     %r10, %r8, %r5;\r\n    mad.lo.s32  %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra    BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32     %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32     %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32     %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32     %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32     %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nThe file starts with a header showing some compiler information in comments, followed by three lines containing the PTX ISA version, target architecture (compute capability) and addressing size being used.\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name. The parameters for these kernels are three pointers to 32-bit integers global memory arrays (notice that there is no distinction from constant to non-constant pointers), and one 32-bit integer argument (the length of our vectors).\r\n\r\nEach parameter start with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case, which in the example are all compiled into 32-bit unsigned integers (for extended information on data types, refer to <a href=\"http://docs.nvidia.com/cuda/parallel-thread-execution/\">PTX ISA documentation</a>). The arguments which are pointers are then followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space) and finally the data alignment, which is <code>.align 4</code> for 4 bytes alignment.\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type (note that references to registers are always preceded by the <code>%</code> sign). Registers with the data type defined by <code>.pred</code> directive are used for conditional assignments, to control a branch instruction, for example.\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register, but the second argument is an address, so it must be inside brackets, as in <code>[add_vectors_param_3]</code>. This copy to a register is necessary as most of PTX instructions cannot handle function parameters directly. See that all data related directives end with the data type that is being processed.\r\n\r\nLater, the values of some special registers are copied to the registers previously defined, they are:\r\n<ul>\r\n<li><code>envreg3</code>: read-only driver-defined special register;</li>\r\n<li><code>ntid.x</code>: number of threads per CTA, Cooperative Thread Array, in x dimension, equivalent to get_local_size(0);</li>\r\n<li><code>ctaid.x</code>: identifier of CTA within a grid, equivalent to get_group_id(0);</li>\r\n<li><code>tid.x</code>: thread identifier in the x dimension of CTA, equivalent to get_local_id(0).</li>\r\n</ul>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since <code>envreg3</code> is not directly part of the code but a driver-specific computation, I won\'t go into more details about it (note that <code>envreg</code> does not appear in PTX of the CUDA code for this kernel).\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), which is done by multiplying second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code) and stored back to the first argument (<code>r4</code>).\r\n\r\nThe first conditional case is then reached, which is composed by the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing second argument (in our case, the global thread ID) to the third argument (number of elements of input vector) using the condition the condition stated after <code>setp</code>, in this case being <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target and continue execution (target must be a label, or register pointing to address of a label), if false, just continues execution. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction.\r\n\r\nThe real data processing is done by instructions under label BB0_2, which calculates data pointers, loads data from global memory, perform calculations and stores it back to global memory. Since we are dealing with 32 bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID, which is then added to the address pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code> to find the where the data that will be processed by the thread lies in memory.\r\n\r\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is the stored to the first argument, a register. After the resulting value is calculated by adding both values read from memory, and memory address where result will be stored is calculated, it is stored in global memory with instruction <code>st.global</code>, in this case the first argument is the address, so that is the one inside brackets. Finally, the return instruction <code>ret</code> is called and the processing is finished.\r\n\r\nAs the PTX might not be as simple as the C/C++ code, it is still not very complicated, and it is very useful to understand it when you want to extract the most out of a GPU.','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-10 14:40:03','2014-09-10 14:40:03','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6590,17795,'2014-09-10 14:45:17','2014-09-10 14:45:17','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a>, I have shown how to generate PTX files from both CUDA and OpenCL kernels. But how does a PTX file looks like, and more importantly, how to understand all those complicated instruction on PTX files?\r\n\r\nIn this post I will use the same vector addition kernel that was used before and show some peculiarities for each PTX file, let\'s start by looking at the PTX for the OpenCL case:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred  %p<2>;\r\n    .reg .s32   %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    mov.u32     %r5, %envreg3;\r\n    mov.u32     %r6, %ntid.x;\r\n    mov.u32     %r7, %ctaid.x;\r\n    mov.u32     %r8, %tid.x;\r\n    add.s32     %r10, %r8, %r5;\r\n    mad.lo.s32  %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra    BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32     %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32     %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32     %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32     %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32     %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nThe file starts with a header showing some compiler information in comments, followed by three lines containing the PTX ISA version, target architecture (compute capability) and addressing size being used.\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n</pre>\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name. The parameters for these kernels are three pointers to 32-bit integers global memory arrays (notice that there is no distinction from constant to non-constant pointers), and one 32-bit integer argument (the length of our vectors).\r\n\r\n<pre>\r\n.entry add_vectors(\r\n...\r\n)\r\n</pre>\r\n\r\nEach parameter start with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case, which in the example are all compiled into 32-bit unsigned integers (for extended information on data types, refer to <a href=\"http://docs.nvidia.com/cuda/parallel-thread-execution/\">PTX ISA documentation</a>). The arguments which are pointers are then followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space) and finally the data alignment, which is <code>.align 4</code> for 4 bytes alignment.\r\n\r\n<pre>\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n</pre>\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type (note that references to registers are always preceded by the <code>%</code> sign). Registers with the data type defined by <code>.pred</code> directive are used for conditional assignments, to control a branch instruction, for example.\r\n\r\n<pre>\r\n    .reg .pred  %p<2>;\r\n    .reg .s32   %r<21>;\r\n</pre>\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register, but the second argument is an address, so it must be inside brackets, as in <code>[add_vectors_param_3]</code>. This copy to a register is necessary as most of PTX instructions cannot handle function parameters directly. See that all data related directives end with the data type that is being processed.\r\n\r\n<pre>\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n</pre>\r\n\r\nLater, the values of some special registers are copied to the registers previously defined, they are:\r\n<ul>\r\n<li><code>envreg3</code>: read-only driver-defined special register;</li>\r\n<li><code>ntid.x</code>: number of threads per CTA, Cooperative Thread Array, in x dimension, equivalent to get_local_size(0);</li>\r\n<li><code>ctaid.x</code>: identifier of CTA within a grid, equivalent to get_group_id(0);</li>\r\n<li><code>tid.x</code>: thread identifier in the x dimension of CTA, equivalent to get_local_id(0).</li>\r\n</ul>\r\n\r\n<pre>\r\n    mov.u32     %r5, %envreg3;\r\n    mov.u32     %r6, %ntid.x;\r\n    mov.u32     %r7, %ctaid.x;\r\n    mov.u32     %r8, %tid.x;\r\n</pre>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since <code>envreg3</code> is not directly part of the code but a driver-specific computation, I won\'t go into more details about it (note that <code>envreg</code> does not appear in PTX of the CUDA code for this kernel).\r\n\r\n<pre>\r\n    add.s32     %r10, %r8, %r5;\r\n</pre>\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), which is done by multiplying second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code) and stored back to the first argument (<code>r4</code>).\r\n\r\n<pre>\r\n    mad.lo.s32  %r4, %r7, %r6, %r10;\r\n</pre>\r\n\r\nThe first conditional case is then reached, which is composed by the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing second argument (in our case, the global thread ID) to the third argument (number of elements of input vector) using the condition the condition stated after <code>setp</code>, in this case being <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target and continue execution (target must be a label, or register pointing to address of a label), if false, just continues execution. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction.\r\n\r\n<pre>\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra    BB0_2;\r\n\r\n    ret;\r\n</pre>\r\n\r\nThe real data processing is done by instructions under label BB0_2, which calculates data pointers, loads data from global memory, perform calculations and stores it back to global memory. Since we are dealing with 32-bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID, which is then added to the address pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code> to find the where the data that will be processed by the thread lies in memory.\r\n\r\n<pre>\r\nBB0_2:\r\n    shl.b32     %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32     %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32     %r13, %r19, %r11;\r\n</pre>\r\n\r\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is the stored to the first argument, a register. After the resulting value is calculated by adding both values read from memory, and memory address where result will be stored is calculated, it is stored in global memory with instruction <code>st.global</code>, in this case the first argument is the address, so that is the one inside brackets. Finally, the return instruction <code>ret</code> is called and the processing is finished.\r\n\r\n<pre>\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32     %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32     %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n</pre>\r\n\r\nAs the PTX might not be as simple as the C/C++ code, it is still not very complicated, and it is very useful to understand it when you want to extract the most out of a GPU.','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-10 14:45:17','2014-09-10 14:45:17','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6591,17795,'2014-09-10 14:49:38','2014-09-10 14:49:38','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a>, I have shown how to generate PTX files from both CUDA and OpenCL kernels. But how does a PTX file looks like, and more importantly, how to understand all those complicated instruction on PTX files?\r\n\r\nIn this post I will use the same vector addition kernel that was used before and show some peculiarities for each PTX file, let\'s start by looking at the PTX for the OpenCL case:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n    add.s32         %r10, %r8, %r5;\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nThe file starts with a header showing some compiler information in comments, followed by three lines containing the PTX ISA version, target architecture (compute capability) and addressing size being used.\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n</pre>\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name. The parameters for these kernels are three pointers to 32-bit integers global memory arrays (notice that there is no distinction from constant to non-constant pointers), and one 32-bit integer argument (the length of our vectors).\r\n\r\n<pre>\r\n.entry add_vectors(\r\n...\r\n)\r\n</pre>\r\n\r\nEach parameter start with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case, which in the example are all compiled into 32-bit unsigned integers (for extended information on data types, refer to <a href=\"http://docs.nvidia.com/cuda/parallel-thread-execution/\">PTX ISA documentation</a>). The arguments which are pointers are then followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space) and finally the data alignment, which is <code>.align 4</code> for 4 bytes alignment.\r\n\r\n<pre>\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n</pre>\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type (note that references to registers are always preceded by the <code>%</code> sign). Registers with the data type defined by <code>.pred</code> directive are used for conditional assignments, to control a branch instruction, for example.\r\n\r\n<pre>\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n</pre>\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register, but the second argument is an address, so it must be inside brackets, as in <code>[add_vectors_param_3]</code>. This copy to a register is necessary as most of PTX instructions cannot handle function parameters directly. See that all data related directives end with the data type that is being processed.\r\n\r\n<pre>\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n</pre>\r\n\r\nLater, the values of some special registers are copied to the registers previously defined, they are:\r\n<ul>\r\n<li><code>envreg3</code>: read-only driver-defined special register;</li>\r\n<li><code>ntid.x</code>: number of threads per CTA, Cooperative Thread Array, in x dimension, equivalent to get_local_size(0);</li>\r\n<li><code>ctaid.x</code>: identifier of CTA within a grid, equivalent to get_group_id(0);</li>\r\n<li><code>tid.x</code>: thread identifier in the x dimension of CTA, equivalent to get_local_id(0).</li>\r\n</ul>\r\n\r\n<pre>\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n</pre>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since <code>envreg3</code> is not directly part of the code but a driver-specific computation, I won\'t go into more details about it (note that <code>envreg</code> does not appear in PTX of the CUDA code for this kernel).\r\n\r\n<pre>\r\n    add.s32         %r10, %r8, %r5;\r\n</pre>\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), which is done by multiplying second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code) and stored back to the first argument (<code>r4</code>).\r\n\r\n<pre>\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n</pre>\r\n\r\nThe first conditional case is then reached, which is composed by the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing second argument (in our case, the global thread ID) to the third argument (number of elements of input vector) using the condition the condition stated after <code>setp</code>, in this case being <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target and continue execution (target must be a label, or register pointing to address of a label), if false, just continues execution. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction.\r\n\r\n<pre>\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n</pre>\r\n\r\nThe real data processing is done by instructions under label BB0_2, which calculates data pointers, loads data from global memory, perform calculations and stores it back to global memory. Since we are dealing with 32-bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID, which is then added to the address pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code> to find the where the data that will be processed by the thread lies in memory.\r\n\r\n<pre>\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n</pre>\r\n\r\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is the stored to the first argument, a register. After the resulting value is calculated by adding both values read from memory, and memory address where result will be stored is calculated, it is stored in global memory with instruction <code>st.global</code>, in this case the first argument is the address, so that is the one inside brackets. Finally, the return instruction <code>ret</code> is called and the processing is finished.\r\n\r\n<pre>\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n</pre>\r\n\r\nAs the PTX might not be as straightforward to understand as the C/C++ code, it is still not that complicated, and it is very useful to understand it when you want to extract the most out of a GPU.','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-10 14:49:38','2014-09-10 14:49:38','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6592,17795,'2014-09-10 14:52:48','2014-09-10 14:52:48','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a>, I have shown how to generate PTX files from both CUDA and OpenCL kernels. But how does a PTX file looks like, and more importantly, how to understand all those complicated instruction on PTX files?\r\n\r\nIn this post I will use the same vector addition kernel that was used in that <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a> and show what the PTX file looks like, also explaining in detail what is happening. For this post, I will use the OpenCL PTX file, in my next post I will show the differences between PTX files of OpenCL and CUDA code. Let\'s start by looking at the complete PTX code:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n    add.s32         %r10, %r8, %r5;\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nThe file starts with a header showing some compiler information in comments, followed by three lines containing the PTX ISA version, target architecture (compute capability) and addressing size being used.\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n</pre>\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name. The parameters for these kernels are three pointers to 32-bit integers global memory arrays (notice that there is no distinction from constant to non-constant pointers), and one 32-bit integer argument (the length of our vectors).\r\n\r\n<pre>\r\n.entry add_vectors(\r\n...\r\n)\r\n</pre>\r\n\r\nEach parameter start with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case, which in the example are all compiled into 32-bit unsigned integers (for extended information on data types, refer to <a href=\"http://docs.nvidia.com/cuda/parallel-thread-execution/\">PTX ISA documentation</a>). The arguments which are pointers are then followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space) and finally the data alignment, which is <code>.align 4</code> for 4 bytes alignment.\r\n\r\n<pre>\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n</pre>\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type (note that references to registers are always preceded by the <code>%</code> sign). Registers with the data type defined by <code>.pred</code> directive are used for conditional assignments, to control a branch instruction, for example.\r\n\r\n<pre>\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n</pre>\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register, but the second argument is an address, so it must be inside brackets, as in <code>[add_vectors_param_3]</code>. This copy to a register is necessary as most of PTX instructions cannot handle function parameters directly. See that all data related directives end with the data type that is being processed.\r\n\r\n<pre>\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n</pre>\r\n\r\nLater, the values of some special registers are copied to the registers previously defined, they are:\r\n<ul>\r\n<li><code>envreg3</code>: read-only driver-defined special register;</li>\r\n<li><code>ntid.x</code>: number of threads per CTA, Cooperative Thread Array, in x dimension, equivalent to get_local_size(0);</li>\r\n<li><code>ctaid.x</code>: identifier of CTA within a grid, equivalent to get_group_id(0);</li>\r\n<li><code>tid.x</code>: thread identifier in the x dimension of CTA, equivalent to get_local_id(0).</li>\r\n</ul>\r\n\r\n<pre>\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n</pre>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since <code>envreg3</code> is not directly part of the code but a driver-specific computation, I won\'t go into more details about it (note that <code>envreg</code> does not appear in PTX of the CUDA code for this kernel).\r\n\r\n<pre>\r\n    add.s32         %r10, %r8, %r5;\r\n</pre>\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), which is done by multiplying second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code) and stored back to the first argument (<code>r4</code>).\r\n\r\n<pre>\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n</pre>\r\n\r\nThe first conditional case is then reached, which is composed by the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing second argument (in our case, the global thread ID) to the third argument (number of elements of input vector) using the condition the condition stated after <code>setp</code>, in this case being <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target and continue execution (target must be a label, or register pointing to address of a label), if false, just continues execution. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction.\r\n\r\n<pre>\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n</pre>\r\n\r\nThe real data processing is done by instructions under label BB0_2, which calculates data pointers, loads data from global memory, perform calculations and stores it back to global memory. Since we are dealing with 32-bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID, which is then added to the address pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code> to find the where the data that will be processed by the thread lies in memory.\r\n\r\n<pre>\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n</pre>\r\n\r\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is the stored to the first argument, a register. After the resulting value is calculated by adding both values read from memory, and memory address where result will be stored is calculated, it is stored in global memory with instruction <code>st.global</code>, in this case the first argument is the address, so that is the one inside brackets. Finally, the return instruction <code>ret</code> is called and the processing is finished.\r\n\r\n<pre>\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n</pre>\r\n\r\nAs the PTX might not be as straightforward to understand as the C/C++ code, it is still not that complicated, and it is very useful to understand it when you want to extract the most out of a GPU.','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-10 14:52:48','2014-09-10 14:52:48','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6593,17795,'2014-09-10 14:56:22','2014-09-10 14:56:22','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a>, I have shown how to generate PTX files from both CUDA and OpenCL kernels. But how does a PTX file looks like, and more importantly, how to understand all those complicated instruction on PTX files?\r\n\r\nIn this post I will use the same vector addition kernel that was used in that <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a> and show what a PTX file looks like and also explain it in detail. For this post, I will use the OpenCL PTX file, in my next post I will show the differences between PTX files of OpenCL and CUDA code. Let\'s start by looking at the complete PTX code:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n    add.s32         %r10, %r8, %r5;\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nThe file starts with a header showing some compiler information in comments, followed by three lines containing the PTX ISA version, target architecture (compute capability) and addressing size being used.\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n</pre>\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name.\r\n\r\n<pre>\r\n.entry add_vectors(\r\n...\r\n)\r\n</pre>\r\n\r\nThe parameters for this kernel are three pointers to 32-bit integers global memory arrays (notice that there is no distinction from constant to non-constant pointers), and one 32-bit integer argument (the length of our vectors). Each parameter start with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case, which in the example are all compiled into 32-bit unsigned integers (for extended information on data types, refer to <a href=\"http://docs.nvidia.com/cuda/parallel-thread-execution/\">PTX ISA documentation</a>). The arguments which are pointers are then followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space) and finally the data alignment, which is <code>.align 4</code> for 4 bytes alignment.\r\n\r\n<pre>\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n</pre>\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type (note that references to registers are always preceded by the <code>%</code> sign). Registers with the data type defined by <code>.pred</code> directive are used for conditional assignments, to control a branch instruction, for example.\r\n\r\n<pre>\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n</pre>\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register, but the second argument is an address, so it must be inside brackets, as in <code>[add_vectors_param_3]</code>. This copy to a register is necessary as most of PTX instructions cannot handle function parameters directly. See that all data related directives end with the data type that is being processed.\r\n\r\n<pre>\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n</pre>\r\n\r\nLater, the values of some special registers are copied to the registers previously defined, they are:\r\n<ul>\r\n<li><code>envreg3</code>: read-only driver-defined special register;</li>\r\n<li><code>ntid.x</code>: number of threads per CTA, Cooperative Thread Array, in x dimension, equivalent to get_local_size(0);</li>\r\n<li><code>ctaid.x</code>: identifier of CTA within a grid, equivalent to get_group_id(0);</li>\r\n<li><code>tid.x</code>: thread identifier in the x dimension of CTA, equivalent to get_local_id(0).</li>\r\n</ul>\r\n\r\n<pre>\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n</pre>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since <code>envreg3</code> is not directly part of the code but a driver-specific computation, I won\'t go into more details about it (note that <code>envreg</code> does not appear in PTX of the CUDA code for this kernel).\r\n\r\n<pre>\r\n    add.s32         %r10, %r8, %r5;\r\n</pre>\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), which is done by multiplying second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code) and stored back to the first argument (<code>r4</code>).\r\n\r\n<pre>\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n</pre>\r\n\r\nThe first conditional case is then reached, which is composed by the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing second argument (in our case, the global thread ID) to the third argument (number of elements of input vector) using the condition the condition stated after <code>setp</code>, in this case being <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target and continue execution (target must be a label, or register pointing to address of a label), if false, just continues execution. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction.\r\n\r\n<pre>\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n</pre>\r\n\r\nThe real data processing is done by instructions under label BB0_2, which calculates data pointers, loads data from global memory, perform calculations and stores it back to global memory. Since we are dealing with 32-bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID, which is then added to the address pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code> to find the where the data that will be processed by the thread lies in memory.\r\n\r\n<pre>\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n</pre>\r\n\r\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is the stored to the first argument, a register. After the resulting value is calculated by adding both values read from memory, and memory address where result will be stored is calculated, it is stored in global memory with instruction <code>st.global</code>, in this case the first argument is the address, so that is the one inside brackets. Finally, the return instruction <code>ret</code> is called and the processing is finished.\r\n\r\n<pre>\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n</pre>\r\n\r\nAs the PTX might not be as straightforward to understand as the C/C++ code, it is still not that complicated, and it is very useful to understand it when you want to extract the most out of a GPU.','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-10 14:56:22','2014-09-10 14:56:22','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6594,17795,'2014-09-10 15:21:01','2014-09-10 15:21:01','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a>, I have shown how to generate PTX files from both CUDA and OpenCL kernels. But how does a PTX file looks like, and more importantly, how to understand all those complicated instruction on PTX files?\r\n\r\nIn this post I will use the same vector addition kernel that was used in that <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a> and show what a PTX file looks like and also explain it in detail. For this post, I will use the OpenCL PTX file, in my next post I will show the differences between PTX files of OpenCL and CUDA code. Let\'s start by looking at the complete PTX code:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n    add.s32         %r10, %r8, %r5;\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nThe file starts with a header showing some compiler information in comments, followed by three lines containing the PTX ISA version, target architecture (compute capability) and addressing size being used.\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n</pre>\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name.\r\n\r\n<pre>\r\n.entry add_vectors(\r\n...\r\n)\r\n</pre>\r\n\r\nThe parameters for this kernel are three pointers to 32-bit integers global memory arrays (notice that there is no distinction from constant to non-constant pointers), and one 32-bit integer argument (the length of our vectors).\r\n\r\nEach parameter of a function starts with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case, which in the example are all compiled into 32-bit unsigned integers (for extended information on data types, refer to <a href=\"http://docs.nvidia.com/cuda/parallel-thread-execution/\">PTX ISA documentation</a>). The arguments which are pointers are then followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space) and finally the data alignment, which is <code>.align 4</code> for 4 bytes alignment.\r\n\r\n<pre>\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n</pre>\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type and its name (note that references to registers are always preceded by the <code>%</code> sign). Registers with the data type defined by <code>.pred</code> directive are used for conditional assignments, to control a branch instruction, for example. The PTX format also supports virtual registers, and a set of registers can be defined by including the number N of virtual registers inside <code><N></code>, with them being addressable as <code>r0, r1, ..., rN-1</code>, where <code>r</code> is the name given to the set of registers.\r\n\r\n<pre>\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n</pre>\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register, but the second argument is an address, so it must be inside brackets, as in <code>[add_vectors_param_3]</code>. This copy to a register is necessary as most of PTX instructions cannot handle function parameters directly. See that all data related directives end with the data type that is being processed.\r\n\r\n<pre>\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n</pre>\r\n\r\nLater, the values of some special registers are copied to the registers previously defined, they are:\r\n<ul>\r\n<li><code>envreg3</code>: read-only driver-defined special register;</li>\r\n<li><code>ntid.x</code>: number of threads per CTA, Cooperative Thread Array, in x dimension, equivalent to get_local_size(0);</li>\r\n<li><code>ctaid.x</code>: identifier of CTA within a grid, equivalent to get_group_id(0);</li>\r\n<li><code>tid.x</code>: thread identifier in the x dimension of CTA, equivalent to get_local_id(0).</li>\r\n</ul>\r\n\r\n<pre>\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n</pre>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since <code>envreg3</code> is not directly part of the code but a driver-specific computation, I won\'t go into more details about it (note that <code>envreg</code> does not appear in PTX of the CUDA code for this kernel).\r\n\r\n<pre>\r\n    add.s32         %r10, %r8, %r5;\r\n</pre>\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), which is done by multiplying second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code>) and stored back to the first argument (<code>r4</code>).\r\n\r\n<pre>\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n</pre>\r\n\r\nThe first conditional case is then reached, which is composed by the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing second argument (in our case, the global thread ID) to the third argument (number of elements of input vector) using the condition the condition stated after <code>setp</code>, in this case being <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target <code>BB0_2</code> (target must be a label, or register pointing to address of a label) and continues execution from there, if false, just continues execution without branching. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction.\r\n\r\n<pre>\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n</pre>\r\n\r\nThe real data processing is done by instructions under label <code>BB0_2</code>, which calculates data pointers, loads data from global memory, perform calculations and stores it back to global memory. Since we are dealing with 32-bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID. The result in <code>r11</code> is then added to the addresses pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code>), resulting in the address where the data that will be processed by the thread lies in memory.\r\n\r\n<pre>\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n</pre>\r\n\r\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the pointer to a memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is then stored in register passed as the first argument. After the resulting value is calculated by adding both values read from memory, and memory address where result will be stored is calculated, it is stored in global memory with instruction to <code>ld.global</code> that is <code>st.global</code>. In the storage to memory case, the first argument is the address, so that is the one inside brackets. Finally, the return instruction <code>ret</code> is called and the processing is finished.\r\n\r\n<pre>\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n</pre>\r\n\r\nAs the PTX might not be as straightforward to understand as the C/C++ code, it is still not that complicated, and it is very useful to understand it when you want to extract the most out of a GPU.','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-10 15:21:01','2014-09-10 15:21:01','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6595,17795,'2014-09-10 15:24:01','2014-09-10 15:24:01','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a>, I have shown how to generate PTX files from both CUDA and OpenCL kernels. But how does a PTX file looks like, and more importantly, how to understand all those complicated instruction on PTX files?\r\n\r\nIn this post I will use the same vector addition kernel that was used in that <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a> and show what a PTX file looks like and also explain it in detail. For this post, I will use the OpenCL PTX file, in my next post I will show the differences between PTX files of OpenCL and CUDA code. Let\'s start by looking at the complete PTX code:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n    add.s32         %r10, %r8, %r5;\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nThe file starts with a header showing some compiler information in comments, followed by three lines containing the PTX ISA version, target architecture (compute capability) and addressing size being used.\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n</pre>\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name.\r\n\r\n<pre>\r\n.entry add_vectors(\r\n...\r\n)\r\n</pre>\r\n\r\nThe parameters for this kernel are three pointers to 32-bit integers global memory arrays (notice that there is no distinction from constant to non-constant pointers), and one 32-bit integer argument (the length of our vectors).\r\n\r\nEach parameter of a function starts with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case, which in the example are all compiled into 32-bit unsigned integers (for extended information on data types, refer to <a href=\"http://docs.nvidia.com/cuda/parallel-thread-execution/\">PTX ISA documentation</a>). The arguments which are pointers are then followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space) and finally the data alignment, which is <code>.align 4</code> for 4 bytes alignment.\r\n\r\n<pre>\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n</pre>\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type and its name (note that references to registers are always preceded by the <code>%</code> sign). Registers with the data type defined by <code>.pred</code> directive are used for conditional assignments, to control a branch instruction, for example. The PTX format also supports virtual registers, and a set of registers can be defined by including the number N of virtual registers inside <code><N></code>, with them being addressable as <code>r0, r1, ..., rN-1</code>, where <code>r</code> is the name given to the set of registers.\r\n\r\n<pre>\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n</pre>\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register, but the second argument is an address, so it must be inside brackets, as in <code>[add_vectors_param_3]</code>. This copy to a register is necessary as most of PTX instructions cannot handle function parameters directly. See that all data related directives end with the data type that is being processed.\r\n\r\n<pre>\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n</pre>\r\n\r\nLater, the values of some special registers are copied to the registers previously defined, they are:\r\n<ul>\r\n<li><code>envreg3</code>: read-only driver-defined special register;</li>\r\n<li><code>ntid.x</code>: number of threads per CTA, Cooperative Thread Array, in x dimension, equivalent to get_local_size(0);</li>\r\n<li><code>ctaid.x</code>: identifier of CTA within a grid, equivalent to get_group_id(0);</li>\r\n<li><code>tid.x</code>: thread identifier in the x dimension of CTA, equivalent to get_local_id(0).</li>\r\n</ul>\r\n\r\n<pre>\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n</pre>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since <code>envreg3</code> is not directly part of the code but a driver-specific computation, I won\'t go into more details about it (note that <code>envreg</code> does not appear in PTX of the CUDA code for this kernel).\r\n\r\n<pre>\r\n    add.s32         %r10, %r8, %r5;\r\n</pre>\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), which is done by multiplying second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code>) and stored back to the first argument (<code>r4</code>).\r\n\r\n<pre>\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n</pre>\r\n\r\nThe first conditional case is then reached, which is composed by the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing second argument (in our case, the global thread ID) to the third argument (number of elements of input vector) using the condition the condition stated after <code>setp</code>, in this case being <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target <code>BB0_2</code> (target must be a label, or register pointing to address of a label) and continues execution from there, if false, just continues execution without branching. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction.\r\n\r\n<pre>\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n</pre>\r\n\r\nThe real data processing is done by instructions under label <code>BB0_2</code>, which calculates data pointers, loads data from global memory, perform calculations and stores it back to global memory. Since we are dealing with 32-bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID. The result in <code>r11</code> is then added to the addresses pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code>), resulting in the address where the data that will be processed by the thread lies in memory.\r\n\r\n<pre>\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n</pre>\r\n\r\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the pointer to a memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is then stored in register passed as the first argument. After the resulting value is calculated by adding both values read from memory, and memory address where result will be stored is calculated, it is stored in global memory with instruction to <code>ld.global</code> that is <code>st.global</code>. In the storage to memory case, the first argument is the address, so that is the one inside brackets. Finally, the return instruction <code>ret</code> is called and the processing is finished.\r\n\r\n<pre>\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n</pre>\r\n\r\nAs the PTX might not be as straightforward to understand as the C/C++ code, it is still not that complicated, in my opinion being easier to understand than pure assembly for most architectures, as we do not have to handle lots of interrupts, for example. Understanding PTX code can significantly help you understand what the compiler is actually doing with you C/C++ code, and how it will behave in the hardware. In some cases, this can be an important tool to take the most advantage out of your GPU.','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-10 15:24:01','2014-09-10 15:24:01','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6596,17795,'2014-09-11 00:29:40','2014-09-11 00:29:40','Here at ArrayFire, we develop code that will work efficiently on both CUDA and OpenCL platforms. Therefore, it is not uncommon that CUDA code on NVIDIA GPUs will run faster than OpenCL. A very good way to understand what is behind the curtains is to generate the PTX file for both cases and compare them. In this post, we show how to generate PTX for both CUDA and OpenCL kernels.\n\nPTX stands for <a title=\"Parallel Thread eXecution\" href=\"http://docs.nvidia.com/cuda/parallel-thread-execution\">Parallel Thread eXecution</a>, which is a low-level virtual machine and instruction set architecture (ISA). For those familiar with assembly language, the PTX instruction set is not really more complicated than a single thread assembly code, except that now we are thinking in massive parallel execution.\n\nRetrieving the PTX file from a CUDA kernel is a pretty straightforward process. First, we need a CUDA kernel, we will use the following code for this article, a simple vector addition kernel.\n<pre>__global__ void add_vectors(\n    const float* a,\n    const float* b,\n    float *c,\n    const int n)\n{\n    const int idx = blockIdx.x * blockDim.x + threadIdx.x;\n\n    if (idx <= n) return;\n\n    c[idx] = a[idx] + b[idx];\n}\n</pre>\nFor simplicity assume that this function is saved to  <code>add_vectors.cu.</code> Now we simply call the NVCC compiler with the <code>--ptx</code> argument.\n<pre>nvcc --ptx add_vectors.cu\n</pre>\nThe compiler output is a text file named <code>add_vectors.ptx</code>.\n\nRetrieving the PTX file for an OpenCL file is somewhat more challenging. Those of you familiar with OpenCL are probably not surprised. Retrieving the PTX coderequires host-side code and the OpenCL file which is only extracted at runtime. This means that the host-side code is necessary for compilation of the OpenCL function whereas this was not necessary for the CUDA code.\n\nThe OpenCL kernel will be very similar to the CUDA kernel and can be saved with any name, here we will use <code>add_vectors.cl</code>, just be aware of the file name to pass the correct one to the host-side code. Below the vector addition kernel adapted to OpenCL is provided.\n<pre>__kernel void add_vectors(\n    __global const int* a,\n    __global const int* b,\n    __global       int* c,\n    int n)\n{\n    int idx = get_global_id(0);\n\n    if (idx <= n) return;\n\n    c[idx] = a[idx] + b[idx];\n}\n</pre>\nFinally, we need the host-side code. A minimalist version (without actually executing the OpenCL kernel) follows.\n<pre>#include \n#include \n\n#ifdef __APPLE__\n#include <OpenCL/opencl.h>\n#else\n#include <CL/cl.h>\n#endif\n\nint main(int argc, char* argv[])\n{\n    // Loads add_vectors.cl\n    FILE* fp;\n    fp = fopen(\"add_vectors.cl\", \"r\");\n    if (!fp) {\n        fprintf(stderr, \"Error loading kernel.\\n\");\n        exit(1);\n    }\n\n    fseek(fp, 0, SEEK_END);\n    size_t kernel_sz = ftell(fp);\n    rewind(fp);\n\n    char* kernel_str = (char*)malloc(kernel_sz);\n    fread(kernel_str, 1, kernel_sz, fp);\n    fclose(fp);\n\n    // Query platforms and devices\n    cl_platform_id platform;\n    cl_device_id device;\n    cl_uint num_devices, num_platforms;\n    cl_int err = clGetPlatformIDs(1, &platform, &num_platforms);\n    err = clGetDeviceIDs(platform, CL_DEVICE_TYPE_ALL, 1,\n                         &device, &num_devices);\n\n    // Create OpenCL context\n    cl_context context = clCreateContext(NULL, 1, &device, NULL, NULL, &err);\n\n    // Create OpenCL command queue\n    cl_command_queue command_queue = clCreateCommandQueue(context, device, 0, &err);\n\n    // Create OpenCL program for add_vectors.cl\n    cl_program program = clCreateProgramWithSource(context, 1,\n            (const char **)&kernel_str, (const size_t *)&kernel_sz, &err);\n\n    // Build OpenCL program\n    err = clBuildProgram(program, 1, &device, NULL, NULL, NULL);\n\n    // Create OpenCL kernel\n    cl_kernel kernel = clCreateKernel(program, \"add_vectors\", &err);\n\n    // Query binary (PTX file) size\n    size_t bin_sz;\n    err = clGetProgramInfo(program, CL_PROGRAM_BINARY_SIZES, sizeof(size_t), &bin_sz, NULL);\n\n    // Read binary (PTX file) to memory buffer\n    unsigned char *bin = (unsigned char *)malloc(bin_sz);\n    err = clGetProgramInfo(program, CL_PROGRAM_BINARIES, sizeof(unsigned char *), &bin, NULL);\n\n    // Save PTX to add_vectors_ocl.ptx\n    fp = fopen(\"add_vectors_ocl.ptx\", \"wb\");\n    fwrite(bin, sizeof(char), bin_sz, fp);\n    fclose(fp);\n    free(bin);\n\n    // Release OpenCL resources\n    clFlush(command_queue);\n    clFinish(command_queue);\n    clReleaseKernel(kernel);\n    clReleaseProgram(program);\n    clReleaseCommandQueue(command_queue);\n    clReleaseContext(context);\n    return 0;\n}\n</pre>\nTo compile the code above with GCC, it is necessary only to pass the OpenCL include files to the compiler and the OpenCL library to the linker. The code should also compile under Visual Studio with little or no changes.\n<pre>gcc -Wall -g add_vectors.c -o add_vectors -I/usr/local/cuda/include -lOpenCL\n</pre>\nFinally, the code can be executed and the PTX will be saved to the file <code>add_vectors_ocl.ptx</code>. Note that for this simple example the PTX will only be extracted if the device 0 is an NVIDIA device, otherwise, it will not be a PTX file.\n\nIf you think the host-side code is too long and complicated, don\'t worry, check the <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">Quest for the Smallest OpenCL Program</a>. One of our engineers wrote a blog that uses the C++ API of OpenCL and he explains how to write simple and short OpenCL code. With few changes, it is possible to use the short C++ code to extract the PTX file from OpenCL kernels.\n\nThe code along\n\nWe plan on following up this blog and discuss in more depth analysing PTX for both CUDA and OpenCL kernels, altogether with a more general host-side code. We will introduce some simple but interesting methods that we use that help us understand and improve code performance. So stay in touch!','Generating PTX files from OpenCL code','','inherit','open','open','','6495-autosave-v1','','','2014-09-11 00:29:40','2014-09-11 00:29:40','',6495,'http://sandbox.arrayfire.com/6495-autosave-v1/',0,'revision','',0),(6597,17795,'2014-09-11 00:30:17','2014-09-11 00:30:17','Here at ArrayFire, we develop code that will work efficiently on both CUDA and OpenCL platforms. Therefore, it is not uncommon that CUDA code on NVIDIA GPUs will run faster than OpenCL. A very good way to understand what is behind the curtains is to generate the PTX file for both cases and compare them. In this post, we show how to generate PTX for both CUDA and OpenCL kernels.\r\n\r\nPTX stands for <a title=\"Parallel Thread eXecution\" href=\"http://docs.nvidia.com/cuda/parallel-thread-execution\">Parallel Thread eXecution</a>, which is a low-level virtual machine and instruction set architecture (ISA). For those familiar with assembly language, the PTX instruction set is not really more complicated than a single thread assembly code, except that now we are thinking in massive parallel execution.\r\n\r\nRetrieving the PTX file from a CUDA kernel is a pretty straightforward process. First, we need a CUDA kernel, we will use the following code for this article, a simple vector addition kernel.\r\n<pre>__global__ void add_vectors(\r\n    const float* a,\r\n    const float* b,\r\n    float *c,\r\n    const int n)\r\n{\r\n    const int idx = blockIdx.x * blockDim.x + threadIdx.x;\r\n\r\n    if (idx <= n) return;\r\n\r\n    c[idx] = a[idx] + b[idx];\r\n}\r\n</pre>\r\nFor simplicity assume that this function is saved to  <code>add_vectors.cu.</code> Now we simply call the NVCC compiler with the <code>--ptx</code> argument.\r\n<pre>nvcc --ptx add_vectors.cu\r\n</pre>\r\nThe compiler output is a text file named <code>add_vectors.ptx</code>.\r\n\r\nRetrieving the PTX file for an OpenCL file is somewhat more challenging. Those of you familiar with OpenCL are probably not surprised. Retrieving the PTX coderequires host-side code and the OpenCL file which is only extracted at runtime. This means that the host-side code is necessary for compilation of the OpenCL function whereas this was not necessary for the CUDA code.\r\n\r\nThe OpenCL kernel will be very similar to the CUDA kernel and can be saved with any name, here we will use <code>add_vectors.cl</code>, just be aware of the file name to pass the correct one to the host-side code. Below the vector addition kernel adapted to OpenCL is provided.\r\n<pre>__kernel void add_vectors(\r\n    __global const int* a,\r\n    __global const int* b,\r\n    __global       int* c,\r\n    int n)\r\n{\r\n    int idx = get_global_id(0);\r\n\r\n    if (idx <= n) return;\r\n\r\n    c[idx] = a[idx] + b[idx];\r\n}\r\n</pre>\r\nFinally, we need the host-side code. A minimalist version (without actually executing the OpenCL kernel) follows.\r\n<pre>#include \r\n#include \r\n\r\n#ifdef __APPLE__\r\n#include <OpenCL/opencl.h>\r\n#else\r\n#include <CL/cl.h>\r\n#endif\r\n\r\nint main(int argc, char* argv[])\r\n{\r\n    // Loads add_vectors.cl\r\n    FILE* fp;\r\n    fp = fopen(\"add_vectors.cl\", \"r\");\r\n    if (!fp) {\r\n        fprintf(stderr, \"Error loading kernel.\\n\");\r\n        exit(1);\r\n    }\r\n\r\n    fseek(fp, 0, SEEK_END);\r\n    size_t kernel_sz = ftell(fp);\r\n    rewind(fp);\r\n\r\n    char* kernel_str = (char*)malloc(kernel_sz);\r\n    fread(kernel_str, 1, kernel_sz, fp);\r\n    fclose(fp);\r\n\r\n    // Query platforms and devices\r\n    cl_platform_id platform;\r\n    cl_device_id device;\r\n    cl_uint num_devices, num_platforms;\r\n    cl_int err = clGetPlatformIDs(1, &platform, &num_platforms);\r\n    err = clGetDeviceIDs(platform, CL_DEVICE_TYPE_ALL, 1,\r\n                         &device, &num_devices);\r\n\r\n    // Create OpenCL context\r\n    cl_context context = clCreateContext(NULL, 1, &device, NULL, NULL, &err);\r\n\r\n    // Create OpenCL command queue\r\n    cl_command_queue command_queue = clCreateCommandQueue(context, device, 0, &err);\r\n\r\n    // Create OpenCL program for add_vectors.cl\r\n    cl_program program = clCreateProgramWithSource(context, 1,\r\n            (const char **)&kernel_str, (const size_t *)&kernel_sz, &err);\r\n\r\n    // Build OpenCL program\r\n    err = clBuildProgram(program, 1, &device, NULL, NULL, NULL);\r\n\r\n    // Create OpenCL kernel\r\n    cl_kernel kernel = clCreateKernel(program, \"add_vectors\", &err);\r\n\r\n    // Query binary (PTX file) size\r\n    size_t bin_sz;\r\n    err = clGetProgramInfo(program, CL_PROGRAM_BINARY_SIZES, sizeof(size_t), &bin_sz, NULL);\r\n\r\n    // Read binary (PTX file) to memory buffer\r\n    unsigned char *bin = (unsigned char *)malloc(bin_sz);\r\n    err = clGetProgramInfo(program, CL_PROGRAM_BINARIES, sizeof(unsigned char *), &bin, NULL);\r\n\r\n    // Save PTX to add_vectors_ocl.ptx\r\n    fp = fopen(\"add_vectors_ocl.ptx\", \"wb\");\r\n    fwrite(bin, sizeof(char), bin_sz, fp);\r\n    fclose(fp);\r\n    free(bin);\r\n\r\n    // Release OpenCL resources\r\n    clFlush(command_queue);\r\n    clFinish(command_queue);\r\n    clReleaseKernel(kernel);\r\n    clReleaseProgram(program);\r\n    clReleaseCommandQueue(command_queue);\r\n    clReleaseContext(context);\r\n    return 0;\r\n}\r\n</pre>\r\nTo compile the code above with GCC, it is necessary only to pass the OpenCL include files to the compiler and the OpenCL library to the linker. The code should also compile under Visual Studio with little or no changes.\r\n<pre>gcc -Wall -g add_vectors.c -o add_vectors -I/usr/local/cuda/include -lOpenCL\r\n</pre>\r\nFinally, the code can be executed and the PTX will be saved to the file <code>add_vectors_ocl.ptx</code>. Note that for this simple example the PTX will only be extracted if the device 0 is an NVIDIA device, otherwise, it will not be a PTX file.\r\n\r\nIf you think the host-side code is too long and complicated, don\'t worry, check the <a href=\"http://sandbox.arrayfire.com/quest-for-the-smallest-opencl-program/\">Quest for the Smallest OpenCL Program</a>. One of our engineers wrote a blog that uses the C++ API of OpenCL and he explains how to write simple and short OpenCL code. With few changes, it is possible to use the short C++ code to extract the PTX file from OpenCL kernels.\r\n\r\nThe complete code along with Makefile and instructions to build it can be found <a href=\"https://github.com/pentschev/ptxtract\">here</a>.\r\n\r\nWe plan on following up this blog and discuss in more depth analysing PTX for both CUDA and OpenCL kernels, altogether with a more general host-side code. We will introduce some simple but interesting methods that we use that help us understand and improve code performance. So stay in touch!','Generating PTX files from OpenCL code','','inherit','open','open','','6495-revision-v1','','','2014-09-11 00:30:17','2014-09-11 00:30:17','',6495,'http://sandbox.arrayfire.com/6495-revision-v1/',0,'revision','',0),(6598,17795,'2014-09-11 00:51:56','2014-09-11 00:51:56','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a>, I have shown how to generate PTX files from both CUDA and OpenCL kernels. But how does a PTX file looks like, and more importantly, how to understand all those complicated instructions on PTX files?\r\n\r\nIn this post I will use the same vector addition kernel that was used in that <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a> (the complete code can be found <a href=\"https://github.com/pentschev/ptxtract\">here</a>), showing what a PTX file looks like and explaining it in detail.\r\n\r\nFor this post, I will use the OpenCL PTX file, in my next post I will show the differences between PTX files of OpenCL and CUDA code. Let\'s start by looking at the complete PTX code:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n    add.s32         %r10, %r8, %r5;\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nThe file starts with a header showing some compiler information in comments, followed by three lines containing the PTX ISA version, target architecture (compute capability) and addressing that will used.\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n</pre>\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name.\r\n\r\n<pre>\r\n.entry add_vectors(\r\n...\r\n)\r\n</pre>\r\n\r\nThe parameters for this kernel are three pointers to 32-bit integers global memory arrays (notice that there is no distinction from constant to non-constant pointers and memory!), and one 32-bit integer argument (the length of input and output vectors).\r\n\r\nEach parameter of a function starts with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case, which in the example are all compiled into 32-bit unsigned integers (for extended information on data types, refer to <a href=\"http://docs.nvidia.com/cuda/parallel-thread-execution/\">PTX ISA documentation</a>). The pointer arguments are followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space) and finally the data alignment, which is <code>.align 4</code> for 4 bytes alignment.\r\n\r\n<pre>\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n</pre>\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type and its name (note that references to registers are always preceded by the <code>%</code> sign). Registers with the <code>.pred</code> data type are used for conditional assignments, to control a branch instruction, for example. The PTX format also supports virtual registers, and a set of registers can be defined by including the number N of virtual registers inside <code>< ></code>, with them being addressable as <code>r0, r1, ..., rN-1</code>, when <code>r</code> is the name given to the set of registers.\r\n\r\n<pre>\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n</pre>\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register. Because the second argument is an address, it must be inside brackets, as in <code>[add_vectors_param_3]</code>. This copy to a register is necessary as most of PTX instructions can not handle function parameters directly. See that all data related directives end with the data type being processed.\r\n\r\n<pre>\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n</pre>\r\n\r\nLater, the values of some special registers are copied to GPU registers, they are:\r\n<ul>\r\n<li><code>envreg3</code>: read-only driver-defined special register;</li>\r\n<li><code>ntid.x</code>: number of threads per CTA, Cooperative Thread Array, in x dimension, equivalent to get_local_size(0);</li>\r\n<li><code>ctaid.x</code>: identifier of CTA within a grid, equivalent to get_group_id(0);</li>\r\n<li><code>tid.x</code>: thread identifier in the x dimension of CTA, equivalent to get_local_id(0).</li>\r\n</ul>\r\n\r\n<pre>\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n</pre>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since <code>envreg3</code> is not directly part of the code, but instead a driver-specific computation, I will not go into more details about it (note that <code>envreg</code> does not appear in PTX of the equivalent CUDA kernel).\r\n\r\n<pre>\r\n    add.s32         %r10, %r8, %r5;\r\n</pre>\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), which is done by multiplying second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code>) and stored back to the first argument (<code>r4</code>).\r\n\r\n<pre>\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n</pre>\r\n\r\nThe first conditional case is then reached (the only one in this example), which is composed by the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing second argument (in our case, the global thread ID) to the third argument (number of elements of input/output vectors) using the condition stated after <code>setp</code>, in this case <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target <code>BB0_2</code> (target must be a label or register pointing to the address of a label) and continues execution from there, if false, just continues execution without branching. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction that comes immediately after.\r\n\r\n<pre>\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n</pre>\r\n\r\nThe real data processing is done by the set of instructions under label <code>BB0_2</code>, which calculates data pointers, loads data from global memory, performs calculations and stores results back to global memory. Since we are dealing with 32-bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID. The result in <code>r11</code> is then added to the addresses pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code>), resulting in the addresses where the data that needs to be processed by the thread lies in memory.\r\n\r\n<pre>\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n</pre>\r\n\r\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the pointer to a memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is then stored into the register passed as the first argument. After the resulting value is calculated by adding both values read from memory, and memory address where result will be stored is calculated, it is stored in global memory with complimentary instruction to <code>ld.global</code>, that is <code>st.global</code>. In the storage to memory case, the first argument is the address, that is the argument inside brackets. Finally, the return instruction <code>ret</code> is called and the processing is finished.\r\n\r\n<pre>\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n</pre>\r\n\r\nAs the PTX might not be as straightforward to understand as the C/C++ code, in my opinion is still easier to understand than pure assembly for most architectures, as we do not have to handle lots of interrupts, for example. Understanding PTX code can significantly help you understand what the compiler is actually doing with you C/C++ code, and how the program will flow through hardware. In some cases, this can be an important tool to put your GPU to full power.\r\n\r\n','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-11 00:51:56','2014-09-11 00:51:56','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6599,17796,'2014-09-11 17:24:21','2014-09-11 17:24:21','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">recent post</a>, I showed how to generate PTX files from both CUDA and OpenCL kernels. In this post I will address the issue of how a PTX file look, and more importantly, how to understand all those complicated instructions in a PTX files.\nIn this post I will use the same vector addition kernel from the the previous post <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a> (the complete code can be found <a href=\"https://github.com/pentschev/ptxtract\">here</a>).\n\nFor this post, I will focus on OpenCL PTX file. In a future post I will discuss the differences between PTX files of OpenCL and CUDA code. Let\'s start by looking at the complete PTX code:\n\n<pre>\n//\n// Generated by NVIDIA NVVM Compiler\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\n// Driver 331.79\n//\n\n.version 3.0\n.target sm_21, texmode_independent\n.address_size 32\n\n\n.entry add_vectors(\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\n    .param .u32 add_vectors_param_3\n)\n{\n    .reg .pred      %p<2>;\n    .reg .s32       %r<21>;\n\n\n    ld.param.u32    %r9, [add_vectors_param_3];\n    mov.u32         %r5, %envreg3;\n    mov.u32         %r6, %ntid.x;\n    mov.u32         %r7, %ctaid.x;\n    mov.u32         %r8, %tid.x;\n    add.s32         %r10, %r8, %r5;\n    mad.lo.s32      %r4, %r7, %r6, %r10;\n    setp.lt.s32     %p1, %r4, %r9;\n    @%p1 bra        BB0_2;\n\n    ret;\n\nBB0_2:\n    shl.b32         %r11, %r4, 2;\n    ld.param.u32    %r18, [add_vectors_param_0];\n    add.s32         %r12, %r18, %r11;\n    ld.param.u32    %r19, [add_vectors_param_1];\n    add.s32         %r13, %r19, %r11;\n    ld.global.u32   %r14, [%r13];\n    ld.global.u32   %r15, [%r12];\n    add.s32         %r16, %r14, %r15;\n    ld.param.u32    %r20, [add_vectors_param_2];\n    add.s32         %r17, %r20, %r11;\n    st.global.u32   [%r17], %r16;\n    ret;\n}\n</pre>\n\nThe file starts with a header showing some compiler information in comments, followed by three lines containing the 1) PTX ISA version, 2) target architecture (compute capability), and 3) address-mode that will used.\n\n<pre>\n//\n// Generated by NVIDIA NVVM Compiler\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\n// Driver 331.79\n//\n\n.version 3.0\n.target sm_21, texmode_independent\n.address_size 32\n</pre>\n\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name.\n\n<pre>\n.entry add_vectors(\n...\n)\n</pre>\n\nThe parameters for this kernel are three pointers to 32-bit integers global memory arrays (notice that there isn\'t a distinction from constant to non-constant pointers and memory!), and one 32-bit integer argument (the length of input and output vectors).\n\nEach parameter of a function starts with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case. In this example all the variables are 32-bit unsigned integers (for extended information on data types, refer to <a href=\"http://docs.nvidia.com/cuda/parallel-thread-execution/\">PTX ISA documentation</a>). The pointer arguments are followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space), and finally the data alignment  which specifies the alignment (in this case <code>.align 4</code> represents 4 bytes alignment).\n\n<pre>\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\n    .param .u32 add_vectors_param_3\n</pre>\n\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type and its name (note that references to registers are always preceded by the <code>%</code> sign). Registers with the <code>.pred</code> keyword are used for conditional assignments, such as in the case of branch instructions. The PTX format also supports virtual registers, and a set of registers can be defined by including the number N of virtual registers inside <code>< ></code>, with them being addressable as <code>r0, r1, ..., rN-1</code>, when <code>r</code> is the name given to the set of registers.\n\n<pre>\n    .reg .pred      %p<2>;\n    .reg .s32       %r<21>;\n</pre>\n\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register. Because the second argument is an address, it must be inside brackets, as in <code>[add_vectors_param_3]</code>. Copying the parameter to a register is necessary as most PTX instructions can not handle function parameters directly. \n\n<pre>\n    ld.param.u32    %r9, [add_vectors_param_3];\n</pre>\n\nLater, the values of some special registers are copied to GPU registers, they are:\n<ul>\n<li><code>envreg3</code>: read-only driver-defined special register;</li>\n<li><code>ntid.x</code>: number of threads per CTA, Cooperative Thread Array, in x dimension, equivalent to get_local_size(0);</li>\n<li><code>ctaid.x</code>: identifier of CTA within a grid, equivalent to get_group_id(0);</li>\n<li><code>tid.x</code>: thread identifier in the x dimension of CTA, equivalent to get_local_id(0).</li>\n</ul>\n\n<pre>\n    mov.u32         %r5, %envreg3;\n    mov.u32         %r6, %ntid.x;\n    mov.u32         %r7, %ctaid.x;\n    mov.u32         %r8, %tid.x;\n</pre>\n\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since <code>envreg3</code> is not directly part of the code, but instead a driver-specific computation, I will not go into more details about it (note that <code>envreg</code> does not appear in PTX of the equivalent CUDA kernel).\n\n<pre>\n    add.s32         %r10, %r8, %r5;\n</pre>\n\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), this is done by multiplying the second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code>) and stored back to the first argument (<code>r4</code>).\n\n<pre>\n    mad.lo.s32      %r4, %r7, %r6, %r10;\n</pre>\n\nThe first conditional instruction is then reached (the only one in this example), which consists of the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing the second argument (the global thread ID in this example) to the third argument (number of elements of input/output vectors) using the condition stated after <code>setp</code>, in this case <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target <code>BB0_2</code> (target must be a label or register pointing to the address of a label) and continues execution from there, if false, just continues execution without branching. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction that comes immediately after.\n\n<pre>\n    setp.lt.s32     %p1, %r4, %r9;\n    @%p1 bra        BB0_2;\n\n    ret;\n</pre>\n\nThe real data processing is done by the set of instructions under label <code>BB0_2</code>, which calculates data pointers, loads data from global memory, performs calculations and stores results back to global memory. Since we are dealing with 32-bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID. The result in <code>r11</code> is then added to the addresses pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code>), resulting in the addresses where the data that needs to be processed by the thread lies in memory.\n\n<pre>\nBB0_2:\n    shl.b32         %r11, %r4, 2;\n    ld.param.u32    %r18, [add_vectors_param_0];\n    add.s32         %r12, %r18, %r11;\n    ld.param.u32    %r19, [add_vectors_param_1];\n    add.s32         %r13, %r19, %r11;\n</pre>\n\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the pointer to a memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is then stored into the register passed as the first argument. After the resulting value is calculated by adding both values read from memory, and memory address where result will be stored is calculated, it is stored in global memory with complimentary instruction to <code>ld.global</code>, that is <code>st.global</code>. In the storage to memory case, the first argument is the address, that is the argument inside brackets. Finally, the return instruction <code>ret</code> is called and the processing is finished.\n\n<pre>\n    ld.global.u32   %r14, [%r13];\n    ld.global.u32   %r15, [%r12];\n    add.s32         %r16, %r14, %r15;\n    ld.param.u32    %r20, [add_vectors_param_2];\n    add.s32         %r17, %r20, %r11;\n    st.global.u32   [%r17], %r16;\n    ret;\n</pre>\n\nWhile PTX code might not be as straightforward to understand as the C/C++ code, in my opinion is still easier to understand than pure assembly for most architectures, as we do not have to handle lots of interrupts, for example. Understanding PTX code can significantly help you understand what the compiler is actually doing with your C/C++ code, and how the program will flow through hardware. In some cases, this can be an important tool to put your GPU to full power.\n\n','Demystifying PTX Code','','inherit','open','open','','6581-autosave-v1','','','2014-09-11 17:24:21','2014-09-11 17:24:21','',6581,'http://sandbox.arrayfire.com/6581-autosave-v1/',0,'revision','',0),(6600,17796,'2014-09-11 04:02:19','2014-09-11 04:02:19','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">recent post</a>, I showed how to generate PTX files from both CUDA and OpenCL kernels. In this post I will address the issue of how a PTX file look, and more importantly, how to understand all those complicated instructions in a PTX files.\r\nIn this post I will use the same vector addition kernel from the the previous post <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a> (the complete code can be found <a href=\"https://github.com/pentschev/ptxtract\">here</a>).\r\n\r\nFor this post, I will focus on OpenCL PTX file. In a future post I will discuss the differences between PTX files of OpenCL and CUDA code. Let\'s start by looking at the complete PTX code:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n    add.s32         %r10, %r8, %r5;\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nThe file starts with a header showing some compiler information in comments, followed by three lines containing the 1) PTX ISA version, 2) target architecture (compute capability), and 3) address-mode that will used.\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n</pre>\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name.\r\n\r\n<pre>\r\n.entry add_vectors(\r\n...\r\n)\r\n</pre>\r\n\r\nThe parameters for this kernel are three pointers to 32-bit integers global memory arrays (notice that there isn\'t a distinction from constant to non-constant pointers and memory!), and one 32-bit integer argument (the length of input and output vectors).\r\n\r\nEach parameter of a function starts with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case. In this example all the variables are 32-bit unsigned integers (for extended information on data types, refer to <a href=\"http://docs.nvidia.com/cuda/parallel-thread-execution/\">PTX ISA documentation</a>). The pointer arguments are followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space), and finally the data alignment  which specifies the alignment (in this case <code>.align 4</code> represents 4 bytes alignment).\r\n\r\n<pre>\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n</pre>\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type and its name (note that references to registers are always preceded by the <code>%</code> sign). Registers with the <code>.pred</code> keyword are used for conditional assignments, such as in the case of branch instructions. The PTX format also supports virtual registers, and a set of registers can be defined by including the number N of virtual registers inside <code>< ></code>, with them being addressable as <code>r0, r1, ..., rN-1</code>, when <code>r</code> is the name given to the set of registers.\r\n\r\n<pre>\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n</pre>\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register. Because the second argument is an address, it must be inside brackets, as in <code>[add_vectors_param_3]</code>. This copy to a register is necessary as most of PTX instructions can not handle function parameters directly. See that all data related directives end with the data type being processed.\r\n\r\n<pre>\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n</pre>\r\n\r\nLater, the values of some special registers are copied to GPU registers, they are:\r\n<ul>\r\n<li><code>envreg3</code>: read-only driver-defined special register;</li>\r\n<li><code>ntid.x</code>: number of threads per CTA, Cooperative Thread Array, in x dimension, equivalent to get_local_size(0);</li>\r\n<li><code>ctaid.x</code>: identifier of CTA within a grid, equivalent to get_group_id(0);</li>\r\n<li><code>tid.x</code>: thread identifier in the x dimension of CTA, equivalent to get_local_id(0).</li>\r\n</ul>\r\n\r\n<pre>\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n</pre>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since <code>envreg3</code> is not directly part of the code, but instead a driver-specific computation, I will not go into more details about it (note that <code>envreg</code> does not appear in PTX of the equivalent CUDA kernel).\r\n\r\n<pre>\r\n    add.s32         %r10, %r8, %r5;\r\n</pre>\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), which is done by multiplying second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code>) and stored back to the first argument (<code>r4</code>).\r\n\r\n<pre>\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n</pre>\r\n\r\nThe first conditional case is then reached (the only one in this example), which is composed by the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing second argument (in our case, the global thread ID) to the third argument (number of elements of input/output vectors) using the condition stated after <code>setp</code>, in this case <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target <code>BB0_2</code> (target must be a label or register pointing to the address of a label) and continues execution from there, if false, just continues execution without branching. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction that comes immediately after.\r\n\r\n<pre>\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n</pre>\r\n\r\nThe real data processing is done by the set of instructions under label <code>BB0_2</code>, which calculates data pointers, loads data from global memory, performs calculations and stores results back to global memory. Since we are dealing with 32-bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID. The result in <code>r11</code> is then added to the addresses pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code>), resulting in the addresses where the data that needs to be processed by the thread lies in memory.\r\n\r\n<pre>\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n</pre>\r\n\r\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the pointer to a memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is then stored into the register passed as the first argument. After the resulting value is calculated by adding both values read from memory, and memory address where result will be stored is calculated, it is stored in global memory with complimentary instruction to <code>ld.global</code>, that is <code>st.global</code>. In the storage to memory case, the first argument is the address, that is the argument inside brackets. Finally, the return instruction <code>ret</code> is called and the processing is finished.\r\n\r\n<pre>\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n</pre>\r\n\r\nAs the PTX might not be as straightforward to understand as the C/C++ code, in my opinion is still easier to understand than pure assembly for most architectures, as we do not have to handle lots of interrupts, for example. Understanding PTX code can significantly help you understand what the compiler is actually doing with you C/C++ code, and how the program will flow through hardware. In some cases, this can be an important tool to put your GPU to full power.\r\n\r\n','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-11 04:02:19','2014-09-11 04:02:19','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6602,17796,'2014-09-11 17:26:26','2014-09-11 17:26:26','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">recent post</a>, I showed how to generate PTX files from both CUDA and OpenCL kernels. In this post I will address the issue of how a PTX file look, and more importantly, how to understand all those complicated instructions in a PTX files.\r\nIn this post I will use the same vector addition kernel from the the previous post <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a> (the complete code can be found <a href=\"https://github.com/pentschev/ptxtract\">here</a>).\r\n\r\nFor this post, I will focus on OpenCL PTX file. In a future post I will discuss the differences between PTX files of OpenCL and CUDA code. Let\'s start by looking at the complete PTX code:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n    add.s32         %r10, %r8, %r5;\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nThe file starts with a header showing some compiler information in comments, followed by three lines containing the 1) PTX ISA version, 2) target architecture (compute capability), and 3) address-mode that will used.\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n</pre>\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name.\r\n\r\n<pre>\r\n.entry add_vectors(\r\n...\r\n)\r\n</pre>\r\n\r\nThe parameters for this kernel are three pointers to 32-bit integers global memory arrays (notice that there isn\'t a distinction from constant to non-constant pointers and memory!), and one 32-bit integer argument (the length of input and output vectors).\r\n\r\nEach parameter of a function starts with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case. In this example all the variables are 32-bit unsigned integers (for extended information on data types, refer to <a href=\"http://docs.nvidia.com/cuda/parallel-thread-execution/\">PTX ISA documentation</a>). The pointer arguments are followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space), and finally the data alignment  which specifies the alignment (in this case <code>.align 4</code> represents 4 bytes alignment).\r\n\r\n<pre>\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n</pre>\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type and its name (note that references to registers are always preceded by the <code>%</code> sign). Registers with the <code>.pred</code> keyword are used for conditional assignments, such as in the case of branch instructions. The PTX format also supports virtual registers, and a set of registers can be defined by including the number N of virtual registers inside <code>< ></code>, with them being addressable as <code>r0, r1, ..., rN-1</code>, when <code>r</code> is the name given to the set of registers.\r\n\r\n<pre>\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n</pre>\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register. Because the second argument is an address, it must be inside brackets, as in <code>[add_vectors_param_3]</code>. Copying the parameter to a register is necessary as most PTX instructions can not handle function parameters directly. \r\n\r\n<pre>\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n</pre>\r\n\r\nLater, the values of some special registers are copied to GPU registers, they are:\r\n<ul>\r\n<li><code>envreg3</code>: read-only driver-defined special register;</li>\r\n<li><code>ntid.x</code>: number of threads per CTA, Cooperative Thread Array, in x dimension, equivalent to get_local_size(0);</li>\r\n<li><code>ctaid.x</code>: identifier of CTA within a grid, equivalent to get_group_id(0);</li>\r\n<li><code>tid.x</code>: thread identifier in the x dimension of CTA, equivalent to get_local_id(0).</li>\r\n</ul>\r\n\r\n<pre>\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n</pre>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since <code>envreg3</code> is not directly part of the code, but instead a driver-specific computation, I will not go into more details about it (note that <code>envreg</code> does not appear in PTX of the equivalent CUDA kernel).\r\n\r\n<pre>\r\n    add.s32         %r10, %r8, %r5;\r\n</pre>\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), this is done by multiplying the second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code>) and stored back to the first argument (<code>r4</code>).\r\n\r\n<pre>\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n</pre>\r\n\r\nThe first conditional instruction is then reached (the only one in this example), which consists of the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing the second argument (the global thread ID in this example) to the third argument (number of elements of input/output vectors) using the condition stated after <code>setp</code>, in this case <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target <code>BB0_2</code> (target must be a label or register pointing to the address of a label) and continues execution from there, if false, just continues execution without branching. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction that comes immediately after.\r\n\r\n<pre>\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n</pre>\r\n\r\nThe real data processing is done by the set of instructions under label <code>BB0_2</code>, which calculates data pointers, loads data from global memory, performs calculations and stores results back to global memory. Since we are dealing with 32-bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID. The result in <code>r11</code> is then added to the addresses pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code>), resulting in the addresses where the data that needs to be processed by the thread lies in memory.\r\n\r\n<pre>\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n</pre>\r\n\r\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the pointer to a memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is then stored into the register passed as the first argument. After the resulting value is calculated by adding both values read from memory, and memory address where result will be stored is calculated, it is stored in global memory with complimentary instruction to <code>ld.global</code>, that is <code>st.global</code>. In the storage to memory case, the first argument is the address, that is the argument inside brackets. Finally, the return instruction <code>ret</code> is called and the processing is finished.\r\n\r\n<pre>\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n</pre>\r\n\r\nWhile PTX code might not be as straightforward to understand as the C/C++ code, in my opinion is still easier to understand than pure assembly for most architectures, as we do not have to handle lots of interrupts, for example. Understanding PTX code can significantly help you understand what the compiler is actually doing with your C/C++ code, and how the program will flow through hardware. In some cases, this can be an important tool to put your GPU to full power.\r\n\r\n','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-11 17:26:26','2014-09-11 17:26:26','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6603,17795,'2014-09-11 18:03:46','2014-09-11 18:03:46','Triangle counting is a building block for many social analytics, especially for the widely used clustering coefficient analytic. Clustering coefficients is used for finding key players in a network based on their local connectivity, which is expressed based on the number of triangles that they belong to. There are many ways for finding the triangles a vertex may belong to. One of the most popular approaches for finding the triangles is to do an intersection of two adjacency lists. If a pair of vertices <em>(u,v) </em>have any common neighbors, these will be found in the intersection process.\n\nWhile the above may sound simple, implementing an efficient intersection on the GPU is not trivial or straightforward, it requires smart partitioning of the work to make full use of the thousands of available threads that modern GPUs have. We just finished such an implementation that has multiple levels of parallelism which partitions the work to the multiprocessors and to the SIMT units.\n\nFor testing purposes, we used graphs taken from the <a href=\"http://www.cc.gatech.edu/dimacs10/\">DIMACS 10 Graph Challenge</a>. Our experiments were conducted on NVIDIA\'s K40 GPU. Our GPU triangle counting implementation achieves speedups in the range of <strong>9X-32X</strong> over a CPU sequential implementation. These can be seen in the figure below.\n\n&nbsp;\n\n&nbsp;\n\n<a href=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu1.png\"><img class=\"alignnone wp-image-6544 size-full\" src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu1.png\" alt=\"gpu\" width=\"569\" height=\"286\" /></a>\n\n&nbsp;','Triangle Counting in Graphs on the GPU (Part 1)','','inherit','open','open','','6539-autosave-v1','','','2014-09-11 18:03:46','2014-09-11 18:03:46','',6539,'http://sandbox.arrayfire.com/6539-autosave-v1/',0,'revision','',0),(6604,17795,'2014-09-11 17:45:51','2014-09-11 17:45:51','Triangle counting is a building block for many social analytics, especially for the widely used clustering coefficient analytic. Clustering coefficients is used for finding key players in a network based on their local connectivity, which is expressed based on the number of triangles that they belong to. There are many ways for finding the triangles a vertex may belong to. One of the most popular approaches for finding the triangles is to do an intersection of two adjacency lists. If a pair of vertices <em>(u,v) </em>have any common neighbors, these will be found in the intersection process.\r\n\r\nWhile the above may sound simple, implementing an efficient intersection on the GPU is not trivial or straightforward, it requires smart partitioning of the work to make full use of the thousands of available threads that modern GPUs have. We just finished such an implementation that has multiple levels of parallelism which partitions the work to the multiprocessors and to the SIMT units.\r\n\r\nFor testing purposes, we used graphs taken from the <a href=\"http://www.cc.gatech.edu/dimacs10/\">DIMACS 10 Graph Challenge</a>. Our experiments were conducted on NVIDIA\'s K40 GPU. Our GPU triangle counting implementation achieves speedups in the range of $9X-32X$ over a CPU sequential implementation. These can be seen in the figure below.\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\n<a href=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu1.png\"><img class=\"alignnone wp-image-6544 size-full\" src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu1.png\" alt=\"gpu\" width=\"569\" height=\"286\" /></a>\r\n\r\n&nbsp;','Triangle Counting in Graphs On the GPU (Part 1)','','inherit','open','open','','6539-revision-v1','','','2014-09-11 17:45:51','2014-09-11 17:45:51','',6539,'http://sandbox.arrayfire.com/6539-revision-v1/',0,'revision','',0),(6605,17795,'2014-09-11 17:48:57','2014-09-11 17:48:57','Triangle counting is a building block for many social analytics, especially for the widely used clustering coefficient analytic. Clustering coefficients is used for finding key players in a network based on their local connectivity, which is expressed based on the number of triangles that they belong to. There are many ways for finding the triangles a vertex may belong to. One of the most popular approaches for finding the triangles is to do an intersection of two adjacency lists. If a pair of vertices <em>(u,v) </em>have any common neighbors, these will be found in the intersection process.\r\n\r\nWhile the above may sound simple, implementing an efficient intersection on the GPU is not trivial or straightforward, it requires smart partitioning of the work to make full use of the thousands of available threads that modern GPUs have. We just finished such an implementation that has multiple levels of parallelism which partitions the work to the multiprocessors and to the SIMT units.\r\n\r\nFor testing purposes, we used graphs taken from the <a href=\"http://www.cc.gatech.edu/dimacs10/\">DIMACS 10 Graph Challenge</a>. Our experiments were conducted on NVIDIA\'s K40 GPU. Our GPU triangle counting implementation achieves speedups in the range of <strong>9X-32X</strong> over a CPU sequential implementation. These can be seen in the figure below.\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\n<a href=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu1.png\"><img class=\"alignnone wp-image-6544 size-full\" src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu1.png\" alt=\"gpu\" width=\"569\" height=\"286\" /></a>\r\n\r\n&nbsp;','Triangle Counting in Graphs On the GPU (Part 1)','','inherit','open','open','','6539-revision-v1','','','2014-09-11 17:48:57','2014-09-11 17:48:57','',6539,'http://sandbox.arrayfire.com/6539-revision-v1/',0,'revision','',0),(6606,17795,'2014-09-11 17:55:02','2014-09-11 17:55:02','In my <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">recent post</a>, I showed how to generate PTX files from both CUDA and OpenCL kernels. In this post I will address the issue of how a PTX file look, and more importantly, how to understand all those complicated instructions in a PTX files.\r\nIn this post I will use the same vector addition kernel from the the previous post <a href=\"http://sandbox.arrayfire.com/generating-ptx-files-from-opencl-code/\">previous post</a> (the complete code can be found <a href=\"https://github.com/pentschev/ptxtract\">here</a>).\r\n\r\nFor this post, I will focus on OpenCL PTX file. In a future post I will discuss the differences between PTX files of OpenCL and CUDA code. Let\'s start by looking at the complete PTX code:\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n\r\n\r\n.entry add_vectors(\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n)\r\n{\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n\r\n\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n    add.s32         %r10, %r8, %r5;\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n}\r\n</pre>\r\n\r\nThe file starts with a header showing some compiler information in comments, followed by three lines containing the 1) PTX ISA version, 2) target architecture (compute capability), and 3) address-mode that will used.\r\n\r\n<pre>\r\n//\r\n// Generated by NVIDIA NVVM Compiler\r\n// Compiler built on Sun May 18 04:44:51 2014 (1400399091)\r\n// Driver 331.79\r\n//\r\n\r\n.version 3.0\r\n.target sm_21, texmode_independent\r\n.address_size 32\r\n</pre>\r\n\r\nImmediately after the header, the entry point of the kernel is found, starting with the <code>.entry</code> directive followed by the kernel name.\r\n\r\n<pre>\r\n.entry add_vectors(\r\n...\r\n)\r\n</pre>\r\n\r\nThe parameters for this kernel are three pointers to 32-bit integers global memory arrays (notice that there isn\'t a distinction from constant to non-constant pointers and memory!), and one 32-bit integer argument (the length of input and output vectors).\r\n\r\nEach parameter of a function starts with the <code>.param</code> directive, followed by its data type, <code>.u32</code> in our case. In this example, the compiler transformed all the function parameters into 32-bit unsigned integers (for extended information on data types, refer to <a href=\"http://docs.nvidia.com/cuda/parallel-thread-execution/\">PTX ISA documentation</a>). The pointer arguments are followed by a <code>.ptr</code> directive, the address space where they are located (<code>.global</code> for global space), and finally the data alignment  which specifies the alignment (in this case <code>.align 4</code> represents 4 bytes alignment).\r\n\r\n<pre>\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_0,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_1,\r\n    .param .u32 .ptr .global .align 4 add_vectors_param_2,\r\n    .param .u32 add_vectors_param_3\r\n</pre>\r\n\r\nImmediately after the function prototype, the code block begins. First thing in the block are register definitions, they always start with <code>.reg</code> directive, followed by the data type and its name (note that references to registers are always preceded by the <code>%</code> sign). Registers defined with the <code>.pred</code> directive are used for conditional assignments, such as in the case of branch instructions. Since PTX is an intermediary language, the registers defined are virtual and do not necessarily have a one-to-one translation to hardware registers. A set of virtual registers can be defined by including the number N of virtual registers inside <code>< ></code>, with them being addressable as <code>r0, r1, ..., rN-1</code>, when <code>r</code> is the name given to the set of registers.\r\n\r\n<pre>\r\n    .reg .pred      %p<2>;\r\n    .reg .s32       %r<21>;\r\n</pre>\r\n\r\nFollowing the register definitions, we see the <code>ld.param</code> directive, which has the ability to copy a function parameter into a register. Because the second argument is an address, it must be inside brackets, as in <code>[add_vectors_param_3]</code>. Copying the parameter to a register is necessary as most PTX instructions can not handle function parameters directly. \r\n\r\n<pre>\r\n    ld.param.u32    %r9, [add_vectors_param_3];\r\n</pre>\r\n\r\nLater, the values of some special registers are copied to GPU registers, they are:\r\n<ul>\r\n<li><code>envreg3</code>: read-only driver-defined special register;</li>\r\n<li><code>ntid.x</code>: number of threads per CTA, Cooperative Thread Array, in x dimension, equivalent to get_local_size(0);</li>\r\n<li><code>ctaid.x</code>: identifier of CTA within a grid, equivalent to get_group_id(0);</li>\r\n<li><code>tid.x</code>: thread identifier in the x dimension of CTA, equivalent to get_local_id(0).</li>\r\n</ul>\r\n\r\n<pre>\r\n    mov.u32         %r5, %envreg3;\r\n    mov.u32         %r6, %ntid.x;\r\n    mov.u32         %r7, %ctaid.x;\r\n    mov.u32         %r8, %tid.x;\r\n</pre>\r\n\r\nAfter copying these registers into locally defined registers, the real fun starts. The values of <code>envreg3</code> and <code>tid.x</code> are added and stored in register <code>r10</code>, since <code>envreg3</code> is not directly part of the code, but instead a driver-specific computation, I will not go into more details about it (note that <code>envreg</code> does not appear in PTX of the equivalent CUDA kernel).\r\n\r\n<pre>\r\n    add.s32         %r10, %r8, %r5;\r\n</pre>\r\n\r\nWith the <code>mad</code> instruction (short for multiply-add), the global thread ID is calculated (get_global_id(0)), this is done by multiplying the second and third arguments (<code>r7</code> and <code>r6</code>, holding values of <code>ntid.x</code> and <code>ctaid.x</code>), with the lower 16 bits (identified by the <code>.lo</code> suffix of <code>mad</code> instruction) of the result being later added to the fourth argument (<code>r10</code>, that holds <code>tid.x</code>) and stored back to the first argument (<code>r4</code>).\r\n\r\n<pre>\r\n    mad.lo.s32      %r4, %r7, %r6, %r10;\r\n</pre>\r\n\r\nThe first conditional instruction is then reached (the only one in this example), which consists of the <code>setp</code> instruction, followed by <code>@</code> and <code>bra</code> instructions. The <code>setp</code> instruction sets a predicate (first argument) by comparing the second argument (the global thread ID in this example) to the third argument (number of elements of input/output vectors) using the condition stated after <code>setp</code>, in this case <code>lt</code> (lower than). The <code>@</code> instruction then executes the predicate, if true, branches (by executing <code>bra</code>) to target <code>BB0_2</code> (target must be a label or register pointing to the address of a label) and continues execution from there, if false, just continues execution without branching. In the case of the condition being false, our kernel would simply return by calling the <code>ret</code> instruction that comes immediately after.\r\n\r\n<pre>\r\n    setp.lt.s32     %p1, %r4, %r9;\r\n    @%p1 bra        BB0_2;\r\n\r\n    ret;\r\n</pre>\r\n\r\nThe real data processing is done by the set of instructions under label <code>BB0_2</code>, which calculates data pointers, loads data from global memory, performs calculations and stores results back to global memory. Since we are dealing with 32-bit data pointers, the first instruction <code>shl</code> takes 32-bit untyped binary registers and shift bits left by 2 positions (equivalent to an integer multiplication by 4), this is in fact calculating the zero-based position of data according to the global thread ID. The result in <code>r11</code> is then added to the addresses pointed by the global memory pointers (after loading them to registers by instruction <code>ld.param</code>), resulting in the addresses where the data that needs to be processed by the thread lies in memory.\r\n\r\n<pre>\r\nBB0_2:\r\n    shl.b32         %r11, %r4, 2;\r\n    ld.param.u32    %r18, [add_vectors_param_0];\r\n    add.s32         %r12, %r18, %r11;\r\n    ld.param.u32    %r19, [add_vectors_param_1];\r\n    add.s32         %r13, %r19, %r11;\r\n</pre>\r\n\r\nData is loaded from global memory with instruction <code>ld.global</code>, the second parameter is a register that holds the pointer to a memory address and must be within brackets, just as we have seen before with <code>ld.param</code>. The actual data read from memory is then stored into the register passed as the first argument. After the resulting value is calculated by adding both values read from memory, and memory address where result will be stored is calculated, it is stored in global memory with complimentary instruction to <code>ld.global</code>, that is <code>st.global</code>. In the storage to memory case, the first argument is the address, that is the argument inside brackets. Finally, the return instruction <code>ret</code> is called and the processing is finished.\r\n\r\n<pre>\r\n    ld.global.u32   %r14, [%r13];\r\n    ld.global.u32   %r15, [%r12];\r\n    add.s32         %r16, %r14, %r15;\r\n    ld.param.u32    %r20, [add_vectors_param_2];\r\n    add.s32         %r17, %r20, %r11;\r\n    st.global.u32   [%r17], %r16;\r\n    ret;\r\n</pre>\r\n\r\nWhile PTX code might not be as straightforward to understand as the C/C++ code, in my opinion is still easier to understand than pure assembly for most architectures, as we do not have to handle lots of interrupts, for example. Understanding PTX code can significantly help you understand what the compiler is actually doing with your C/C++ code, and how the program will flow through hardware. In some cases, this can be an important tool to put your GPU to full power.\r\n\r\n','Demystifying PTX Code','','inherit','open','open','','6581-revision-v1','','','2014-09-11 17:55:02','2014-09-11 17:55:02','',6581,'http://sandbox.arrayfire.com/6581-revision-v1/',0,'revision','',0),(6607,17795,'2014-09-11 18:04:55','2014-09-11 18:04:55','Triangle counting is a building block for many social analytics, especially for the widely used clustering coefficient analytic. Clustering coefficients is used for finding key players in a network based on their local connectivity, which is expressed based on the number of triangles that they belong to. There are many ways for finding the triangles a vertex may belong to. One of the most popular approaches for finding the triangles is to do an intersection of two adjacency lists. If a pair of vertices <em>(u,v) </em>have any common neighbors, these will be found in the intersection process.\r\n\r\nWhile the above may sound simple, implementing an efficient intersection on the GPU is not trivial or straightforward, it requires smart partitioning of the work to make full use of the thousands of available threads that modern GPUs have. We just finished such an implementation that has multiple levels of parallelism which partitions the work to the multiprocessors and to the SIMT units.\r\n\r\nFor testing purposes, we used graphs taken from the <a href=\"http://www.cc.gatech.edu/dimacs10/\">DIMACS 10 Graph Challenge</a>. Our experiments were conducted on NVIDIA\'s K40 GPU. Our GPU triangle counting implementation achieves speedups in the range of <strong>9X-32X</strong> over a CPU sequential implementation. These can be seen in the figure below.\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\n<a href=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu1.png\"><img class=\"alignnone wp-image-6544 size-full\" src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu1.png\" alt=\"gpu\" width=\"569\" height=\"286\" /></a>\r\n\r\n&nbsp;','Triangle Counting in Graphs on the GPU (Part 1)','','inherit','open','open','','6539-revision-v1','','','2014-09-11 18:04:55','2014-09-11 18:04:55','',6539,'http://sandbox.arrayfire.com/6539-revision-v1/',0,'revision','',0),(6608,17796,'2014-09-11 18:17:28','2014-09-11 18:17:28','','gpu','','inherit','open','open','','gpu-4','','','2014-09-11 18:17:28','2014-09-11 18:17:28','',6539,'http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu2.png',0,'attachment','image/png',0),(6609,17796,'2014-09-11 18:18:10','2014-09-11 18:18:10','Triangle counting is a building block for many social analytics, especially for the widely used clustering coefficient analytic. Clustering coefficients is used for finding key players in a network based on their local connectivity, which is expressed based on the number of triangles that they belong to. There are many ways for finding the triangles a vertex may belong to. One of the most popular approaches for finding the triangles is to do an intersection of two adjacency lists. If a pair of vertices <em>(u,v) </em>have any common neighbors, these will be found in the intersection process.\r\n\r\nWhile the above may sound simple, implementing an efficient intersection on the GPU is not trivial or straightforward, it requires smart partitioning of the work to make full use of the thousands of available threads that modern GPUs have. We just finished such an implementation that has multiple levels of parallelism which partitions the work to the multiprocessors and to the SIMT units.\r\n\r\nFor testing purposes, we used graphs taken from the <a href=\"http://www.cc.gatech.edu/dimacs10/\">DIMACS 10 Graph Challenge</a>. Our experiments were conducted on NVIDIA\'s K40 GPU. Our GPU triangle counting implementation achieves speedups in the range of <strong>9X-32X</strong> over a CPU sequential implementation. These can be seen in the figure below.\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\n<a href=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu1.png\"><img class=\"alignnone wp-image-6544 size-full\" src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu1.png\" alt=\"gpu\" width=\"569\" height=\"286\" /></a>\r\n\r\n<a href=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu2.png\"><img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu2-300x150.png\" alt=\"gpu\" width=\"300\" height=\"150\" class=\"alignnone size-medium wp-image-6608\" /></a>\r\n\r\n&nbsp;','Triangle Counting in Graphs on the GPU (Part 1)','','inherit','open','open','','6539-revision-v1','','','2014-09-11 18:18:10','2014-09-11 18:18:10','',6539,'http://sandbox.arrayfire.com/6539-revision-v1/',0,'revision','',0),(6610,17796,'2014-09-11 18:18:58','2014-09-11 18:18:58','Triangle counting is a building block for many social analytics, especially for the widely used clustering coefficient analytic. Clustering coefficients is used for finding key players in a network based on their local connectivity, which is expressed based on the number of triangles that they belong to. There are many ways for finding the triangles a vertex may belong to. One of the most popular approaches for finding the triangles is to do an intersection of two adjacency lists. If a pair of vertices <em>(u,v) </em>have any common neighbors, these will be found in the intersection process.\r\n\r\nWhile the above may sound simple, implementing an efficient intersection on the GPU is not trivial or straightforward, it requires smart partitioning of the work to make full use of the thousands of available threads that modern GPUs have. We just finished such an implementation that has multiple levels of parallelism which partitions the work to the multiprocessors and to the SIMT units.\r\n\r\nFor testing purposes, we used graphs taken from the <a href=\"http://www.cc.gatech.edu/dimacs10/\">DIMACS 10 Graph Challenge</a>. Our experiments were conducted on NVIDIA\'s K40 GPU. Our GPU triangle counting implementation achieves speedups in the range of <strong>9X-32X</strong> over a CPU sequential implementation. These can be seen in the figure below.\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\n<a href=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu2.png\"><img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/gpu2.png\" alt=\"gpu\" width=\"569\" height=\"286\" class=\"alignnone size-full wp-image-6608\" /></a>\r\n\r\n&nbsp;','Triangle Counting in Graphs on the GPU (Part 1)','','inherit','open','open','','6539-revision-v1','','','2014-09-11 18:18:58','2014-09-11 18:18:58','',6539,'http://sandbox.arrayfire.com/6539-revision-v1/',0,'revision','',0),(6613,7,'2014-09-17 18:27:14','2014-09-17 18:27:14','[content_band inner_container=\"true\" no_margin=\"true\" border=\"none\" padding_top=\"40px\" padding_bottom=\"40px\"][column type=\"two-fifths\"]\r\n\r\n[custom_headline type=\"left\" level=\"h3\"]If you want faster code, you\'ve come to the right place.[/custom_headline][gap size=\"15%\"][button  type=\"flat\" shape=\"rounded\" href=\"http://sandbox.arrayfire.com/download\" size=\"x-large\" block=\"true\"]Download ArrayFire[/button]\r\n\r\n[gap size=\"10%\"]\r\n\r\n[button  type=\"flat\" block=\"true\" shape=\"rounded\" href=\"http://www.meetme.so/arrayfire\" size=\"x-large\" ]Schedule a consultation[/button]\r\n\r\n[/column][column type=\"three-fifths\" last=\"true\"][gap size=\"7%\"]\r\n<div id=\"wistia_rj2bar3xxp\" class=\"wistia_embed\" style=\"width: 640px; height: 388px;\"></div>\r\n<script src=\"//fast.wistia.com/assets/external/E-v1.js\" charset=\"ISO-8859-1\"></script><script>// <![CDATA[\r\nwistiaEmbed = Wistia.embed(\"rj2bar3xxp\");\r\n// ]]></script>\r\n[/column]\r\n<div id=\"arrayfire\"></div>\r\n[/content_band]\r\n\r\n[content_band bg_color=\"#f2f2f2\" inner_container=\"true\" no_margin=\"true\" border=\"none\" padding_top=\"40px\" padding_bottom=\"40px\"]\r\n\r\n[column type=\"one-third\" ][custom_headline type=\"left\" level=\"h3\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/car-e1412967813807.png\" class=\"mbn\"] Faster Code[/custom_headline][line style=\"border-top: solid #999999;\"]ArrayFire is a blazing fast software library for GPU computing. Its easy-to-use API and array-based function set make GPU programming simple. A few lines of code in ArrayFire can replace dozens of lines of raw GPU code, saving you valuable time and lowering development costs.\r\n<p style=\"text-align: center;\">[button type=\"flat\" shape=\"rounded\" size=\"regular\" href=\"http://www.sandbox.arrayfire.com/docs/examples.htm\"]See some examples[/button][/column]</p>\r\n[column type=\"one-third\" ][custom_headline type=\"left\" level=\"h3\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/mini-motorcycle-01-e1412969290876.png\" class=\"mbn\"] Hardware Neutral[/custom_headline][line style=\"border-top: solid #999999;\"]ArrayFire supports both CUDA-capable NVIDIA GPUs and most OpenCL devices, including AMD GPUs/APUs and Intel Xeon Phi co-processors. It also supports mobile OpenCL devices from ARM, Qualcomm, and others. We want your code to run as fast as possible, regardless of the hardware.\r\n<p style=\"text-align: center;\">[button type=\"flat\" shape=\"rounded\" size=\"regular\" href=\"http://www.sandbox.arrayfire.com/download\"]Download ArrayFire[/button][/column]</p>\r\n[column type=\"one-third\" last=\"true\" ][custom_headline type=\"left\" level=\"h3\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/09/mini-plane-01-e1412969527633.png\" class=\"mbn\"] Open Source[/custom_headline][line style=\"border-top: solid #999999;\"]ArrayFire is open source—it\'s all there and it\'s all free. Be sure to check out all of the ArrayFire functions (and a lot more!) in our excellent <a href=\"http://www.sandbox.arrayfire.com/docs/index.htm\">documentation</a>. And don\'t forget to visit our <a href=\"http://sandbox.arrayfire.com/forums/\">forums</a> to connect with the ArrayFire community and pick up acceleration tips and innovative best practices.\r\n<p style=\"text-align: center;\">[button type=\"flat\" shape=\"rounded\" size=\"regular\" href=\"http://www.sandbox.arrayfire.com/docs/index.htm\"]View the documentation[/button][/column][gap size=\"3%\"][/content_band]</p>\r\n\r\n<div>\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"none\" padding_top=\"40px\" padding_bottom=\"40px\"][gap size=5%]\r\n\r\n[rev_slider customers]\r\n<h3 style=\"text-align: center;\">Join the ArrayFire community</h3>\r\n<p style=\"text-align: center;\">[button  type=\"flat\" shape=\"rounded\" href=\"http://sandbox.arrayfire.com/download\" size=\"normal\" ]                    Get started                    [/button]</p>\r\n[/content_band]\r\n\r\n</div>','Home OPSC','','publish','open','closed','wisc0nsin','home-opsc','','','2014-11-25 20:16:27','2014-11-25 20:16:27','',0,'http://sandbox.arrayfire.com/?page_id=6613',0,'page','',0),(6614,7,'2014-09-15 20:16:48','2014-09-15 20:16:48','','Home OPSC','','inherit','open','open','','6613-revision-v1','','','2014-09-15 20:16:48','2014-09-15 20:16:48','',6613,'http://sandbox.arrayfire.com/6613-revision-v1/',0,'revision','',0),(6615,7,'2014-09-15 20:17:34','2014-09-15 20:17:34','[content_band inner_container=\"true\" no_margin=\"true\" border=\"none\" padding_top=\"40px\" padding_bottom=\"40px\"][column type=\"two-fifths\"]\r\n\r\n[custom_headline type=\"left\" level=\"h3\"]If you want faster code, you\'ve come to the right place.[/custom_headline][gap size=\"15%\"][button  type=\"flat\" shape=\"rounded\" href=\"http://sandbox.arrayfire.com/download\" size=\"x-large\" block=\"true\"]Download ArrayFire[/button]\r\n\r\n[gap size=\"10%\"]\r\n\r\n[button  type=\"flat\" block=\"true\" shape=\"rounded\" href=\"http://www.meetme.so/arrayfire\" size=\"x-large\" ]Schedule a consultation[/button]\r\n\r\n[/column][column type=\"three-fifths\" last=\"true\"][gap size=\"7%\"]\r\n<div id=\"wistia_rj2bar3xxp\" class=\"wistia_embed\"></div>\r\n[/column]\r\n<div id=\"arrayfire\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"][column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\"]Faster code[/custom_headline]\r\n\r\nArrayFire is a fast, hardware-neutral software library for GPU computing with an easy-to-use API. Its array-based function set makes GPU programming simple. A few lines of code in ArrayFire can replace dozens of lines of raw GPU code, saving you valuable time and lowering development costs.\r\n\r\n[gap size=\"10%\"][button  type=\"flat\" shape=\"rounded\" href=\"http://sandbox.arrayfire.com/download\" size=\"x-large\" ]Download ArrayFire[/button][/column][column type=\"one-half\" last=\"true\" class=\"center-text\"][gap size=\"5%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/Triumvirate_Exported.png\"][/column] [gap size=\"5%\"]\r\n\r\n[column type=\"one-third\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/Googlelogo-e1396387097279.png\"][line]Video content analysis is the basis for categorizing videos and enabling search by content. Google used ArrayFire to extract motion features in video, improving performance by substantially accelerating the solution of the L1-regularized least-squares optimization problem.[/column][column type=\"one-third\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/Koch-Industries-e1396387359637.jpg\"][line]Andrew Shin, Market Risk Manager of Koch Supply &amp; Trading, achieves significant performance increases on option pricing algorithms using ArrayFire software, \"My buddy and I are, at best, novice programmers and we couldn\'t imagine having to figure out how to code all this in CUDA.\"[/column][column type=\"one-third\" last=\"true\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/nasa-e1396387230473.png\"][line]The main thrust of this research was improving Mars rover image compression via GPUs and genetic algorithms. With ArrayFire software and GPUs, the researchers were able to achieve 5X speedups on the larger data sizes.[/column]\r\n<div id=\"hardware\"></div>\r\n[/content_band]\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"]\r\n\r\n[column type=\"one-half\"][gap size=\"15%\"]\r\n\r\n<img class=\"aligncenter\" src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/CUDA-logo.jpg\" alt=\"CUDA logo\" width=\"231\" height=\"140\" />\r\n\r\n<img class=\"aligncenter\" src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/OpenCLLogo_678x452.png\" alt=\"OpenCL\" width=\"326\" height=\"217\" />\r\n\r\n[/column][column type=\"one-half\" last=\"true\"][gap size=\"10%\"]\r\n\r\n[custom_headline type=\"left\" level=\"h3\"] ArrayFire for CUDA and OpenCL[/custom_headline]\r\n\r\nArrayFire supports CUDA-capable NVIDIA GPUs and most OpenCL devices, including AMD GPUs/APUs and Intel Xeon Phi co-processors. It also supports mobile OpenCL devices from ARM, Qualcomm, and others.\r\n\r\nArrayFire is a high-performance software library designed for maximum productivity and speed without the hassle of writing difficult low-level device code. Each of ArrayFire\'s functions has been hand-tuned by our CUDA and OpenCL experts.\r\n\r\n[/column]\r\n<div id=\"mobile\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"]\r\n[column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\"  ]Mobile GPU Computing[/custom_headline]\r\n\r\nMobile GPUs offer accelerated performance. If you would like to use ArrayFire in a mobile application or if you would like to hire our mobile acceleration services, email us at <a href=\"mailto:sales@arrayfire.com\" target=\"_blank\">sales@arrayfire.com</a> and include a description of your application.\r\n\r\nOur clients have achieved between 5X to 30X speed boosts for convolutions and other compute functions on mobile devices. It enables:[icon_list][icon_list_item type=\"angle-double-right\"]Real-time video processing[/icon_list_item][icon_list_item type=\"angle-double-right\"]Better augmented reality [/icon_list_item][icon_list_item type=\"angle-double-right\"]Better computational photograph[/icon_list_item][icon_list_item type=\"angle-double-right\"]Faster data processing[/icon_list_item][/icon_list]\r\n\r\nAll mobile devices have a GPU which can deliver greater compute throughput than the CPU. Why not use the GPU to make your app faster?[/column][column type=\"one-half\" fade=\"true\" last=\"true\" fade_animation=\"in-from-right\" class=\"center-text\"][gap size=\"10%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/mobile_Exported1-e1395437261846.png\"][/column]\r\n<div id=\"documentation\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"][column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\"]Documentation[/custom_headline]\r\n<h5>ArrayFire for C, C++, and Fortran</h5>\r\nOpen the hood—take a look at the beautiful nitty-gritty.\r\n\r\n[icon type=\"angle-double-right\"] <a href=\"http://www.sandbox.arrayfire.com/docs/installation.htm\" target=\"_blank\">CUDA &amp; OpenCL C/C++</a>\r\n<h5>Functions</h5>\r\nHundreds of functions, hand-tuned and optimized by our engineers.\r\n\r\n[icon type=\"angle-double-right\"] <a title=\"ArrayFire Functions\" href=\"http://www.sandbox.arrayfire.com/docs/modules.htm\">ArrayFire Functions</a>\r\n<h5>User Forums</h5>\r\nEvery post gets a response from ArrayFire engineers.\r\n\r\n[icon type=\"angle-double-right\"] <a href=\"http://forums.accelereyes.com/\" target=\"_blank\">User Forums</a>\r\n\r\n[/column][column class=\"center-text\" type=\"one-half\" last=\"true\" fade=\"true\" fade_animation=\"in-from-right\" ][gap size=\"5%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/gears1.png\"][/column]\r\n<div id=\"benchmarks\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"]\r\n[column type=\"one-half\" fade=\"true\" fade_animation=\"in-from-left\" ][gap size=\"5%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/Benchmark-guy-torso-opposite-e1392155948298.png\"][/column]\r\n\r\n[column type=\"one-half\" last=\"true\"][custom_headline type=\"left\" level=\"h3\" ]Benchmarks[/custom_headline]\r\n\r\nAll benchmarks were performed on a NVIDIA Tesla C2050 with an Intel i7-950 processor. The benchmarks compare ArrayFire with several popular CPU-based acceleration libraries, including <a href=\"http://software.intel.com/en-us/articles/intel-mkl/\" target=\"_new\">Intel Math Kernel Library</a>, <a href=\"http://software.intel.com/en-us/articles/intel-ipp/\" target=\"_new\">Intel Integrated Performance Primitives</a>, <a href=\"http://eigen.tuxfamily.org/index.php?title=Main_Page\" target=\"_new\">Eigen</a>, and <a href=\"http://arma.sourceforge.net/\" target=\"_new\">Armadillo</a>.[/column]\r\n\r\n[column type=\"one-fifth\"].[/column][column type=\"three-fifths\"][tab_nav type=\"four-up\"][tab_nav_item title=\"Base\" active=\"true\"][tab_nav_item title=\"Linear Algebra\" active=\"\"][tab_nav_item title=\"Convolution\" active=\"\"][tab_nav_item title=\"Utility\" active=\"\"][/tab_nav][tabs][tab active=\"true\"]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/matrix_multiply-1024x730.png\" alt=\"Matrix Multiply\" width=\"491\" height=\"350\" />[line]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/matrix_transpose-1024x730.png\" alt=\"Matrix Transpose\" width=\"491\" height=\"350\" />[line]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/fft-1024x730.png\" alt=\"FFT\" width=\"491\" height=\"350\" />[/tab][tab]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/lu-1024x730.png\" alt=\"LU\" width=\"491\" height=\"350\" />[line]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/svd-1024x730.png\" alt=\"SVD\" width=\"491\" height=\"350\" />[line]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/solve-1024x730.png\" alt=\"Solve\" width=\"491\" height=\"350\" />[/tab][tab]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/convs-1024x730.png\" alt=\"Convs\" width=\"491\" height=\"350\" />[line]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/conv-1024x730.png\" alt=\"Conv\" width=\"491\" height=\"350\" />[/tab][tab]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/sum-1024x730.png\" alt=\"sum\" width=\"491\" height=\"350\" />[line]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/sort-1024x730.png\" alt=\"sort\" width=\"491\" height=\"350\" />[line]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/scan-1024x730.png\" alt=\"scan\" width=\"491\" height=\"350\" />[/tab][/tabs][/column][column type=\"one-fifth\" last=\"true\"].[/column]\r\n<div id=\"free\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\" ]\r\n\r\n[column type=\"one-half\"].[/column][column type=\"one-fourth\"].[custom_headline type=\"center\"  level=\"h3\" class=\"mtn\"]ArrayFire Free[/custom_headline][/column][column type=\"one-fourth\" last=\"true\"].[/column][column type=\"one-fourth\"  fade=\"true\" fade_animation=\"in-from-left\" ][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/right-leaning-e1391788779101.png\"][/column][column type=\"one-fourth\"]\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td>[custom_headline type=\"center\" level=\"h5\"]Functions[/custom_headline]</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Basic Operations</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Arithmetic</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Signal Processing</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Image Processing</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Statistics</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Visualization</td>\r\n</tr>\r\n</tbody>\r\n</table>\r\n[gap size=\"17%\"][button type=\"flat\" block=\"true\" shape=\"rounded\" size=\"large\"  href=\"http://sandbox.arrayfire.com/download\"]Download ArrayFire[/button] [/column][column type=\"one-fourth\"]\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td>[custom_headline type=\"center\" level=\"h5\"]Hardware[/custom_headline]</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] CUDA</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] OpenCL</td>\r\n</tr>\r\n<tr>\r\n<td>[custom_headline type=\"center\" level=\"h5\"]Languages[/custom_headline]</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] C/C++</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Fortran</td>\r\n</tr>\r\n<tr>\r\n<td>[custom_headline type=\"center\" level=\"h5\"]Advanced[/custom_headline]</td>\r\n</tr>\r\n<tr>\r\n<td> [icon type=\"check-circle\" style=\"color: #8cc540;\"] GFOR Loop</td>\r\n</tr>\r\n</tbody>\r\n</table>\r\n[/column][column type=\"one-fourth\" last=\"true\"]\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td>[custom_headline type=\"center\" level=\"h5\"]Platforms[/custom_headline]</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Windows</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Linux</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Mac</td>\r\n</tr>\r\n<tr>\r\n<td>[custom_headline type=\"center\" level=\"h5\"]Data Types[/custom_headline]</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] All types</td>\r\n</tr>\r\n<tr>\r\n<td>[custom_headline type=\"center\" level=\"h5\"]Support[/custom_headline]</td>\r\n</tr>\r\n<tr>\r\n<td> [icon type=\"check-circle\" style=\"color: #8cc540;\"] Forums</td>\r\n</tr>\r\n</tbody>\r\n</table>\r\n<div id=\"licensing\"></div>\r\n[/column][gap size=\"8%\"]\r\n\r\n[pricing_table id=\"pricing\" columns=\"3\"][pricing_table_column  featured=\"false\" title=\"ArrayFire Developer\" currency=\"$\" price=\"499 / year\" interval=\"$149 / year (Academic)\"] [icon_list] [icon_list_item type=\"star\" ]Dedicated license [/icon_list_item] [icon_list_item  type=\"times-circle\"] Starts at 2 GPUs or devices [/icon_list_item] [icon_list_item type=\"times-circle\"] Linear algebra [/icon_list_item] [icon_list_item type=\"times-circle\"] Sparse matrices [/icon_list_item][icon_list_item type=\"times-circle\"] Phone support [/icon_list_item][icon_list_item type=\"times-circle\"] Premium support &amp; consulting [/icon_list_item][/icon_list] [button href=\" http://sandbox.arrayfire.com/product-category/arrayfire/\"] Purchase [/button] [/pricing_table_column] [pricing_table_column featured=\"true\" featured_sub=\"Most Popular\" title=\"ArrayFire Pro\" currency=\"$\" price=\"1,499 / year\" interval=\"$525 / year (Academic)\"] [icon_list] [icon_list_item type=\"star\"] Dedicated license [/icon_list_item] [icon_list_item type=\"star\"] Starts at 2 GPUs or devices [/icon_list_item] [icon_list_item type=\"star\"] Linear algebra [/icon_list_item][icon_list_item type=\"star\"] Sparse matrices [/icon_list_item][icon_list_item type=\"times-circle\"] Phone support [/icon_list_item][icon_list_item type=\"times-circle\"] Premium support &amp; consulting [/icon_list_item] [/icon_list] [button href=\" http://sandbox.arrayfire.com/product-category/arrayfire/\"]Purchase [/button] [/pricing_table_column] [pricing_table_column featured=\"false\" title=\"ArrayFire Enterprise\" currency=\"$\" price=\"2,999 / year\" interval=\"$1,049 / year (Academic)\"] [icon_list] [icon_list_item type=\"star\"] Dedicated license [/icon_list_item] [icon_list_item type=\"star\"] Starts at 2 GPUs or devices [/icon_list_item] [icon_list_item type=\"star\"] Linear algebra [/icon_list_item][icon_list_item type=\"star\"]Sparse matrices [/icon_list_item][icon_list_item type=\"star\"] Phone support[/icon_list_item][icon_list_item type=\"star\"]Premium support &amp; consulting [/icon_list_item][/icon_list] [button href=\" http://sandbox.arrayfire.com/product-category/arrayfire/\"] Purchase [/button] [/pricing_table_column] [/pricing_table]\r\n<div id=\"whitepapers\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\" ]\r\n\r\n[column type=\"one-half\"][gap size=\"20%\"][image type=\"thumbnail\" src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/wp2.jpg\"][button href=\"http://go.sandbox.arrayfire.com/l/37882/2014-05-29/dw83/37882/18534/arrayfire_matrix_computations_chrzeszczyk.pdf\" shape=\"rounded\" size=\"regular\" block=\"true\"]Download <em>Matrix Computations on the GPU with ArrayFire for C/C++</em>[/button][/column][column type=\"one-half\" last=\"true\"]\r\n\r\n[custom_headline type=\"left\" level=\"h3\" ]Whitepapers[/custom_headline]\r\n\r\n<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/Whitepaper-1.png\" alt=\"Whitepaper 1\" width=\"466\" height=\"374\" />\r\n\r\n&nbsp;\r\n\r\n[/column][gap size=\"10%\"]\r\n\r\n[column type=\"one-half\"]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/Whitepaper-2.png\" alt=\"Whitepaper 2\" width=\"442\" height=\"304\" />[/column][column type=\"one-half\" last=\"true\"][image type=\"thumbnail\" src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/wp1.jpg\"][button href=\"http://go.sandbox.arrayfire.com/l/37882/2014-05-29/dw81/37882/18532/arrayfire_whitepaper.pdf\" shape=\"rounded\" size=\"regular\"  block=\"true\" float=\"right\"]Download <em>High-level GPU Computing in C, C++, and Fortran</em>[/button][/column]\r\n<div id=\"casestudies\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\" ]\r\n\r\n[column type=\"one-half\"][gap size=\"12%\"][custom_headline type=\"left\" level=\"h3\" ]Case Studies[/custom_headline]\r\n\r\nLearn how ArrayFire has worked in real code, including applications in academia, finance, government, life sciences, manufacturing, media, and oil &amp; gas.[/column][column type=\"one-half\" last=\"true\" fade=\"true\" fade_animation=\"in-from right\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/model-A.png\"][/column][custom_headline type=\"left\" level=\"h5\"]Academia [/custom_headline][accordion][accordion_item title=\"Accelerating LTE Simulation | Tsinghua University\"]\r\n\r\nAuthors: Yuan Gao, Yin Sun, Chun Hui Zhou, Xin Su, Xi Bin Xu, Shi Dong Zhou, Tsinghua University\r\nSpeedup: 3X\r\n\r\nFast simulations are a driving force in several research projects. However, the accompanying long simulation times can tend to be a drag in many of these projects. In this article, we shall bring up the example of the work on 3GPP LTE System Simulation by Yuan Gao et al (from Tsinghua University, Beijing) and demonstrate how the use of ArrayFire software can significantly improve the simulator performance and lead to faster validation times in simulation projects.[/accordion_item]\r\n\r\n[accordion_item title=\"High Performance Compressive Sensing | Rice University\"]\r\n\r\nAuthors: Nabor Reyna and Wotao Yin from Rice University\r\nSpeedup: 5X\r\n\r\nThis work deals with reconstruction of signals using partial Fourier matrices (RecPF). The major computational components of the algorithm involve shrinkage and FFTs. ArrayFire software is employed to accelerate this compute-heavy code.[/accordion_item]\r\n\r\n[accordion_item title=\"Power System Simulations | Indian Institute of Technology, Roorkee, India\"]\r\nAuthors: Indian Institute of Technology, Roorkee\r\nSpeedup: 35X\r\n\r\nPower flow studies are one of the most important aspects of power system planning and operation. The power flow reveals the sinusoidal steady state characteristics of the entire system - voltages, real and reactive power generated, and absorbed and line losses- elucidating the voltage magnitudes and angles at each bus, the generation of each generating unit, and real and reactive power losses in the system. All this is necessary to ensure the security, economy, and control of electrical energy distribution. Learn how ArrayFire software can deliver magnitudes of performance improvement over CPU-based solutions.[/accordion_item]\r\n\r\n[accordion_item title=\"Antenna Array Simulations | University of Naples Federico II\"]\r\n\r\nAuthors: A. Capozzoli, C. Cucio, A. Liseno at University of Naples Federico II\r\nSpeedup: 24X\r\n\r\nAntenna array design involves repeated simulation to tune the many parameters involved, and waiting around for simulations to finish is no fun. Offloading the optimization problem onto the GPU cuts that time down significantly. In their recent paper, Capozzoli, Curcio, and Liseno of University of Naples Federico II demonstrated how a simple modification to their echo generator array simulation took advantage of the GPU to bring immediate speedups.[/accordion_item]\r\n\r\n[accordion_item title=\"Laplace Transform Inversion | Acunum Algorithms and Simulations\"]\r\n\r\nAuthors: Patrick Kano and Moysey Brio at Acunum Algorithms and Simulations\r\nSpeedup: 3.8X\r\n\r\nThe numerical inversion of the Laplace transform is a long standing problem due its implicit ill-posedness. Patrick Kano and Moysey Brio of Acunum Algorithms and Simulations, with their experience in computational methods and algorithm development, found a solution that not only works, but is very fast.[/accordion_item]\r\n\r\n[accordion_item title=\"Compressed Sensing for Image Reconstruction | College of Engineering, Roorkee, India\"]\r\n\r\nAuthors: Kuldeep Yadav, Ankush Mittal, M. A. Ansar, and Avi Srivastava, College of Engineering, Roorkee, India\r\nSpeedup: 8X\r\n\r\nCompressed sensing is very critical in the areas of medical image reconstruction, image acquisition or sensor networks. An algorithm for compressed sensing developed using a Basis Pursuit Algorithm shows over 8X speedup when run on an NVIDIA GPU.[/accordion_item]\r\n\r\n[accordion_item title=\"Fat/Water Reconstruction for Medical Images | Case Western Reserve University\"]\r\n\r\nAuthors: D. H. Johnson, S. Narayan, C. A. Flask, and D. L. Wilson, Case Western Reserve University\r\nSpeedup: 11.6X\r\n\r\nCase Western Reserve University researchers turned to GPUs running ArrayFire software to develop a fast and robust version of the \"Iterative Decomposition of water and fat with an Echo Asymmetry and Least-squares\" (IDEAL) reconstruction algorithm. This algorithm uses a lot of Image Processing algorithms for reconstruction, and was shown to achieve very high speedups.\r\n[/accordion_item]\r\n\r\n[/accordion]\r\n<h5>Finance</h5>\r\n[accordion][accordion_item title=\"Option Pricing | Koch Supply and Trading\"]\r\n\r\nAuthors: Koch Supply &amp; Trading\r\nSpeedup: 51.8X\r\n\r\nAndrew Shin, Market Risk Manager of Koch Supply &amp; Trading, achieves significant performance increases on option pricing algorithms using ArrayFire software to accelerate his code with GPUs. Andrew says, \"My buddy and I are, at best, novice programmers and we couldn\'t imagine having to figure out how to code all this in CUDA.\" But he found ArrayFire software to be straight-forward. With these results, he says he can see ArrayFire software and GPUs populating Koch\'s mark-to-futures cube, which contains its assets, simulations, and simulated asset prices.[/accordion_item]\r\n\r\n[accordion_item title=\"GPU Computing in Automated Trader | Automated Trader\"]\r\n\r\nAuthors: Automated Trader\r\nSpeedup: 37.5X\r\n\r\nThe Q1 2012 issue of Automated Trader contains an excellent Mashup piece reviewing software for algorithmic trading. The article provides a wonderful glimpse into the 1-2 month adventure of Andy Webb, Automated Trader.s Founder, and Wrecking Crew building a fast trading platform from several technologies. The full trading platform they built was quite extensive. The part that caught our eye was the core computational component of the pipeline. That component involved permuting 1,000 potential pairs with cointegration tests for 350 time windows on each potential pair.\r\n[/accordion_item]\r\n[accordion_item title=\"GPUs in Quantitative Analytics and Finance | Private Bank\"]\r\n\r\nThe world of Quantitative finance is all about getting accurate results really, really fast. ArrayFire is working with one of the largest banks in Spain to maximize their output using GPUs. Click the link below for an overview of the uses of GPU computing in finance.[/accordion_item][/accordion]\r\n<h5>Government</h5>\r\n[accordion][accordion_item title=\"Powering Mars Research | NASA and UAA in Anchorage\" ]\r\n\r\nAuthors: NASA and UAA in Anchorage\r\nSpeedup: 5X\r\n\r\nThe main thrust of this research is improving mars rover image compression via GPUs and genetic algorithms. With ArrayFire software and GPUs, the researchers were able to achieve 5X speedups on the larger data sizes. The algorithm works by pairing neighboring pixels with a random one and then adjusting the random pixel based on whether it incrementally improves the original image. Babb described the algorithm as an embarrassingly parallel process, ideally suited to GPU acceleration. He estimates he has been able to achieve a 20 to 30 percent error reduction in subjects like fingerprints and satellite imagery.[/accordion_item]\r\n\r\n[accordion_item title=\"Radar Image Formation | System Planning Corporation\"]\r\n\r\nAuthors: Gary Rubin and Earl Sager - System Planning Corporation\r\nSpeedup: ~45X\r\n\r\nRadar imaging is computationally intensive. As a result, many imaging algorithms apply FFT-based approximations. While efficient, these algorithms sacrifice data fidelity for speed. Other algorithms better preserve information, but are often too slow for many applications. At System Planning Corporation (SPC) , we have implemented a SAR/ISAR imaging routine based on the Backprojection algorithm. Using ArrayFire software, we have demonstrated speedups of roughly 45x for large datasets.[/accordion_item]\r\n\r\n[accordion_item title=\"Radar Clutter Reduction | System Planning Corporation\"]\r\n\r\nAuthors: David Berger and Gary Rubin - System Planning Corporation\r\nSpeedup: 5-10X\r\n\r\nSystem Planning Corporation (SPC) uses ArrayFire software to accelerate radar processing algorithms. The system processes raw data from marine navigation radars using a variety of thresholding techniques to extract real targets from clutter. This involves highly data-parallel processing in which each radar pulse is subjected to the same computations; very few operations occur across multiple pulses. Using ArrayFire software, SPC has achieved 10x speed improvements relative to a Core i7-920 CPU and 5x improvements relative to a realtime DSP implementation.[/accordion_item]\r\n\r\n[accordion_item title=\"Novel Algorithms for Linear Algebra | SAIC\" ]\r\n\r\nAuthors: Nolan Davis and Daniel Redig, SAIC\r\nSpeedup: 3.5X\r\n\r\nNolan Davis and Daniel Redig at SAIC recently presented work on Hybrid GPU/Multicore Solutions for Large Linear Algebra Problems where they developed a novel algorithm for LU decomposition, one of the most important routines in linear algebra. They presented a Hybrid CPU/GPU computing approach, where problems too large to fit in GPU memory can also be solved faster than using only the CPU.\r\n[/accordion_item]\r\n[accordion_item title=\"Geolocation | BAE Systems\"]\r\n\r\nAuthors: BAE Systems\r\nSpeedup: 17X\r\n\r\nGeolocation is the identification of the real-world geographic location of a target of interest. In this application, the system receives the signal with an array of several antennas and computes the direction of arrival of the radio energy by measuring the time difference of arrival (or the phase difference) at the different antennas.\r\n[/accordion_item]\r\n[accordion_item title=\"Tsunami Modeling | University of Minnesota, Boise State, Saint Scholastica, and NCAR\"]\r\n\r\nAuthors: University of Minnesota, Boise State, Saint Scholastica, and NCAR\r\nSpeedup: 3-5X\r\n\r\nNatural catastrophic disasters like tsunamis commonly strike with little warning. For most people, tsunamis are underrated as major hazards. People sometimes wrongly believe that they occur infrequently and only along distant coasts. Tsunamis are usually caused by earthquakes. Seismic signals can give some margin of warning since the speed of tsunami waves travels at 1/30 the speed of seismic waves. Still there is little time between the creation of the tsunami and its impact making fast processing critical to producing effective warning systems. ArrayFire software was used to run an RBF simulation on the GPU with a time to solution not available by other alternatives.\r\n[/accordion_item][/accordion]\r\n<h5>Life Sciences</h5>\r\n[accordion][accordion_item title=\"Parallelized Gene Predictors | University of Quebec\" ]\r\n\r\nAuthors: University of Quebec\r\nSpeedup: 43X\r\n\r\nComputerized approaches to studying the human genome are challenged by the exploding amount of data, which doubles roughly every 6 months. In order to deal with this burgeoning datasets, demands for faster processing power continue to arise. This work focuses on predicting genes using frequency analysis with FFTs and with an equivalent technique known as Goertzel\'s algorithm. In these applications, the emphasis of this paper is to propose tools to geneticists and molecular biologists for the prediction or identification of new genes using existing complementary strategies. The criteria for these tools are speed, reliability, accuracy and ease of use, thus requiring little training.\r\n[/accordion_item]\r\n[accordion_item title=\"Pathology Advances with GPUs | Northeastern University\" ]\r\n\r\nAuthors: Laboratory for Spectral Diagnosis at Northeastern University\r\nSpeedup: 100X+\r\n\r\nOne element of the hyperspectral image analysis workflow that requires more than a traditional desktop workstation or personal computer is Hierarchical Cluster analysis (HCA). HCA requires a large amount of data space and substantial computation time (~11 hours) for typical datasets using a single processor personal computer. Rather than following the traditional approach of moving to a lower level programming language like C or C++ and complex parallel programming paradigms such as OpenMP or the Massage Passing Interface (MPI), the lab utilized graphics processing units, or GPUs, and the ArrayFire software platform. The solution allowed the lab to dramatically increase the performance of the analysis while substantially decreasing the amount of calendar time to reach the desired results.\r\n[/accordion_item]\r\n[accordion_item title=\"Hepatitis C Virus - Mutation Modeling | Centers for Disease Control and Prevention\" ]\r\n\r\nAuthors: CDC Research and Development Team\r\nSpeedup: ~20X\r\n\r\nThis case study provides a look at biological research regarding coordinated mutations of the Hepatitis C Virus (HCV). ArrayFire provided collaborative R&amp;D resources and greatly improved the speed of this HCV research with the use of parallelization, reducing the computing time from 40 days to less than 1 day. Most importantly, the conclusion of the case study illustrates the the relative price-performance of personal supercomputers that leverage GPUs and ArrayFire software provides a compelling solution versus other architectures and approaches.\r\n[/accordion_item]\r\n[accordion_item title=\"Accelerating the SPM Package for Neuroimaging | Georgia Institute of Technology\" ]\r\n\r\nAuthors: Georgia Institute of Technology\r\nSpeedup: 3.5X\r\n\r\nThe Georgia Tech team explores the value of ArrayFire software and GPUs for fMRI workflows within the popular SPM - Statistical Parametric Mapping software widely used in neuroscience research.\r\n[/accordion_item]\r\n[accordion_item title=\"Medical Image Compression | Indian Institute of Technology, Roorkee, India\" ]\r\n\r\nAuthors: Jaideep Singh, Ipseeta Aruni, R. Balasubramanian - IIT - Roorkee, India\r\nSpeedup: 38X\r\n\r\nThis study presents the acceleration of Haar wavelet-based image compression algorithm for medical imaging on the Graphics Processing Unit (GPU) using ArrayFire software. Due to bandwidth and image size constraints of medical imaging systems, image compression plays a vital role in reducing the bit rate of transmission or storage. Wavelet-based image compression provides the most promising approach for high quality image compression.\r\n[/accordion_item]\r\n[accordion_item title=\"Brain Displacement | Spencer Technologies\"]\r\n\r\nAuthors: Spencer Technologies\r\nSpeedup: 12X\r\n\r\nSpencer describes how ArrayFire software facilitates the development of fast algorithms enabling observation of brain displacement across depth with sampling density that far surpasses previous benchmarks.\r\n[/accordion_item]\r\n[accordion_item title=\"Multidimensional Scaling for Genomics | Leibniz Institute of Plant Genetics and Crop Plant Research\" ]\r\n\r\nAuthors: Leibniz Institute of Plant Genetics and Crop Plant Research\r\nSpeedup: 20-35X\r\n\r\nMultidimensional scaling (MDS) is a general computing technique to turn a distance matrix into a set of reconstructed points with pair-wise relationships approximating the original distances by points located in a usually low-dimensional space. ArrayFire software is used to enhance execution of the HiT-MDS procedure and delivers considerable performance improvement.\r\n[/accordion_item]\r\n[accordion_item title=\"Drug Delivery Model | Georgia Institute of Technology\"]\r\n\r\nAuthors: Georgia Institute of Technology\r\nSpeedup: 70X\r\n\r\nIn this work, the researchers simulate the delivery of a novel nanoparticle chemotherapy drug to cancerous tissue. Simulation allows scientists to predict experimental outcomes and thus reduce the cost of development and time to clinical relevance. The simulation model includes blood vessels, tumor cells, and healthy cells and an engine to calculate the spatial distributions of both drug and oxygen. ArrayFire software is used to speed up the diffusion calculations for the drug and oxygen within the tissue.\r\n[/accordion_item]\r\n[accordion_item title=\"Biomedical Infrared Spectroscopy | University of Manchester and Nofima Mat, Norway\" ]\r\n\r\nAuthors: University of Manchester and Nofima Mat, Norway\r\nSpeedup: Hours of runtime reduction\r\n\r\nThe authors present an iterative algorithm that applies full Mie scattering theory and avoids noise accumulation in their iterative algorithm by integrating a curve-fitting step. ArrayFire software along with NVIDIA GPUs are leveraged to reduce the time added by the curve-fitting step.\r\n[/accordion_item][/accordion]\r\n<h5>Manufacturing</h5>\r\n[accordion][accordion_item title=\"Feature Learning on Images | Stanford\" ]\r\n\r\nAuthors: Andrew Ng, Stanford University\r\nSpeedup: Ability to process many images in parallel\r\n\r\nStanford researchers in Andrew Ng\'s group used GPUs and ArrayFire software to speed up their work on Feature Learning Architectures. They decided to use ArrayFire software for this study because of the need to quickly evaluate many architectures on thousands of images. ArrayFire software taps into the immense computing power of GPUs and speeds up research utilizing many images.\r\n[/accordion_item]\r\n[accordion_item title=\"Tomography of Vegetation - Filtered Back-Projection and Non-Uniform FFTs | Universita di Napoli Federico II\" ]\r\n\r\nAuthors: Drs. Capozzoli, Curcio, di Vico, and Liseno, Universita di Napoli Federico II\r\nSpeedup: 10X\r\n\r\nIn order to investigate changes of forest biomass, scientists use microwave tomography to image the vegetation. At the smallest scale, individual plants can be imaged to investigate branching and growth, but even synthetic aperture radar can reveal large-scale changes in regional ecology. To the right, you can see the experimental setup to image an individual plant.\r\n[/accordion_item]\r\n[accordion_item title=\"Action Recognition with Independent Subspace Analysis | Stanford University\" ]\r\n\r\nAuthors: Quoc Le, Will Zou, Serena Yeung, Andrew Ng, Stanford University\r\nSpeedup: 4.4X\r\n\r\nIn a paper at this year\'s CVPR 2011, entitled \"Learning hierarchical invariant spatio-temporal features for action recognition with independent subspace analysis\", the authors explain how their unsupervised feature learning algorithm competes with other algorithms that are hand crafted or use learned features. For their training purposes, they used a multi-layered stacked convolutional ISA (Independent subspace analysis) network. An ISA is used for learning features from image patches without supervision.\r\n[/accordion_item][/accordion]\r\n<h5>Media and Computer Vision</h5>\r\n[accordion][accordion_item title=\"Fast Computer Vision with OpenCV and ArrayFire | OpenCV Blogger\" ]\r\n\r\nAuthors: OpenCV Blogger\r\nSpeedup: ~10X\r\n\r\nThe OpenCV library is the defacto standard for doing computer vision and image processing research projects. OpenCV includes several hundreds of computer vision algorithms, aimed for use in realtime vision applications. This case study shows how to use both libraries together. There is a simple example application that demonstrates using OpenCV for webcam access and ArrayFire for some basic processing routines and displaying results.\r\n[/accordion_item]\r\n[accordion_item title=\"Video Processing | Google\" ]\r\n\r\nAuthors: Google and Stanford\r\nSpeedup: 10-20X\r\n\r\nVideo content analysis is the basis for categorizing videos and enabling search by content. Growing interest in using sparse-coding methods to extract motion features in video in support of video content analysis led to the application of ArrayFire software to improve performance by substantially accelerating the solution of the L1-regularized least-squares optimization problem.\r\n[/accordion_item]\r\n[accordion_item title=\"Action Recognition with Independent Subspace Analysis | Stanford University\"]\r\n\r\nAuthors: Quoc Le, Will Zou, Serena Yeung, Andrew Ng, Stanford University\r\nSpeedup: 4.4X\r\n\r\nIn a paper at this year\'s CVPR 2011, entitled \"Learning hierarchical invariant spatio-temporal features for action recognition with independent subspace analysis\", the authors explain how their unsupervised feature learning algorithm competes with other algorithms that are hand crafted or use learned features. For their training purposes, they used a multi-layered stacked convolutional ISA (Independent subspace analysis) network. An ISA is used for learning features from image patches without supervision.\r\n[/accordion_item]\r\n[accordion_item title=\"Music Beat Analysis | Georgia Tech\"]\r\n\r\nAuthors: Vidhur Vohra - Georgia Tech\r\nSpeedup: 15X\r\n\r\nDid you ever wonder how the music visualizer in your media player works? Watching it pulsate in synchrony with the beats of the song is almost as entertaining as listening to the song itself! Researchers have been attempting to detect beats in audio signals for many years, and there are many techniques available, from the simplest (and least accurate) to more complicated algorithms that are highly accurate. All algorithms, though, perform some form of signal processing and frequency analysis, applications highly suited to GPU Computing.\r\n[/accordion_item]\r\n[accordion_item title=\"Optimization Methods for Deep Learning | Stanford Artificial Intelligence Laboratory\" ]\r\n\r\nAuthors: Stanford Artificial Intelligence Laboratory\r\nSpeedup: Improved accuracy\r\n\r\nResearchers at SAIL (Stanford Artificial Intelligence Laboratory), have done it again. They have successfully used ArrayFire software to speed up the training part of Deep Learning algorithms. In their paper titled .On Optimization Methods for Deep Learning., they experiment with some of the well known training algorithms and demostrate their scalability across parallel architectures (GPUs as well as multi-machine networks). The algorithms include SGDs (Stochastic Gradient Descent) L-BFGS (Limited BFGS used for solving non-linear problems), CG (Conjugate Gradient).\r\n[/accordion_item]\r\n[accordion_item title=\"Feature Learning on Images | Stanford University\" ]\r\n\r\nAuthors: Andrew Ng, Stanford University\r\nSpeedup: Ability to process many images in parallel\r\n\r\nStanford researchers in Andrew Ng’s group used ArrayFire software to speed up their work on Feature Learning Architectures. They decided to use ArrayFire software for this study because of the need to quickly evaluate many architectures on thousands of images. ArrayFire software taps into the immense computing power of GPUs and speeds up research utilizing many images.\r\n[/accordion_item]\r\n[accordion_item title=\"Digital Holography for Imaging | National University of Ireland, Maynooth\" ]\r\n\r\nAuthors: Nitesh Pandey, Damien Kelly, Bryan Hennelly and Thomas Naughton from the National University of Ireland, Maynooth\r\nSpeedup: 17X\r\n\r\nDigital holography is a powerful imaging technique with many new applications like true 3D display. It allows the capture of both amplitude and phase information of the light reflected off the surface of 3D objects. Researchers at the National University of Ireland, Maynooth are developing techniques based on digital holography for 3D display applications.\r\nReconstruction of large digital holograms can be computationally intensive to generate on CPUs, but GPUs running ArrayFire software offer amazing possibilities.\r\n[/accordion_item][/accordion]\r\n<h5>Oil and Gas</h5>\r\n[accordion][accordion_item title=\"3D Mantle Convection - Geodynamics | Boise State, University of Colorado, University of Minnesota\" ]\r\n\r\nAuthors: Boise State, University of Colorado, University of Minnesota\r\nSpeedup: 2.5-4.5X\r\n\r\nThe authors introduce a GPU implementation of a three-dimensional mantle convection modeling at a high Rayleigh number to the solid earth geophysics community. They outline code development time, compare performance of CPUs versus GPUs, and deliver powerful visualizations.\r\n[/accordion_item]\r\n[accordion_item title=\"Ground Water Simulations | Louisiana State University\" ]\r\n\r\nAuthors: Kevin R. Tubbs and Frank T-C. Tsai at Louisiana State University\r\nSpeedup: &gt;20X\r\n\r\nA lattice Boltzmann method for solving the shallow water equations and the advection-dispersion equation is developed and implemented on graphics processing unit (GPU)-based architectures. The proposed LBM is implemented to an NVIDIA Computing Processor in a single GPU workstation. GPU computing is performed using ArrayFire software. Mass transport with velocity-dependent dispersion in shallow water flow is simulated by combining the MRT-LBM model and the TRT-LBM model. The GPU parallel performance increases as the grid size increases. The results indicate the promise of the GPU-accelerated LBM for modeling mass transport phenomena in shallow water flows.\r\n[/accordion_item]\r\n[accordion_item title=\"Shallow Water Fluid Flow | Louisiana State University\" ]\r\n\r\nAuthors: Louisiana State University\r\nSpeedup: &gt;10X\r\n\r\nA lattice Boltzmann method (LBM) on high performance computing (HPC) environments for three-dimensional shallow water flow fields coupled to mass transport is developed. LBM is an attractive method for solving the multilayered shallow water equations because the extension to multilayer is straight forward with all of the simplicities and advantages of the LBM in mass transport in shallow water flows and the LBM performance on central processing unit (CPU)-based and graphics processing unit (GPU)-based HPC environments.\r\n[/accordion_item][/accordion]\r\n<div id=\"consulting\"></div>\r\n[/content_band]\r\n<div id=\"services\"></div>\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"][column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\"]Hire our acceleration gang[/custom_headline]\r\n\r\nHire us to accelerate your code. Or to train your pros. Or even to write new code for your organization!\r\n\r\nWe’ve already helped thousands of organizations speedup their code. We’ve accelerated algorithms, data sets, and challenging problems of all types in the past, and we’re confident that we can accelerate your code too.\r\n\r\n[gap size=\"10%\"][button  type=\"flat\" shape=\"rounded\" href=\"http://meetme.so/arrayfire\" size=\"x-large\" ]Schedule a consultation[/button][/column][column type=\"one-half\" last=\"true\" class=\"center-text\"][gap size=\"5%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/Bat-signal-e1391790016951.png\"][/column] [gap size=\"7%\"]\r\n\r\n[column type=\"one-third\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/LFG-B-HORZ_202_K-e1396448935778.jpg\"][line]Lincoln Financial Group ported their CPU code (C/C++) to CUDA, and this enabled them to speed up the necessary financial calculations. Their primary objective was to reduce the time taken to run this code. Before porting to CUDA, they required 10-12 hours to run the entire code. After porting to CUDA, they were able to do the same work in about 30 minutes.[/column][column type=\"one-third\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/reveal_logo-e1396449044651.jpg\"][line]Reveal Imaging, an SAIC company, uses ArrayFire in developing threat-detection products for transportation systems—such as cargo and baggage screening in airports—and in securing facilities and public events.[/column][column type=\"one-third\" last=\"true\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/1800contactlogo.png\"][line]The Glasses.com app relies on computer vision to recognize the features of a user’s face. The application then generates an accurate, high-fidelity, three-dimensional model of that face, and virtually places selected frames on the image.[/column]\r\n<div id=\"starterpackage\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"]\r\n\r\n[column type=\"one-half\" last=\"false\" fade=\"true\" fade_animation=\"in-from-left\" ][gap size=\"10%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/comingatyou.png\"][/column][column type=\"one-half\" last=\"true\"] [custom_headline type=\"left\" level=\"h3\"]Starter Package ($500)* [/custom_headline] Hire us for 1-day. We set you up with one engineer dedicated for a full day, as well as support from senior and test engineers throughout the day. Here\'s how it works:\r\n\r\n[icon_list] [icon_list_item type=\"angle-double-right\"]Initial phone call[/icon_list_item] [icon_list_item type=\"angle-double-right\"]You send us your code or algorithm [/icon_list_item] [icon_list_item type=\"angle-double-right\"]We analyze your code for potential GPU benefit[/icon_list_item][icon_list_item type=\"angle-double-right\"]We accelerate as much of the code as is possible within the 1-day effort, applying our extensive GPU software libraries[/icon_list_item][icon_list_item type=\"angle-double-right\"]We produce a final report, along with code[/icon_list_item] [/icon_list] The final report outlines the best approach to follow for full GPU-acceleration of your code.\r\n\r\n&nbsp;\r\n\r\n[button type=\"flat\" shape=\"rounded\" size=\"regular\" href=\"http://sandbox.arrayfire.com/product/consulting-starter-package/\" title=\"Starter Package\"]Buy the Starter Package[/button]\r\n\r\n&nbsp;\r\n\r\n*Limit one (1) per customer.\r\n\r\n[/column]\r\n<div id=\"customcode\"></div>\r\n[/content_band] [content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\" ]\r\n\r\n[column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\" ]Custom Coding Work[/custom_headline]\r\n\r\n[custom_headline type=\"left\" level=\"h6\" ]Why Choose Us?[/custom_headline] [icon_list] [icon_list_item type=\"angle-double-right\"]Deep experience, already servicing thousands of customers[/icon_list_item] [icon_list_item type=\"angle-double-right\"]Quality work, with leading GPU software [/icon_list_item] [icon_list_item type=\"angle-double-right\"]Efficient delivery, with ArrayFire\'s code base we can deliver results fast[/icon_list_item][icon_list_item type=\"angle-double-right\"]Proven, we make customers happy through faster code[/icon_list_item][/icon_list] [custom_headline type=\"left\" level=\"h6\" ]Our Strengths[/custom_headline] [icon_list] [icon_list_item type=\"angle-double-right\"]Excellence in GPU code[/icon_list_item] [icon_list_item type=\"angle-double-right\"]Well-written, efficient C, C++, Fortran, Java, or .NET [/icon_list_item] [icon_list_item type=\"angle-double-right\"]Application porting and integration[/icon_list_item][icon_list_item type=\"angle-double-right\"]Tuning software to peak hardware performance[/icon_list_item][icon_list_item type=\"angle-double-right\"]Scalability of algorithms to handle enterprise-level programs[/icon_list_item] [/icon_list][button type=\"flat\" shape=\"rounded\" size=\"regular\" href=\"http://meetme.so/arrayfire\" title=\"Tech Consultation\"]Schedule a consultation[/button] [/column][column type=\"one-half\"  fade=\"true\" fade_animation=\"in-from-right\" last=\"true\" ][gap size=\"25%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/Holoham.png\"][/column]\r\n<div id=\"training\"></div>\r\n[/content_band] [content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\" ]\r\n\r\n[column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\" ]Training[/custom_headline] Attendees will receive the latest industry knowledge and techniques for GPU computing in CUDA and OpenCL.\r\n\r\nArrayFire offers up to four days of specialized GPU training in CUDA and OpenCL programming. We provide customized on-site training courses for customers that have 3 or more attendees from their organization. We can travel to your location and provide a CUDA or OpenCL training course tailored to meet your application-specific needs. We also offer individual trainings at our Atlanta office. Please <a href=\"mailto:sales@arrayfire.com\">contact us</a> to learn more about our training offerings.\r\n\r\nWe recommend that attendees have a working knowledge of C/C++ in order to gain the most from the training courses. For more information about the content of our training lectures and hands-on practicums, please see the following training course syllabus.\r\n\r\n[/column]\r\n\r\n[column type=\"one-half\" last=\"true\" fade=\"true\" fade_animation=\"in-from-right\" class=\"center-text\"][gap size=\"15%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/Professor-AF_Exported-e1395436350363.png\" ][/column]\r\n\r\n[column type=\"one-half\" class=\"center-text\"] [gap size=\"17%\"]\r\n<div>[button type=\"flat\" shape=\"rounded\" size=\"jumbo\" href=\"mailto:sales@arrayfire.com?Subject=Training%20Inquiry\"] Register for Training[/button]</div>\r\n[/column][column type=\"one-half\" last=\"true\"][custom_headline type=\"left\" level=\"h3\"]Included in Course[/custom_headline]\r\n\r\n[icon_list] [icon_list_item type=\"angle-double-right\"]Instruction by an excellent and interesting expert, with hands-on exercises[/icon_list_item] [icon_list_item type=\"angle-double-right\"]Use of a laptop with CUDA and OpenCL capable GPUs and CPUs [/icon_list_item] [icon_list_item type=\"angle-double-right\"]Choice of Linux or Windows operating system[/icon_list_item][icon_list_item type=\"angle-double-right\"]Printed manual of lecture material[/icon_list_item][icon_list_item type=\"angle-double-right\"]Electronic copy of programming exercises[/icon_list_item][/icon_list]\r\n\r\n[/column]\r\n\r\n<span>[gap size=\"5%\"]</span>\r\n\r\n[custom_headline type=\"left\" level=\"h3\"]Training Course Syllabus[/custom_headline] [column type=\"one-half\"] [custom_headline type=\"left\" level=\"h5\"  accent=\"false\"]Day 1, Introduction[/custom_headline] Lectures:\r\nGPU Computing Overview\r\nThe Programming Model\r\nBasic Dataset Mapping Techniques\r\nLibraries, ArrayFire\r\nProfiling Tools\r\n\r\nPractice:\r\nA Simple Kernel\r\nEquivalent ArrayFire Example\r\nUsing Libraries\r\nMonte Carlo Pi Estimation\r\nTiming and ArrayFire\r\nDebugging Code\r\n\r\n[custom_headline type=\"left\" level=\"h5\" accent=\"false\"]Day 3, Multi-GPU[/custom_headline] Lectures:\r\nMulti-GPU Use Cases\r\nMulti-GPUs: Contexts\r\nExisting Libraries\r\nScaling Across Multiple GPUs\r\n\r\nPractice:\r\nOut of Core Problems: Matrix Multiply\r\nTask Level Parallelism: Optimization\r\nArrayFire Multi-GPU[/column]\r\n\r\n[column type=\"one-half\" last=\"true\"] [custom_headline type=\"left\" level=\"h5\" accent=\"false\"]Day 2, Optimization[/custom_headline] Lectures:\r\nArchitecture: Grids, Blocks, and Threads\r\nMemory Model: Global, Shared, and Constant Memory\r\nAdvanced Mapping Techniques\r\nStreams: Asynchronos Launches and Concurrent Execution\r\nArrayFire: Lazy Evaluation and Code Vectorization\r\n\r\nPractice:\r\nMatrix Transpose\r\nOptimization Using Shared Memory\r\nMedian Filter\r\nOptimization Using Constant Memory\r\nStream Example\r\nArrayFire Example: Nearest Neighbor Algorithm\r\n\r\n[custom_headline type=\"left\" level=\"h5\" accent=\"false\"]Day 4, Algorithm Problems[/custom_headline]\r\n\r\nLectures and Practice:\r\nReductions\r\nScan Algorithms\r\nSort\r\nConvolution\r\nCustomer-Specific Problem [/column][/content_band]','Home OPSC','','inherit','open','open','','6613-revision-v1','','','2014-09-15 20:17:34','2014-09-15 20:17:34','',6613,'http://sandbox.arrayfire.com/6613-revision-v1/',0,'revision','',0),(6616,7,'2014-09-15 20:20:33','2014-09-15 20:20:33','[content_band inner_container=\"true\" no_margin=\"true\" border=\"none\" padding_top=\"40px\" padding_bottom=\"40px\"][column type=\"two-fifths\"]\r\n\r\n[custom_headline type=\"left\" level=\"h3\"]If you want faster code, you\'ve come to the right place.[/custom_headline][gap size=\"15%\"][button  type=\"flat\" shape=\"rounded\" href=\"http://sandbox.arrayfire.com/download\" size=\"x-large\" block=\"true\"]Download ArrayFire[/button]\r\n\r\n[gap size=\"10%\"]\r\n\r\n[button  type=\"flat\" block=\"true\" shape=\"rounded\" href=\"http://www.meetme.so/arrayfire\" size=\"x-large\" ]Schedule a consultation[/button]\r\n\r\n[/column][column type=\"three-fifths\" last=\"true\"][gap size=\"7%\"]\r\n<div id=\"wistia_rj2bar3xxp\" class=\"wistia_embed\"></div>\r\n[/column]\r\n<div id=\"arrayfire\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"][column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\"]Faster code[/custom_headline]\r\n\r\nArrayFire is a fast, hardware-neutral software library for GPU computing with an easy-to-use API. Its array-based function set makes GPU programming simple. A few lines of code in ArrayFire can replace dozens of lines of raw GPU code, saving you valuable time and lowering development costs.\r\n\r\n[gap size=\"10%\"][button  type=\"flat\" shape=\"rounded\" href=\"http://sandbox.arrayfire.com/download\" size=\"x-large\" ]Download ArrayFire[/button][/column][column type=\"one-half\" last=\"true\" class=\"center-text\"][gap size=\"5%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/Triumvirate_Exported.png\"][/column] [gap size=\"5%\"]\r\n\r\n[column type=\"one-third\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/Googlelogo-e1396387097279.png\"][line]Video content analysis is the basis for categorizing videos and enabling search by content. Google used ArrayFire to extract motion features in video, improving performance by substantially accelerating the solution of the L1-regularized least-squares optimization problem.[/column][column type=\"one-third\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/Koch-Industries-e1396387359637.jpg\"][line]Andrew Shin, Market Risk Manager of Koch Supply &amp; Trading, achieves significant performance increases on option pricing algorithms using ArrayFire software, \"My buddy and I are, at best, novice programmers and we couldn\'t imagine having to figure out how to code all this in CUDA.\"[/column][column type=\"one-third\" last=\"true\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/nasa-e1396387230473.png\"][line]The main thrust of this research was improving Mars rover image compression via GPUs and genetic algorithms. With ArrayFire software and GPUs, the researchers were able to achieve 5X speedups on the larger data sizes.[/column]\r\n<div id=\"hardware\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"]\r\n[column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\"  ]Mobile GPU Computing[/custom_headline]\r\n\r\nMobile GPUs offer accelerated performance. If you would like to use ArrayFire in a mobile application or if you would like to hire our mobile acceleration services, email us at <a href=\"mailto:sales@arrayfire.com\" target=\"_blank\">sales@arrayfire.com</a> and include a description of your application.\r\n\r\nOur clients have achieved between 5X to 30X speed boosts for convolutions and other compute functions on mobile devices. It enables:[icon_list][icon_list_item type=\"angle-double-right\"]Real-time video processing[/icon_list_item][icon_list_item type=\"angle-double-right\"]Better augmented reality [/icon_list_item][icon_list_item type=\"angle-double-right\"]Better computational photograph[/icon_list_item][icon_list_item type=\"angle-double-right\"]Faster data processing[/icon_list_item][/icon_list]\r\n\r\nAll mobile devices have a GPU which can deliver greater compute throughput than the CPU. Why not use the GPU to make your app faster?[/column][column type=\"one-half\" fade=\"true\" last=\"true\" fade_animation=\"in-from-right\" class=\"center-text\"][gap size=\"10%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/mobile_Exported1-e1395437261846.png\"][/column]\r\n<div id=\"documentation\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"][column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\"]Documentation[/custom_headline]\r\n<h5>ArrayFire for C, C++, and Fortran</h5>\r\nOpen the hood—take a look at the beautiful nitty-gritty.\r\n\r\n[icon type=\"angle-double-right\"] <a href=\"http://www.sandbox.arrayfire.com/docs/installation.htm\" target=\"_blank\">CUDA &amp; OpenCL C/C++</a>\r\n<h5>Functions</h5>\r\nHundreds of functions, hand-tuned and optimized by our engineers.\r\n\r\n[icon type=\"angle-double-right\"] <a title=\"ArrayFire Functions\" href=\"http://www.sandbox.arrayfire.com/docs/modules.htm\">ArrayFire Functions</a>\r\n<h5>User Forums</h5>\r\nEvery post gets a response from ArrayFire engineers.\r\n\r\n[icon type=\"angle-double-right\"] <a href=\"http://forums.accelereyes.com/\" target=\"_blank\">User Forums</a>\r\n\r\n[/column][column class=\"center-text\" type=\"one-half\" last=\"true\" fade=\"true\" fade_animation=\"in-from-right\" ][gap size=\"5%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/gears1.png\"][/column]\r\n<div id=\"benchmarks\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"]\r\n[column type=\"one-half\" fade=\"true\" fade_animation=\"in-from-left\" ][gap size=\"5%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/Benchmark-guy-torso-opposite-e1392155948298.png\"][/column]\r\n\r\n[column type=\"one-half\" last=\"true\"][custom_headline type=\"left\" level=\"h3\" ]Benchmarks[/custom_headline]\r\n\r\nAll benchmarks were performed on a NVIDIA Tesla C2050 with an Intel i7-950 processor. The benchmarks compare ArrayFire with several popular CPU-based acceleration libraries, including <a href=\"http://software.intel.com/en-us/articles/intel-mkl/\" target=\"_new\">Intel Math Kernel Library</a>, <a href=\"http://software.intel.com/en-us/articles/intel-ipp/\" target=\"_new\">Intel Integrated Performance Primitives</a>, <a href=\"http://eigen.tuxfamily.org/index.php?title=Main_Page\" target=\"_new\">Eigen</a>, and <a href=\"http://arma.sourceforge.net/\" target=\"_new\">Armadillo</a>.[/column]\r\n\r\n[column type=\"one-fifth\"].[/column][column type=\"three-fifths\"][tab_nav type=\"four-up\"][tab_nav_item title=\"Base\" active=\"true\"][tab_nav_item title=\"Linear Algebra\" active=\"\"][tab_nav_item title=\"Convolution\" active=\"\"][tab_nav_item title=\"Utility\" active=\"\"][/tab_nav][tabs][tab active=\"true\"]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/matrix_multiply-1024x730.png\" alt=\"Matrix Multiply\" width=\"491\" height=\"350\" />[line]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/matrix_transpose-1024x730.png\" alt=\"Matrix Transpose\" width=\"491\" height=\"350\" />[line]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/fft-1024x730.png\" alt=\"FFT\" width=\"491\" height=\"350\" />[/tab][tab]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/lu-1024x730.png\" alt=\"LU\" width=\"491\" height=\"350\" />[line]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/svd-1024x730.png\" alt=\"SVD\" width=\"491\" height=\"350\" />[line]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/solve-1024x730.png\" alt=\"Solve\" width=\"491\" height=\"350\" />[/tab][tab]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/convs-1024x730.png\" alt=\"Convs\" width=\"491\" height=\"350\" />[line]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/conv-1024x730.png\" alt=\"Conv\" width=\"491\" height=\"350\" />[/tab][tab]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/sum-1024x730.png\" alt=\"sum\" width=\"491\" height=\"350\" />[line]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/sort-1024x730.png\" alt=\"sort\" width=\"491\" height=\"350\" />[line]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/scan-1024x730.png\" alt=\"scan\" width=\"491\" height=\"350\" />[/tab][/tabs][/column][column type=\"one-fifth\" last=\"true\"].[/column]\r\n<div id=\"free\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\" ]\r\n\r\n[column type=\"one-half\"].[/column][column type=\"one-fourth\"].[custom_headline type=\"center\"  level=\"h3\" class=\"mtn\"]ArrayFire Free[/custom_headline][/column][column type=\"one-fourth\" last=\"true\"].[/column][column type=\"one-fourth\"  fade=\"true\" fade_animation=\"in-from-left\" ][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/right-leaning-e1391788779101.png\"][/column][column type=\"one-fourth\"]\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td>[custom_headline type=\"center\" level=\"h5\"]Functions[/custom_headline]</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Basic Operations</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Arithmetic</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Signal Processing</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Image Processing</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Statistics</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Visualization</td>\r\n</tr>\r\n</tbody>\r\n</table>\r\n[gap size=\"17%\"][button type=\"flat\" block=\"true\" shape=\"rounded\" size=\"large\"  href=\"http://sandbox.arrayfire.com/download\"]Download ArrayFire[/button] [/column][column type=\"one-fourth\"]\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td>[custom_headline type=\"center\" level=\"h5\"]Hardware[/custom_headline]</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] CUDA</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] OpenCL</td>\r\n</tr>\r\n<tr>\r\n<td>[custom_headline type=\"center\" level=\"h5\"]Languages[/custom_headline]</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] C/C++</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Fortran</td>\r\n</tr>\r\n<tr>\r\n<td>[custom_headline type=\"center\" level=\"h5\"]Advanced[/custom_headline]</td>\r\n</tr>\r\n<tr>\r\n<td> [icon type=\"check-circle\" style=\"color: #8cc540;\"] GFOR Loop</td>\r\n</tr>\r\n</tbody>\r\n</table>\r\n[/column][column type=\"one-fourth\" last=\"true\"]\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td>[custom_headline type=\"center\" level=\"h5\"]Platforms[/custom_headline]</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Windows</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Linux</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] Mac</td>\r\n</tr>\r\n<tr>\r\n<td>[custom_headline type=\"center\" level=\"h5\"]Data Types[/custom_headline]</td>\r\n</tr>\r\n<tr>\r\n<td>[icon type=\"check-circle\" style=\"color: #8cc540;\"] All types</td>\r\n</tr>\r\n<tr>\r\n<td>[custom_headline type=\"center\" level=\"h5\"]Support[/custom_headline]</td>\r\n</tr>\r\n<tr>\r\n<td> [icon type=\"check-circle\" style=\"color: #8cc540;\"] Forums</td>\r\n</tr>\r\n</tbody>\r\n</table>\r\n<div id=\"licensing\"></div>\r\n[/column][gap size=\"8%\"]\r\n\r\n[pricing_table id=\"pricing\" columns=\"3\"][pricing_table_column  featured=\"false\" title=\"ArrayFire Developer\" currency=\"$\" price=\"499 / year\" interval=\"$149 / year (Academic)\"] [icon_list] [icon_list_item type=\"star\" ]Dedicated license [/icon_list_item] [icon_list_item  type=\"times-circle\"] Starts at 2 GPUs or devices [/icon_list_item] [icon_list_item type=\"times-circle\"] Linear algebra [/icon_list_item] [icon_list_item type=\"times-circle\"] Sparse matrices [/icon_list_item][icon_list_item type=\"times-circle\"] Phone support [/icon_list_item][icon_list_item type=\"times-circle\"] Premium support &amp; consulting [/icon_list_item][/icon_list] [button href=\" http://sandbox.arrayfire.com/product-category/arrayfire/\"] Purchase [/button] [/pricing_table_column] [pricing_table_column featured=\"true\" featured_sub=\"Most Popular\" title=\"ArrayFire Pro\" currency=\"$\" price=\"1,499 / year\" interval=\"$525 / year (Academic)\"] [icon_list] [icon_list_item type=\"star\"] Dedicated license [/icon_list_item] [icon_list_item type=\"star\"] Starts at 2 GPUs or devices [/icon_list_item] [icon_list_item type=\"star\"] Linear algebra [/icon_list_item][icon_list_item type=\"star\"] Sparse matrices [/icon_list_item][icon_list_item type=\"times-circle\"] Phone support [/icon_list_item][icon_list_item type=\"times-circle\"] Premium support &amp; consulting [/icon_list_item] [/icon_list] [button href=\" http://sandbox.arrayfire.com/product-category/arrayfire/\"]Purchase [/button] [/pricing_table_column] [pricing_table_column featured=\"false\" title=\"ArrayFire Enterprise\" currency=\"$\" price=\"2,999 / year\" interval=\"$1,049 / year (Academic)\"] [icon_list] [icon_list_item type=\"star\"] Dedicated license [/icon_list_item] [icon_list_item type=\"star\"] Starts at 2 GPUs or devices [/icon_list_item] [icon_list_item type=\"star\"] Linear algebra [/icon_list_item][icon_list_item type=\"star\"]Sparse matrices [/icon_list_item][icon_list_item type=\"star\"] Phone support[/icon_list_item][icon_list_item type=\"star\"]Premium support &amp; consulting [/icon_list_item][/icon_list] [button href=\" http://sandbox.arrayfire.com/product-category/arrayfire/\"] Purchase [/button] [/pricing_table_column] [/pricing_table]\r\n<div id=\"whitepapers\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\" ]\r\n\r\n[column type=\"one-half\"][gap size=\"20%\"][image type=\"thumbnail\" src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/wp2.jpg\"][button href=\"http://go.sandbox.arrayfire.com/l/37882/2014-05-29/dw83/37882/18534/arrayfire_matrix_computations_chrzeszczyk.pdf\" shape=\"rounded\" size=\"regular\" block=\"true\"]Download <em>Matrix Computations on the GPU with ArrayFire for C/C++</em>[/button][/column][column type=\"one-half\" last=\"true\"]\r\n\r\n[custom_headline type=\"left\" level=\"h3\" ]Whitepapers[/custom_headline]\r\n\r\n<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/Whitepaper-1.png\" alt=\"Whitepaper 1\" width=\"466\" height=\"374\" />\r\n\r\n&nbsp;\r\n\r\n[/column][gap size=\"10%\"]\r\n\r\n[column type=\"one-half\"]<img src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/Whitepaper-2.png\" alt=\"Whitepaper 2\" width=\"442\" height=\"304\" />[/column][column type=\"one-half\" last=\"true\"][image type=\"thumbnail\" src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/wp1.jpg\"][button href=\"http://go.sandbox.arrayfire.com/l/37882/2014-05-29/dw81/37882/18532/arrayfire_whitepaper.pdf\" shape=\"rounded\" size=\"regular\"  block=\"true\" float=\"right\"]Download <em>High-level GPU Computing in C, C++, and Fortran</em>[/button][/column]\r\n<div id=\"casestudies\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\" ]\r\n\r\n[column type=\"one-half\"][gap size=\"12%\"][custom_headline type=\"left\" level=\"h3\" ]Case Studies[/custom_headline]\r\n\r\nLearn how ArrayFire has worked in real code, including applications in academia, finance, government, life sciences, manufacturing, media, and oil &amp; gas.[/column][column type=\"one-half\" last=\"true\" fade=\"true\" fade_animation=\"in-from right\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/model-A.png\"][/column][custom_headline type=\"left\" level=\"h5\"]Academia [/custom_headline][accordion][accordion_item title=\"Accelerating LTE Simulation | Tsinghua University\"]\r\n\r\nAuthors: Yuan Gao, Yin Sun, Chun Hui Zhou, Xin Su, Xi Bin Xu, Shi Dong Zhou, Tsinghua University\r\nSpeedup: 3X\r\n\r\nFast simulations are a driving force in several research projects. However, the accompanying long simulation times can tend to be a drag in many of these projects. In this article, we shall bring up the example of the work on 3GPP LTE System Simulation by Yuan Gao et al (from Tsinghua University, Beijing) and demonstrate how the use of ArrayFire software can significantly improve the simulator performance and lead to faster validation times in simulation projects.[/accordion_item]\r\n\r\n[accordion_item title=\"High Performance Compressive Sensing | Rice University\"]\r\n\r\nAuthors: Nabor Reyna and Wotao Yin from Rice University\r\nSpeedup: 5X\r\n\r\nThis work deals with reconstruction of signals using partial Fourier matrices (RecPF). The major computational components of the algorithm involve shrinkage and FFTs. ArrayFire software is employed to accelerate this compute-heavy code.[/accordion_item]\r\n\r\n[accordion_item title=\"Power System Simulations | Indian Institute of Technology, Roorkee, India\"]\r\nAuthors: Indian Institute of Technology, Roorkee\r\nSpeedup: 35X\r\n\r\nPower flow studies are one of the most important aspects of power system planning and operation. The power flow reveals the sinusoidal steady state characteristics of the entire system - voltages, real and reactive power generated, and absorbed and line losses- elucidating the voltage magnitudes and angles at each bus, the generation of each generating unit, and real and reactive power losses in the system. All this is necessary to ensure the security, economy, and control of electrical energy distribution. Learn how ArrayFire software can deliver magnitudes of performance improvement over CPU-based solutions.[/accordion_item]\r\n\r\n[accordion_item title=\"Antenna Array Simulations | University of Naples Federico II\"]\r\n\r\nAuthors: A. Capozzoli, C. Cucio, A. Liseno at University of Naples Federico II\r\nSpeedup: 24X\r\n\r\nAntenna array design involves repeated simulation to tune the many parameters involved, and waiting around for simulations to finish is no fun. Offloading the optimization problem onto the GPU cuts that time down significantly. In their recent paper, Capozzoli, Curcio, and Liseno of University of Naples Federico II demonstrated how a simple modification to their echo generator array simulation took advantage of the GPU to bring immediate speedups.[/accordion_item]\r\n\r\n[accordion_item title=\"Laplace Transform Inversion | Acunum Algorithms and Simulations\"]\r\n\r\nAuthors: Patrick Kano and Moysey Brio at Acunum Algorithms and Simulations\r\nSpeedup: 3.8X\r\n\r\nThe numerical inversion of the Laplace transform is a long standing problem due its implicit ill-posedness. Patrick Kano and Moysey Brio of Acunum Algorithms and Simulations, with their experience in computational methods and algorithm development, found a solution that not only works, but is very fast.[/accordion_item]\r\n\r\n[accordion_item title=\"Compressed Sensing for Image Reconstruction | College of Engineering, Roorkee, India\"]\r\n\r\nAuthors: Kuldeep Yadav, Ankush Mittal, M. A. Ansar, and Avi Srivastava, College of Engineering, Roorkee, India\r\nSpeedup: 8X\r\n\r\nCompressed sensing is very critical in the areas of medical image reconstruction, image acquisition or sensor networks. An algorithm for compressed sensing developed using a Basis Pursuit Algorithm shows over 8X speedup when run on an NVIDIA GPU.[/accordion_item]\r\n\r\n[accordion_item title=\"Fat/Water Reconstruction for Medical Images | Case Western Reserve University\"]\r\n\r\nAuthors: D. H. Johnson, S. Narayan, C. A. Flask, and D. L. Wilson, Case Western Reserve University\r\nSpeedup: 11.6X\r\n\r\nCase Western Reserve University researchers turned to GPUs running ArrayFire software to develop a fast and robust version of the \"Iterative Decomposition of water and fat with an Echo Asymmetry and Least-squares\" (IDEAL) reconstruction algorithm. This algorithm uses a lot of Image Processing algorithms for reconstruction, and was shown to achieve very high speedups.\r\n[/accordion_item]\r\n\r\n[/accordion]\r\n<h5>Finance</h5>\r\n[accordion][accordion_item title=\"Option Pricing | Koch Supply and Trading\"]\r\n\r\nAuthors: Koch Supply &amp; Trading\r\nSpeedup: 51.8X\r\n\r\nAndrew Shin, Market Risk Manager of Koch Supply &amp; Trading, achieves significant performance increases on option pricing algorithms using ArrayFire software to accelerate his code with GPUs. Andrew says, \"My buddy and I are, at best, novice programmers and we couldn\'t imagine having to figure out how to code all this in CUDA.\" But he found ArrayFire software to be straight-forward. With these results, he says he can see ArrayFire software and GPUs populating Koch\'s mark-to-futures cube, which contains its assets, simulations, and simulated asset prices.[/accordion_item]\r\n\r\n[accordion_item title=\"GPU Computing in Automated Trader | Automated Trader\"]\r\n\r\nAuthors: Automated Trader\r\nSpeedup: 37.5X\r\n\r\nThe Q1 2012 issue of Automated Trader contains an excellent Mashup piece reviewing software for algorithmic trading. The article provides a wonderful glimpse into the 1-2 month adventure of Andy Webb, Automated Trader.s Founder, and Wrecking Crew building a fast trading platform from several technologies. The full trading platform they built was quite extensive. The part that caught our eye was the core computational component of the pipeline. That component involved permuting 1,000 potential pairs with cointegration tests for 350 time windows on each potential pair.\r\n[/accordion_item]\r\n[accordion_item title=\"GPUs in Quantitative Analytics and Finance | Private Bank\"]\r\n\r\nThe world of Quantitative finance is all about getting accurate results really, really fast. ArrayFire is working with one of the largest banks in Spain to maximize their output using GPUs. Click the link below for an overview of the uses of GPU computing in finance.[/accordion_item][/accordion]\r\n<h5>Government</h5>\r\n[accordion][accordion_item title=\"Powering Mars Research | NASA and UAA in Anchorage\" ]\r\n\r\nAuthors: NASA and UAA in Anchorage\r\nSpeedup: 5X\r\n\r\nThe main thrust of this research is improving mars rover image compression via GPUs and genetic algorithms. With ArrayFire software and GPUs, the researchers were able to achieve 5X speedups on the larger data sizes. The algorithm works by pairing neighboring pixels with a random one and then adjusting the random pixel based on whether it incrementally improves the original image. Babb described the algorithm as an embarrassingly parallel process, ideally suited to GPU acceleration. He estimates he has been able to achieve a 20 to 30 percent error reduction in subjects like fingerprints and satellite imagery.[/accordion_item]\r\n\r\n[accordion_item title=\"Radar Image Formation | System Planning Corporation\"]\r\n\r\nAuthors: Gary Rubin and Earl Sager - System Planning Corporation\r\nSpeedup: ~45X\r\n\r\nRadar imaging is computationally intensive. As a result, many imaging algorithms apply FFT-based approximations. While efficient, these algorithms sacrifice data fidelity for speed. Other algorithms better preserve information, but are often too slow for many applications. At System Planning Corporation (SPC) , we have implemented a SAR/ISAR imaging routine based on the Backprojection algorithm. Using ArrayFire software, we have demonstrated speedups of roughly 45x for large datasets.[/accordion_item]\r\n\r\n[accordion_item title=\"Radar Clutter Reduction | System Planning Corporation\"]\r\n\r\nAuthors: David Berger and Gary Rubin - System Planning Corporation\r\nSpeedup: 5-10X\r\n\r\nSystem Planning Corporation (SPC) uses ArrayFire software to accelerate radar processing algorithms. The system processes raw data from marine navigation radars using a variety of thresholding techniques to extract real targets from clutter. This involves highly data-parallel processing in which each radar pulse is subjected to the same computations; very few operations occur across multiple pulses. Using ArrayFire software, SPC has achieved 10x speed improvements relative to a Core i7-920 CPU and 5x improvements relative to a realtime DSP implementation.[/accordion_item]\r\n\r\n[accordion_item title=\"Novel Algorithms for Linear Algebra | SAIC\" ]\r\n\r\nAuthors: Nolan Davis and Daniel Redig, SAIC\r\nSpeedup: 3.5X\r\n\r\nNolan Davis and Daniel Redig at SAIC recently presented work on Hybrid GPU/Multicore Solutions for Large Linear Algebra Problems where they developed a novel algorithm for LU decomposition, one of the most important routines in linear algebra. They presented a Hybrid CPU/GPU computing approach, where problems too large to fit in GPU memory can also be solved faster than using only the CPU.\r\n[/accordion_item]\r\n[accordion_item title=\"Geolocation | BAE Systems\"]\r\n\r\nAuthors: BAE Systems\r\nSpeedup: 17X\r\n\r\nGeolocation is the identification of the real-world geographic location of a target of interest. In this application, the system receives the signal with an array of several antennas and computes the direction of arrival of the radio energy by measuring the time difference of arrival (or the phase difference) at the different antennas.\r\n[/accordion_item]\r\n[accordion_item title=\"Tsunami Modeling | University of Minnesota, Boise State, Saint Scholastica, and NCAR\"]\r\n\r\nAuthors: University of Minnesota, Boise State, Saint Scholastica, and NCAR\r\nSpeedup: 3-5X\r\n\r\nNatural catastrophic disasters like tsunamis commonly strike with little warning. For most people, tsunamis are underrated as major hazards. People sometimes wrongly believe that they occur infrequently and only along distant coasts. Tsunamis are usually caused by earthquakes. Seismic signals can give some margin of warning since the speed of tsunami waves travels at 1/30 the speed of seismic waves. Still there is little time between the creation of the tsunami and its impact making fast processing critical to producing effective warning systems. ArrayFire software was used to run an RBF simulation on the GPU with a time to solution not available by other alternatives.\r\n[/accordion_item][/accordion]\r\n<h5>Life Sciences</h5>\r\n[accordion][accordion_item title=\"Parallelized Gene Predictors | University of Quebec\" ]\r\n\r\nAuthors: University of Quebec\r\nSpeedup: 43X\r\n\r\nComputerized approaches to studying the human genome are challenged by the exploding amount of data, which doubles roughly every 6 months. In order to deal with this burgeoning datasets, demands for faster processing power continue to arise. This work focuses on predicting genes using frequency analysis with FFTs and with an equivalent technique known as Goertzel\'s algorithm. In these applications, the emphasis of this paper is to propose tools to geneticists and molecular biologists for the prediction or identification of new genes using existing complementary strategies. The criteria for these tools are speed, reliability, accuracy and ease of use, thus requiring little training.\r\n[/accordion_item]\r\n[accordion_item title=\"Pathology Advances with GPUs | Northeastern University\" ]\r\n\r\nAuthors: Laboratory for Spectral Diagnosis at Northeastern University\r\nSpeedup: 100X+\r\n\r\nOne element of the hyperspectral image analysis workflow that requires more than a traditional desktop workstation or personal computer is Hierarchical Cluster analysis (HCA). HCA requires a large amount of data space and substantial computation time (~11 hours) for typical datasets using a single processor personal computer. Rather than following the traditional approach of moving to a lower level programming language like C or C++ and complex parallel programming paradigms such as OpenMP or the Massage Passing Interface (MPI), the lab utilized graphics processing units, or GPUs, and the ArrayFire software platform. The solution allowed the lab to dramatically increase the performance of the analysis while substantially decreasing the amount of calendar time to reach the desired results.\r\n[/accordion_item]\r\n[accordion_item title=\"Hepatitis C Virus - Mutation Modeling | Centers for Disease Control and Prevention\" ]\r\n\r\nAuthors: CDC Research and Development Team\r\nSpeedup: ~20X\r\n\r\nThis case study provides a look at biological research regarding coordinated mutations of the Hepatitis C Virus (HCV). ArrayFire provided collaborative R&amp;D resources and greatly improved the speed of this HCV research with the use of parallelization, reducing the computing time from 40 days to less than 1 day. Most importantly, the conclusion of the case study illustrates the the relative price-performance of personal supercomputers that leverage GPUs and ArrayFire software provides a compelling solution versus other architectures and approaches.\r\n[/accordion_item]\r\n[accordion_item title=\"Accelerating the SPM Package for Neuroimaging | Georgia Institute of Technology\" ]\r\n\r\nAuthors: Georgia Institute of Technology\r\nSpeedup: 3.5X\r\n\r\nThe Georgia Tech team explores the value of ArrayFire software and GPUs for fMRI workflows within the popular SPM - Statistical Parametric Mapping software widely used in neuroscience research.\r\n[/accordion_item]\r\n[accordion_item title=\"Medical Image Compression | Indian Institute of Technology, Roorkee, India\" ]\r\n\r\nAuthors: Jaideep Singh, Ipseeta Aruni, R. Balasubramanian - IIT - Roorkee, India\r\nSpeedup: 38X\r\n\r\nThis study presents the acceleration of Haar wavelet-based image compression algorithm for medical imaging on the Graphics Processing Unit (GPU) using ArrayFire software. Due to bandwidth and image size constraints of medical imaging systems, image compression plays a vital role in reducing the bit rate of transmission or storage. Wavelet-based image compression provides the most promising approach for high quality image compression.\r\n[/accordion_item]\r\n[accordion_item title=\"Brain Displacement | Spencer Technologies\"]\r\n\r\nAuthors: Spencer Technologies\r\nSpeedup: 12X\r\n\r\nSpencer describes how ArrayFire software facilitates the development of fast algorithms enabling observation of brain displacement across depth with sampling density that far surpasses previous benchmarks.\r\n[/accordion_item]\r\n[accordion_item title=\"Multidimensional Scaling for Genomics | Leibniz Institute of Plant Genetics and Crop Plant Research\" ]\r\n\r\nAuthors: Leibniz Institute of Plant Genetics and Crop Plant Research\r\nSpeedup: 20-35X\r\n\r\nMultidimensional scaling (MDS) is a general computing technique to turn a distance matrix into a set of reconstructed points with pair-wise relationships approximating the original distances by points located in a usually low-dimensional space. ArrayFire software is used to enhance execution of the HiT-MDS procedure and delivers considerable performance improvement.\r\n[/accordion_item]\r\n[accordion_item title=\"Drug Delivery Model | Georgia Institute of Technology\"]\r\n\r\nAuthors: Georgia Institute of Technology\r\nSpeedup: 70X\r\n\r\nIn this work, the researchers simulate the delivery of a novel nanoparticle chemotherapy drug to cancerous tissue. Simulation allows scientists to predict experimental outcomes and thus reduce the cost of development and time to clinical relevance. The simulation model includes blood vessels, tumor cells, and healthy cells and an engine to calculate the spatial distributions of both drug and oxygen. ArrayFire software is used to speed up the diffusion calculations for the drug and oxygen within the tissue.\r\n[/accordion_item]\r\n[accordion_item title=\"Biomedical Infrared Spectroscopy | University of Manchester and Nofima Mat, Norway\" ]\r\n\r\nAuthors: University of Manchester and Nofima Mat, Norway\r\nSpeedup: Hours of runtime reduction\r\n\r\nThe authors present an iterative algorithm that applies full Mie scattering theory and avoids noise accumulation in their iterative algorithm by integrating a curve-fitting step. ArrayFire software along with NVIDIA GPUs are leveraged to reduce the time added by the curve-fitting step.\r\n[/accordion_item][/accordion]\r\n<h5>Manufacturing</h5>\r\n[accordion][accordion_item title=\"Feature Learning on Images | Stanford\" ]\r\n\r\nAuthors: Andrew Ng, Stanford University\r\nSpeedup: Ability to process many images in parallel\r\n\r\nStanford researchers in Andrew Ng\'s group used GPUs and ArrayFire software to speed up their work on Feature Learning Architectures. They decided to use ArrayFire software for this study because of the need to quickly evaluate many architectures on thousands of images. ArrayFire software taps into the immense computing power of GPUs and speeds up research utilizing many images.\r\n[/accordion_item]\r\n[accordion_item title=\"Tomography of Vegetation - Filtered Back-Projection and Non-Uniform FFTs | Universita di Napoli Federico II\" ]\r\n\r\nAuthors: Drs. Capozzoli, Curcio, di Vico, and Liseno, Universita di Napoli Federico II\r\nSpeedup: 10X\r\n\r\nIn order to investigate changes of forest biomass, scientists use microwave tomography to image the vegetation. At the smallest scale, individual plants can be imaged to investigate branching and growth, but even synthetic aperture radar can reveal large-scale changes in regional ecology. To the right, you can see the experimental setup to image an individual plant.\r\n[/accordion_item]\r\n[accordion_item title=\"Action Recognition with Independent Subspace Analysis | Stanford University\" ]\r\n\r\nAuthors: Quoc Le, Will Zou, Serena Yeung, Andrew Ng, Stanford University\r\nSpeedup: 4.4X\r\n\r\nIn a paper at this year\'s CVPR 2011, entitled \"Learning hierarchical invariant spatio-temporal features for action recognition with independent subspace analysis\", the authors explain how their unsupervised feature learning algorithm competes with other algorithms that are hand crafted or use learned features. For their training purposes, they used a multi-layered stacked convolutional ISA (Independent subspace analysis) network. An ISA is used for learning features from image patches without supervision.\r\n[/accordion_item][/accordion]\r\n<h5>Media and Computer Vision</h5>\r\n[accordion][accordion_item title=\"Fast Computer Vision with OpenCV and ArrayFire | OpenCV Blogger\" ]\r\n\r\nAuthors: OpenCV Blogger\r\nSpeedup: ~10X\r\n\r\nThe OpenCV library is the defacto standard for doing computer vision and image processing research projects. OpenCV includes several hundreds of computer vision algorithms, aimed for use in realtime vision applications. This case study shows how to use both libraries together. There is a simple example application that demonstrates using OpenCV for webcam access and ArrayFire for some basic processing routines and displaying results.\r\n[/accordion_item]\r\n[accordion_item title=\"Video Processing | Google\" ]\r\n\r\nAuthors: Google and Stanford\r\nSpeedup: 10-20X\r\n\r\nVideo content analysis is the basis for categorizing videos and enabling search by content. Growing interest in using sparse-coding methods to extract motion features in video in support of video content analysis led to the application of ArrayFire software to improve performance by substantially accelerating the solution of the L1-regularized least-squares optimization problem.\r\n[/accordion_item]\r\n[accordion_item title=\"Action Recognition with Independent Subspace Analysis | Stanford University\"]\r\n\r\nAuthors: Quoc Le, Will Zou, Serena Yeung, Andrew Ng, Stanford University\r\nSpeedup: 4.4X\r\n\r\nIn a paper at this year\'s CVPR 2011, entitled \"Learning hierarchical invariant spatio-temporal features for action recognition with independent subspace analysis\", the authors explain how their unsupervised feature learning algorithm competes with other algorithms that are hand crafted or use learned features. For their training purposes, they used a multi-layered stacked convolutional ISA (Independent subspace analysis) network. An ISA is used for learning features from image patches without supervision.\r\n[/accordion_item]\r\n[accordion_item title=\"Music Beat Analysis | Georgia Tech\"]\r\n\r\nAuthors: Vidhur Vohra - Georgia Tech\r\nSpeedup: 15X\r\n\r\nDid you ever wonder how the music visualizer in your media player works? Watching it pulsate in synchrony with the beats of the song is almost as entertaining as listening to the song itself! Researchers have been attempting to detect beats in audio signals for many years, and there are many techniques available, from the simplest (and least accurate) to more complicated algorithms that are highly accurate. All algorithms, though, perform some form of signal processing and frequency analysis, applications highly suited to GPU Computing.\r\n[/accordion_item]\r\n[accordion_item title=\"Optimization Methods for Deep Learning | Stanford Artificial Intelligence Laboratory\" ]\r\n\r\nAuthors: Stanford Artificial Intelligence Laboratory\r\nSpeedup: Improved accuracy\r\n\r\nResearchers at SAIL (Stanford Artificial Intelligence Laboratory), have done it again. They have successfully used ArrayFire software to speed up the training part of Deep Learning algorithms. In their paper titled .On Optimization Methods for Deep Learning., they experiment with some of the well known training algorithms and demostrate their scalability across parallel architectures (GPUs as well as multi-machine networks). The algorithms include SGDs (Stochastic Gradient Descent) L-BFGS (Limited BFGS used for solving non-linear problems), CG (Conjugate Gradient).\r\n[/accordion_item]\r\n[accordion_item title=\"Feature Learning on Images | Stanford University\" ]\r\n\r\nAuthors: Andrew Ng, Stanford University\r\nSpeedup: Ability to process many images in parallel\r\n\r\nStanford researchers in Andrew Ng’s group used ArrayFire software to speed up their work on Feature Learning Architectures. They decided to use ArrayFire software for this study because of the need to quickly evaluate many architectures on thousands of images. ArrayFire software taps into the immense computing power of GPUs and speeds up research utilizing many images.\r\n[/accordion_item]\r\n[accordion_item title=\"Digital Holography for Imaging | National University of Ireland, Maynooth\" ]\r\n\r\nAuthors: Nitesh Pandey, Damien Kelly, Bryan Hennelly and Thomas Naughton from the National University of Ireland, Maynooth\r\nSpeedup: 17X\r\n\r\nDigital holography is a powerful imaging technique with many new applications like true 3D display. It allows the capture of both amplitude and phase information of the light reflected off the surface of 3D objects. Researchers at the National University of Ireland, Maynooth are developing techniques based on digital holography for 3D display applications.\r\nReconstruction of large digital holograms can be computationally intensive to generate on CPUs, but GPUs running ArrayFire software offer amazing possibilities.\r\n[/accordion_item][/accordion]\r\n<h5>Oil and Gas</h5>\r\n[accordion][accordion_item title=\"3D Mantle Convection - Geodynamics | Boise State, University of Colorado, University of Minnesota\" ]\r\n\r\nAuthors: Boise State, University of Colorado, University of Minnesota\r\nSpeedup: 2.5-4.5X\r\n\r\nThe authors introduce a GPU implementation of a three-dimensional mantle convection modeling at a high Rayleigh number to the solid earth geophysics community. They outline code development time, compare performance of CPUs versus GPUs, and deliver powerful visualizations.\r\n[/accordion_item]\r\n[accordion_item title=\"Ground Water Simulations | Louisiana State University\" ]\r\n\r\nAuthors: Kevin R. Tubbs and Frank T-C. Tsai at Louisiana State University\r\nSpeedup: &gt;20X\r\n\r\nA lattice Boltzmann method for solving the shallow water equations and the advection-dispersion equation is developed and implemented on graphics processing unit (GPU)-based architectures. The proposed LBM is implemented to an NVIDIA Computing Processor in a single GPU workstation. GPU computing is performed using ArrayFire software. Mass transport with velocity-dependent dispersion in shallow water flow is simulated by combining the MRT-LBM model and the TRT-LBM model. The GPU parallel performance increases as the grid size increases. The results indicate the promise of the GPU-accelerated LBM for modeling mass transport phenomena in shallow water flows.\r\n[/accordion_item]\r\n[accordion_item title=\"Shallow Water Fluid Flow | Louisiana State University\" ]\r\n\r\nAuthors: Louisiana State University\r\nSpeedup: &gt;10X\r\n\r\nA lattice Boltzmann method (LBM) on high performance computing (HPC) environments for three-dimensional shallow water flow fields coupled to mass transport is developed. LBM is an attractive method for solving the multilayered shallow water equations because the extension to multilayer is straight forward with all of the simplicities and advantages of the LBM in mass transport in shallow water flows and the LBM performance on central processing unit (CPU)-based and graphics processing unit (GPU)-based HPC environments.\r\n[/accordion_item][/accordion]\r\n<div id=\"consulting\"></div>\r\n[/content_band]\r\n<div id=\"services\"></div>\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"][column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\"]Hire our acceleration gang[/custom_headline]\r\n\r\nHire us to accelerate your code. Or to train your pros. Or even to write new code for your organization!\r\n\r\nWe’ve already helped thousands of organizations speedup their code. We’ve accelerated algorithms, data sets, and challenging problems of all types in the past, and we’re confident that we can accelerate your code too.\r\n\r\n[gap size=\"10%\"][button  type=\"flat\" shape=\"rounded\" href=\"http://meetme.so/arrayfire\" size=\"x-large\" ]Schedule a consultation[/button][/column][column type=\"one-half\" last=\"true\" class=\"center-text\"][gap size=\"5%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/Bat-signal-e1391790016951.png\"][/column] [gap size=\"7%\"]\r\n\r\n[column type=\"one-third\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/LFG-B-HORZ_202_K-e1396448935778.jpg\"][line]Lincoln Financial Group ported their CPU code (C/C++) to CUDA, and this enabled them to speed up the necessary financial calculations. Their primary objective was to reduce the time taken to run this code. Before porting to CUDA, they required 10-12 hours to run the entire code. After porting to CUDA, they were able to do the same work in about 30 minutes.[/column][column type=\"one-third\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/reveal_logo-e1396449044651.jpg\"][line]Reveal Imaging, an SAIC company, uses ArrayFire in developing threat-detection products for transportation systems—such as cargo and baggage screening in airports—and in securing facilities and public events.[/column][column type=\"one-third\" last=\"true\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/1800contactlogo.png\"][line]The Glasses.com app relies on computer vision to recognize the features of a user’s face. The application then generates an accurate, high-fidelity, three-dimensional model of that face, and virtually places selected frames on the image.[/column]\r\n<div id=\"starterpackage\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"]\r\n\r\n[column type=\"one-half\" last=\"false\" fade=\"true\" fade_animation=\"in-from-left\" ][gap size=\"10%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/comingatyou.png\"][/column][column type=\"one-half\" last=\"true\"] [custom_headline type=\"left\" level=\"h3\"]Starter Package ($500)* [/custom_headline] Hire us for 1-day. We set you up with one engineer dedicated for a full day, as well as support from senior and test engineers throughout the day. Here\'s how it works:\r\n\r\n[icon_list] [icon_list_item type=\"angle-double-right\"]Initial phone call[/icon_list_item] [icon_list_item type=\"angle-double-right\"]You send us your code or algorithm [/icon_list_item] [icon_list_item type=\"angle-double-right\"]We analyze your code for potential GPU benefit[/icon_list_item][icon_list_item type=\"angle-double-right\"]We accelerate as much of the code as is possible within the 1-day effort, applying our extensive GPU software libraries[/icon_list_item][icon_list_item type=\"angle-double-right\"]We produce a final report, along with code[/icon_list_item] [/icon_list] The final report outlines the best approach to follow for full GPU-acceleration of your code.\r\n\r\n&nbsp;\r\n\r\n[button type=\"flat\" shape=\"rounded\" size=\"regular\" href=\"http://sandbox.arrayfire.com/product/consulting-starter-package/\" title=\"Starter Package\"]Buy the Starter Package[/button]\r\n\r\n&nbsp;\r\n\r\n*Limit one (1) per customer.\r\n\r\n[/column]\r\n<div id=\"customcode\"></div>\r\n[/content_band] [content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\" ]\r\n\r\n[column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\" ]Custom Coding Work[/custom_headline]\r\n\r\n[custom_headline type=\"left\" level=\"h6\" ]Why Choose Us?[/custom_headline] [icon_list] [icon_list_item type=\"angle-double-right\"]Deep experience, already servicing thousands of customers[/icon_list_item] [icon_list_item type=\"angle-double-right\"]Quality work, with leading GPU software [/icon_list_item] [icon_list_item type=\"angle-double-right\"]Efficient delivery, with ArrayFire\'s code base we can deliver results fast[/icon_list_item][icon_list_item type=\"angle-double-right\"]Proven, we make customers happy through faster code[/icon_list_item][/icon_list] [custom_headline type=\"left\" level=\"h6\" ]Our Strengths[/custom_headline] [icon_list] [icon_list_item type=\"angle-double-right\"]Excellence in GPU code[/icon_list_item] [icon_list_item type=\"angle-double-right\"]Well-written, efficient C, C++, Fortran, Java, or .NET [/icon_list_item] [icon_list_item type=\"angle-double-right\"]Application porting and integration[/icon_list_item][icon_list_item type=\"angle-double-right\"]Tuning software to peak hardware performance[/icon_list_item][icon_list_item type=\"angle-double-right\"]Scalability of algorithms to handle enterprise-level programs[/icon_list_item] [/icon_list][button type=\"flat\" shape=\"rounded\" size=\"regular\" href=\"http://meetme.so/arrayfire\" title=\"Tech Consultation\"]Schedule a consultation[/button] [/column][column type=\"one-half\"  fade=\"true\" fade_animation=\"in-from-right\" last=\"true\" ][gap size=\"25%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/Holoham.png\"][/column]\r\n<div id=\"training\"></div>\r\n[/content_band] [content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\" ]\r\n\r\n[column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\" ]Training[/custom_headline] Attendees will receive the latest industry knowledge and techniques for GPU computing in CUDA and OpenCL.\r\n\r\nArrayFire offers up to four days of specialized GPU training in CUDA and OpenCL programming. We provide customized on-site training courses for customers that have 3 or more attendees from their organization. We can travel to your location and provide a CUDA or OpenCL training course tailored to meet your application-specific needs. We also offer individual trainings at our Atlanta office. Please <a href=\"mailto:sales@arrayfire.com\">contact us</a> to learn more about our training offerings.\r\n\r\nWe recommend that attendees have a working knowledge of C/C++ in order to gain the most from the training courses. For more information about the content of our training lectures and hands-on practicums, please see the following training course syllabus.\r\n\r\n[/column]\r\n\r\n[column type=\"one-half\" last=\"true\" fade=\"true\" fade_animation=\"in-from-right\" class=\"center-text\"][gap size=\"15%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/Professor-AF_Exported-e1395436350363.png\" ][/column]\r\n\r\n[column type=\"one-half\" class=\"center-text\"] [gap size=\"17%\"]\r\n<div>[button type=\"flat\" shape=\"rounded\" size=\"jumbo\" href=\"mailto:sales@arrayfire.com?Subject=Training%20Inquiry\"] Register for Training[/button]</div>\r\n[/column][column type=\"one-half\" last=\"true\"][custom_headline type=\"left\" level=\"h3\"]Included in Course[/custom_headline]\r\n\r\n[icon_list] [icon_list_item type=\"angle-double-right\"]Instruction by an excellent and interesting expert, with hands-on exercises[/icon_list_item] [icon_list_item type=\"angle-double-right\"]Use of a laptop with CUDA and OpenCL capable GPUs and CPUs [/icon_list_item] [icon_list_item type=\"angle-double-right\"]Choice of Linux or Windows operating system[/icon_list_item][icon_list_item type=\"angle-double-right\"]Printed manual of lecture material[/icon_list_item][icon_list_item type=\"angle-double-right\"]Electronic copy of programming exercises[/icon_list_item][/icon_list]\r\n\r\n[/column]\r\n\r\n<span>[gap size=\"5%\"]</span>\r\n\r\n[custom_headline type=\"left\" level=\"h3\"]Training Course Syllabus[/custom_headline] [column type=\"one-half\"] [custom_headline type=\"left\" level=\"h5\"  accent=\"false\"]Day 1, Introduction[/custom_headline] Lectures:\r\nGPU Computing Overview\r\nThe Programming Model\r\nBasic Dataset Mapping Techniques\r\nLibraries, ArrayFire\r\nProfiling Tools\r\n\r\nPractice:\r\nA Simple Kernel\r\nEquivalent ArrayFire Example\r\nUsing Libraries\r\nMonte Carlo Pi Estimation\r\nTiming and ArrayFire\r\nDebugging Code\r\n\r\n[custom_headline type=\"left\" level=\"h5\" accent=\"false\"]Day 3, Multi-GPU[/custom_headline] Lectures:\r\nMulti-GPU Use Cases\r\nMulti-GPUs: Contexts\r\nExisting Libraries\r\nScaling Across Multiple GPUs\r\n\r\nPractice:\r\nOut of Core Problems: Matrix Multiply\r\nTask Level Parallelism: Optimization\r\nArrayFire Multi-GPU[/column]\r\n\r\n[column type=\"one-half\" last=\"true\"] [custom_headline type=\"left\" level=\"h5\" accent=\"false\"]Day 2, Optimization[/custom_headline] Lectures:\r\nArchitecture: Grids, Blocks, and Threads\r\nMemory Model: Global, Shared, and Constant Memory\r\nAdvanced Mapping Techniques\r\nStreams: Asynchronos Launches and Concurrent Execution\r\nArrayFire: Lazy Evaluation and Code Vectorization\r\n\r\nPractice:\r\nMatrix Transpose\r\nOptimization Using Shared Memory\r\nMedian Filter\r\nOptimization Using Constant Memory\r\nStream Example\r\nArrayFire Example: Nearest Neighbor Algorithm\r\n\r\n[custom_headline type=\"left\" level=\"h5\" accent=\"false\"]Day 4, Algorithm Problems[/custom_headline]\r\n\r\nLectures and Practice:\r\nReductions\r\nScan Algorithms\r\nSort\r\nConvolution\r\nCustomer-Specific Problem [/column][/content_band]','Home OPSC','','inherit','open','open','','6613-revision-v1','','','2014-09-15 20:20:33','2014-09-15 20:20:33','',6613,'http://sandbox.arrayfire.com/6613-revision-v1/',0,'revision','',0),(6617,7,'2014-09-15 20:22:32','2014-09-15 20:22:32','[content_band inner_container=\"true\" no_margin=\"true\" border=\"none\" padding_top=\"40px\" padding_bottom=\"40px\"][column type=\"two-fifths\"]\r\n\r\n[custom_headline type=\"left\" level=\"h3\"]If you want faster code, you\'ve come to the right place.[/custom_headline][gap size=\"15%\"][button  type=\"flat\" shape=\"rounded\" href=\"http://sandbox.arrayfire.com/download\" size=\"x-large\" block=\"true\"]Download ArrayFire[/button]\r\n\r\n[gap size=\"10%\"]\r\n\r\n[button  type=\"flat\" block=\"true\" shape=\"rounded\" href=\"http://www.meetme.so/arrayfire\" size=\"x-large\" ]Schedule a consultation[/button]\r\n\r\n[/column][column type=\"three-fifths\" last=\"true\"][gap size=\"7%\"]\r\n<div id=\"wistia_rj2bar3xxp\" class=\"wistia_embed\"></div>\r\n[/column]\r\n<div id=\"arrayfire\"></div>\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"][column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\"]Faster code[/custom_headline]\r\n\r\nArrayFire is a fast, hardware-neutral software library for GPU computing with an easy-to-use API. Its array-based function set makes GPU programming simple. A few lines of code in ArrayFire can replace dozens of lines of raw GPU code, saving you valuable time and lowering development costs.\r\n\r\n[gap size=\"10%\"][button  type=\"flat\" shape=\"rounded\" href=\"http://sandbox.arrayfire.com/download\" size=\"x-large\" ]Download ArrayFire[/button][/column][column type=\"one-half\" last=\"true\" class=\"center-text\"][gap size=\"5%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/Triumvirate_Exported.png\"][/column] [gap size=\"5%\"]\r\n\r\n[column type=\"one-third\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/Googlelogo-e1396387097279.png\"][line]Video content analysis is the basis for categorizing videos and enabling search by content. Google used ArrayFire to extract motion features in video, improving performance by substantially accelerating the solution of the L1-regularized least-squares optimization problem.[/column][column type=\"one-third\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/Koch-Industries-e1396387359637.jpg\"][line]Andrew Shin, Market Risk Manager of Koch Supply &amp; Trading, achieves significant performance increases on option pricing algorithms using ArrayFire software, \"My buddy and I are, at best, novice programmers and we couldn\'t imagine having to figure out how to code all this in CUDA.\"[/column][column type=\"one-third\" last=\"true\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/nasa-e1396387230473.png\"][line]The main thrust of this research was improving Mars rover image compression via GPUs and genetic algorithms. With ArrayFire software and GPUs, the researchers were able to achieve 5X speedups on the larger data sizes.[/column]\r\n<div id=\"hardware\"></div>\r\n[/content_band]\r\n\r\n&nbsp;','Home OPSC','','inherit','open','open','','6613-revision-v1','','','2014-09-15 20:22:32','2014-09-15 20:22:32','',6613,'http://sandbox.arrayfire.com/6613-revision-v1/',0,'revision','',0),(6631,7,'2014-11-10 20:05:17','2014-11-10 20:05:17','<div>\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"]\r\n[column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\"  ]Mobile GPU Computing[/custom_headline]\r\n\r\nMobile GPUs offer accelerated performance. If you would like to use ArrayFire in a mobile application or if you would like to hire our mobile acceleration services, email us at <a href=\"mailto:sales@arrayfire.com\" target=\"_blank\">sales@arrayfire.com</a> and include a description of your application.\r\n\r\nOur clients have achieved between 5X to 30X speed boosts for convolutions and other compute functions on mobile devices. It enables:[icon_list][icon_list_item type=\"angle-double-right\"]Real-time video processing[/icon_list_item][icon_list_item type=\"angle-double-right\"]Better augmented reality [/icon_list_item][icon_list_item type=\"angle-double-right\"]Better computational photograph[/icon_list_item][icon_list_item type=\"angle-double-right\"]Faster data processing[/icon_list_item][/icon_list]\r\n\r\nAll mobile devices have a GPU which can deliver greater compute throughput than the CPU. Why not use the GPU to make your app faster?[/column][column type=\"one-half\" fade=\"true\" last=\"true\" fade_animation=\"in-from-right\" class=\"center-text\"][gap size=\"10%\"][image src=\"https://sandbox.arrayfire.com/wp-content/uploads/2014/02/mobile_Exported1-e1395437261846.png\"][/column]\r\n<div></div>\r\n[/content_band]\r\n\r\n</div>','Mobile','','publish','closed','closed','','mobile','','','2018-06-26 15:43:58','2018-06-26 19:43:58','',0,'http://sandbox.arrayfire.com/?page_id=6631',0,'page','',0),(6632,7,'2014-09-15 21:12:10','2014-09-15 21:12:10','','Mobile, OPSC','','inherit','open','open','','6631-revision-v1','','','2014-09-15 21:12:10','2014-09-15 21:12:10','',6631,'http://sandbox.arrayfire.com/6631-revision-v1/',0,'revision','',0),(6633,7,'2014-09-15 21:14:45','2014-09-15 21:14:45','<div>\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"]\r\n[column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\"  ]Mobile GPU Computing[/custom_headline]\r\n\r\nMobile GPUs offer accelerated performance. If you would like to use ArrayFire in a mobile application or if you would like to hire our mobile acceleration services, email us at <a href=\"mailto:sales@arrayfire.com\" target=\"_blank\">sales@arrayfire.com</a> and include a description of your application.\r\n\r\nOur clients have achieved between 5X to 30X speed boosts for convolutions and other compute functions on mobile devices. It enables:[icon_list][icon_list_item type=\"angle-double-right\"]Real-time video processing[/icon_list_item][icon_list_item type=\"angle-double-right\"]Better augmented reality [/icon_list_item][icon_list_item type=\"angle-double-right\"]Better computational photograph[/icon_list_item][icon_list_item type=\"angle-double-right\"]Faster data processing[/icon_list_item][/icon_list]\r\n\r\nAll mobile devices have a GPU which can deliver greater compute throughput than the CPU. Why not use the GPU to make your app faster?[/column][column type=\"one-half\" fade=\"true\" last=\"true\" fade_animation=\"in-from-right\" class=\"center-text\"][gap size=\"10%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/mobile_Exported1-e1395437261846.png\"][/column]\r\n<div></div>\r\n[/content_band]\r\n\r\n</div>','Mobile, OPSC','','inherit','open','open','','6631-revision-v1','','','2014-09-15 21:14:45','2014-09-15 21:14:45','',6631,'http://sandbox.arrayfire.com/6631-revision-v1/',0,'revision','',0),(6634,7,'2014-11-12 15:18:47','2014-11-12 15:18:47','[content_band inner_container=\"true\" no_margin=\"true\" border=\"none\" padding_top=\"10px\" padding_bottom=\"40px\"][column type=\"three-fifths\"][custom_headline type=\"left\" level=\"h2\"]Call the ArrayFire team[/custom_headline]\r\n\r\nHire us to accelerate your code, train your pros, or even write new code for your organization!\r\n\r\nWe’ve already helped thousands of organizations speed up their code. We’ve accelerated algorithms, sped up data analysis, and solved challenging problems of all types in the past, and we’re confident that we can accelerate your code, too.\r\n\r\nStart by setting up a free consultation to discuss your project with an ArrayFire expert today!\r\n\r\n[gap size=\"5%\"]\r\n\r\n[button  type=\"flat\" shape=\"rounded\" href=\"https://meetme.so/arrayfire\" size=\"normal\" ]Schedule a consultation[/button]\r\n\r\n[button  type=\"flat\" shape=\"rounded\" href=\"https://sandbox.arrayfire.com/case-studies\" size=\"normal\" ]Read Case Studies[/button]\r\n\r\n[/column]\r\n\r\n\r\n[column type=\"two-fifths\" last=\"true\" class=\"center-text\"][gap size=\"15%\"]<img class=\"aligncenter wp-image-462\" src=\"https://sandbox.arrayfire.com/wp-content/uploads/2014/01/Bat-signal.png\" alt=\"Bat signal\" width=\"700\" height=\"437\" />[/column][gap size=\"2%\"][/content_band]\r\n\r\n<!-- Starter Package Band -->\r\n[content_band bg_color=\"#f2f2f2\" inner_container=\"true\" no_margin=\"true\" border=\"none\" padding_top=\"10px\" padding_bottom=\"40px\"]\r\n\r\n[column type=\"one-half\"] [custom_headline type=\"left\" level=\"h2\"]Starter Package ($799) [/custom_headline] Hire us for a single day. We\'ll match you with one engineer dedicated for a full day, supported by senior and test engineers throughout the day. Here\'s how it works:\r\n\r\n[icon_list] [icon_list_item type=\"angle-double-right\"]We conduct an initial phone call.[/icon_list_item] [icon_list_item type=\"angle-double-right\"]You send us your code or algorithm. [/icon_list_item] [icon_list_item type=\"angle-double-right\"]We analyze your code for potential GPU benefit.[/icon_list_item][icon_list_item type=\"angle-double-right\"]We accelerate as much of your code as is possible within the one-day effort, applying our extensive GPU software libraries.[/icon_list_item][icon_list_item type=\"angle-double-right\"]We produce a final report for you, along with your optimized code.[/icon_list_item] [/icon_list] The final report outlines the best approach to follow for full GPU-acceleration of your code.\r\n\r\n[button type=\"flat\"  shape=\"rounded\" size=\"regular\" href=\"https://sandbox.arrayfire.com/product-category/starter-package/\" title=\"Starter Package\"]Get the Starter Package[/button]\r\n\r\n&nbsp;\r\n\r\n[/column][column type=\"one-half\" last=\"true\" ][gap size=\"15%\"]<img class=\"aligncenter wp-image-4962\" src=\"https://sandbox.arrayfire.com/wp-content/uploads/2014/02/Benchmark-guy-torso-opposite.png\" alt=\"Benchmark guy, torso opposite\" width=\"450\" height=\"397\" />[/column]\r\n<div></div>\r\n[/content_band]\r\n\r\n<!-- Software Design Horizontal Band -->\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"none\" padding_top=\"0px\" margin_top=\"0px\" padding_bottom=\"40px\" ]\r\n\r\n<!-- Link from home page -->\r\n<a name=\"software-design\"></a>\r\n\r\n[custom_headline type=\"left\" level=\"h2\" class=\"center-text\"]Software Design[/custom_headline]\r\n\r\nYour hardware can do anything, given the right code. Getting that code right can be tricky when your team is swamped in work or when you\'re new to parallel programming. Bring us in—our team is capable of writing custom code that\'s as unique as your work and tailored to your task. Here\'s what we bring to the table:\r\n\r\n[column type=\"one-half\"]\r\n\r\n[icon_list] [icon_list_item type=\"angle-double-right\"]Excellence in GPU code[/icon_list_item] [icon_list_item type=\"angle-double-right\"]Well-written, efficient C, C++, Fortran, Java, or .NET [/icon_list_item] [icon_list_item type=\"angle-double-right\"]Application porting and integration[/icon_list_item][icon_list_item type=\"angle-double-right\"]Tuning software to peak hardware performance[/icon_list_item][icon_list_item type=\"angle-double-right\"]Scalability of algorithms to handle enterprise-level programs[/icon_list_item] [/icon_list]\r\n\r\nRead more about our capabilities in our <a href=\"/case-studies\">case studies</a> or check out one of our more involved projects to the right.\r\n\r\n[button  type=\"flat\" shape=\"rounded\" href=\"https://meetme.so/arrayfire\" size=\"regular\" ]Schedule a consultation[/button]\r\n[/column]\r\n\r\n[column type=\"one-half\"]\r\n[promo image=\"https://sandbox.arrayfire.com/wp-content/uploads/2014/10/glasses-logo-promo-01.png\" alt=\"Glasses.com\"]The Glasses.com app relies on computer vision functionality and three-dimentional head modeling code implemented and accelerated by ArrayFire. This code generates accurate, high-fidelity images that let a user virtually try on thousands of pairs of glasses without leaving the comfort of their own home.\r\n<p style=\"text-align: center;\">[button type=\"flat\" shape=\"rounded\" href=\"https://sandbox.arrayfire.com/case-study-glasses-com-app-with-3dfit-technology\" size=\"regular\" ]Read the case study[/button]</p>\r\n[/promo]\r\n\r\n[/column]\r\n\r\n [/content_band]\r\n\r\n<!-- System Evaluation Horizontal Band -->\r\n[content_band bg_color=\"#f2f2f2\" inner_container=\"true\" no_margin=\"true\" border=\"none\" padding_top=\"10px\" padding_bottom=\"40px\"]\r\n\r\n<!-- Link from home page -->\r\n<a name=\"system-evaluation\"></a>\r\n\r\n[custom_headline type=\"left\" level=\"h2\" class=\"center-text\"]System Evaluation[/custom_headline]\r\n\r\nGetting the maximum performance out of your system is tricky to say the least. The interplay between network communication, disk operations, and processing can be tricky to understand and even more difficult to profile correctly. Our team excels at benchmarking and we know how to find the bottleknecks in your application quickly. Hire us to evaluate sections of your code or the entire system. We do it all! Here is what we bring to the table:\r\n\r\n[column type=\"one-half\"  last=\"true\" ]\r\n\r\n[icon_list]\r\n[icon_list_item type=\"angle-double-right\"]System architecture and design expertise\r\n[/icon_list_item]\r\n\r\n[icon_list_item type=\"angle-double-right\"]In-depth knowledge and a plethora of field experience optimizing applications and processes for CPUs, GPUs, and FPGAs.[/icon_list_item]\r\n\r\n[icon_list_item type=\"angle-double-right\"]Awareness of the latest industry trends and tools[/icon_list_item]\r\n\r\n[icon_list_item type=\"angle-double-right\"]Hands on experience auditing on large, complicated systems.[/icon_list_item]\r\n\r\n[/icon_list][button  type=\"flat\" shape=\"rounded\" href=\"https://meetme.so/arrayfire\" size=\"regular\" ]Schedule a consultation[/button][/column]\r\n\r\n[column type=\"one-half\"]\r\n\r\n[promo image=\"https://sandbox.arrayfire.com/wp-content/uploads/2016/08/pT5oEjE8c-1024x240.jpg\" alt=\"San Fransisco Skyline\"]A Fortune 200 Insurance Company contacted ArrayFire to conduct an audit of their system in nine key areas. Two of these were scalability and optimization techniques. Through our comprehensive review ArrayFire located key bottleknecks that, once corrected, decreased total nightly runtime by 39% without any major code or system modifications.\r\n<p style=\"text-align: center;\">[button type=\"flat\" shape=\"rounded\" href=\"https://sandbox.arrayfire.com/case-study-fortune-200-insurance-company\" size=\"regular\" ]Read the case study[/button]</p>\r\n[/promo]\r\n\r\n[/column]\r\n\r\n[/content_band]','Consulting','','publish','closed','closed','','consulting','','','2018-06-26 15:42:58','2018-06-26 19:42:58','',0,'http://sandbox.arrayfire.com/?page_id=6634',0,'page','',0),(6635,7,'2014-09-15 21:20:45','2014-09-15 21:20:45','<div>\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\"][column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\"]Hire our acceleration gang[/custom_headline]\r\n\r\nHire us to accelerate your code. Or to train your pros. Or even to write new code for your organization!\r\n\r\nWe’ve already helped thousands of organizations speedup their code. We’ve accelerated algorithms, data sets, and challenging problems of all types in the past, and we’re confident that we can accelerate your code too.\r\n\r\n[gap size=\"10%\"][button  type=\"flat\" shape=\"rounded\" href=\"http://meetme.so/arrayfire\" size=\"x-large\" ]Schedule a consultation[/button][/column][column type=\"one-half\" last=\"true\" class=\"center-text\"][gap size=\"5%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/01/Bat-signal-e1391790016951.png\"][/column] [gap size=\"7%\"]\r\n\r\n[column type=\"one-third\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/LFG-B-HORZ_202_K-e1396448935778.jpg\"][line]Lincoln Financial Group ported their CPU code (C/C++) to CUDA, and this enabled them to speed up the necessary financial calculations. Their primary objective was to reduce the time taken to run this code. Before porting to CUDA, they required 10-12 hours to run the entire code. After porting to CUDA, they were able to do the same work in about 30 minutes.[/column][column type=\"one-third\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/reveal_logo-e1396449044651.jpg\"][line]Reveal Imaging, an SAIC company, uses ArrayFire in developing threat-detection products for transportation systems—such as cargo and baggage screening in airports—and in securing facilities and public events.[/column][column type=\"one-third\" last=\"true\" class=\"center-text\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/04/1800contactlogo.png\"][line]The Glasses.com app relies on computer vision to recognize the features of a user’s face. The application then generates an accurate, high-fidelity, three-dimensional model of that face, and virtually places selected frames on the image.[/column]\r\n<div></div>\r\n[/content_band]\r\n\r\n</div>','Consulting, OPSC','','inherit','open','open','','6634-revision-v1','','','2014-09-15 21:20:45','2014-09-15 21:20:45','',6634,'http://sandbox.arrayfire.com/6634-revision-v1/',0,'revision','',0),(6640,7,'2014-11-11 22:04:25','2014-11-11 22:04:25','[content_band inner_container=\"true\" no_margin=\"true\" border=\"none\" padding_top=\"10px\" padding_bottom=\"40px\" ]\r\n\r\n[column type=\"one-half\"][custom_headline type=\"left\" level=\"h2\" ]Train your team[/custom_headline] Attendees will receive the latest industry knowledge and techniques for GPU computing in CUDA and OpenCL.\r\n\r\nArrayFire offers up to four days of specialized GPU training in CUDA and OpenCL programming. We provide customized on-site training courses where we can travel to your location and provide a CUDA or OpenCL training course tailored to meet your application-specific needs. We also offer individual trainings at our Atlanta office.\r\n\r\nWe recommend that attendees have a working knowledge of C/C++ in order to gain the most from the training courses.\r\n\r\n[button type=\"flat\" shape=\"rounded\"  size=\"regular\" href=\"mailto:sales@arrayfire.com?Subject=Training%20Inquiry\"]Contact us about a training[/button]\r\n\r\n[/column]\r\n\r\n[column type=\"one-half\" last=\"true\" fade=\"true\" fade_animation=\"in-from-right\" class=\"center-text\"][gap size=\"15%\"][image src=\"https://sandbox.arrayfire.com/wp-content/uploads/2014/02/Professor-AF_Exported-e1395436350363.png\" ][/column]\r\n\r\n[/content_band][content_band bg_color=\"#F2f2f2\" inner_container=\"true\" no_margin=\"true\" border=\"none\" padding_top=\"10px\" padding_bottom=\"40px\" ]\r\n\r\n[column type=\"one-half\"][gap size=\"10%\"]<img class=\"aligncenter wp-image-4806\" src=\"https://sandbox.arrayfire.com/wp-content/uploads/2014/01/gears1-e1395437543311.png\" alt=\"gears\" width=\"427\" height=\"400\" />\r\n\r\n[/column][column type=\"one-half\" last=\"true\"]\r\n\r\n[custom_headline type=\"left\" level=\"h2\"]Included in the course[/custom_headline]\r\n\r\nYou provide the minds, and we\'ll take care of the rest. Each training comes with the following:\r\n\r\n[icon_list] [icon_list_item type=\"angle-double-right\"]Instruction by an excellent and interesting expert[/icon_list_item] [icon_list_item type=\"angle-double-right\"]Hands-on exercises[/icon_list_item][icon_list_item type=\"angle-double-right\"]Use of a laptop with CUDA and OpenCL capable GPUs and CPUs [/icon_list_item] [icon_list_item type=\"angle-double-right\"]Choice of Linux or Windows operating system[/icon_list_item][icon_list_item type=\"angle-double-right\"]Printed manual of lecture material[/icon_list_item][icon_list_item type=\"angle-double-right\"]Electronic copy of programming exercises[/icon_list_item][/icon_list]\r\n\r\n[button type=\"flat\" shape=\"rounded\"  size=\"regular\" href=\"mailto:sales@arrayfire.com?Subject=Training%20Inquiry\"]Go ahead, contact us about a training[/button]\r\n\r\n[/column][/content_band]\r\n\r\n[content_band bg_image=\"https://sandbox.arrayfire.com/wp-content/uploads/2014/11/Epipheo-background1.png\" parallax=\"true\" inner_container=\"true\" no_margin=\"true\" border=\"none\" padding_top=\"10px\" padding_bottom=\"40px\" ]\r\n\r\n[blockquote cite=\"<span style=\"color: #ffffff;\">Brian Rapp</span>\" type=\"center\"]<span style=\"color: #ffffff;\">One can\'t ask for better individualized instruction than the environment I was fortunate enough to encounter.</span> <span style=\"color: #ffffff;\">The instructor was able to completely focus on my particular needs and concerns.</span>\r\n\r\n<span style=\"color: #ffffff;\">—Brian Rapp,  U.S. Army Research Lab</span>[/blockquote]\r\n\r\n[/content_band]\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"none\" padding_top=\"10px\" padding_bottom=\"40px\" ]\r\n\r\n[custom_headline type=\"left\" level=\"h2\"]Training Syllabus[/custom_headline] [column type=\"one-half\"] [custom_headline type=\"left\" level=\"h5\"  accent=\"false\"]Day 1, Introduction[/custom_headline] Lectures:\r\nGPU Computing Overview\r\nThe Programming Model\r\nBasic Dataset Mapping Techniques\r\nLibraries, ArrayFire\r\nProfiling Tools\r\n\r\nPractice:\r\nA Simple Kernel\r\nEquivalent ArrayFire Example\r\nUsing Libraries\r\nMonte Carlo Pi Estimation\r\nTiming and ArrayFire\r\nDebugging Code\r\n\r\n[custom_headline type=\"left\" level=\"h5\" accent=\"false\"]Day 3, Multi-GPU[/custom_headline] Lectures (customizable):\r\nMulti-GPU Use Cases\r\nMulti-GPUs: Contexts\r\nExisting Libraries\r\nScaling Across Multiple GPUs\r\n\r\nPractice:\r\nOut of Core Problems: Matrix Multiply\r\nTask Level Parallelism: Optimization\r\nArrayFire Multi-GPU[/column]\r\n\r\n[column type=\"one-half\" last=\"true\"] [custom_headline type=\"left\" level=\"h5\" accent=\"false\"]Day 2, Optimization[/custom_headline] Lectures:\r\nArchitecture: Grids, Blocks, and Threads\r\nMemory Model: Global, Shared, and Constant Memory\r\nAdvanced Mapping Techniques\r\nStreams: Asynchronos Launches and Concurrent Execution\r\nArrayFire: Lazy Evaluation and Code Vectorization\r\n\r\nPractice:\r\nMatrix Transpose\r\nOptimization Using Shared Memory\r\nMedian Filter\r\nOptimization Using Constant Memory\r\nStream Example\r\nArrayFire Example: Nearest Neighbor Algorithm\r\n\r\n[custom_headline type=\"left\" level=\"h5\" accent=\"false\"]Day 4, Algorithm Problems[/custom_headline]\r\n\r\nLectures and Practice (customizable):\r\nReductions\r\nScan Algorithms\r\nSort\r\nConvolution\r\nCustomer-Specific Problem\r\n\r\n[button type=\"flat\" shape=\"rounded\"  size=\"regular\" href=\"mailto:sales@arrayfire.com?Subject=Training%20Inquiry\"]Okay, <em>now </em>contact us about a training[/button][/column][/content_band]','Training','','publish','closed','closed','','training','','','2018-06-26 15:46:20','2018-06-26 19:46:20','',0,'http://sandbox.arrayfire.com/?page_id=6640',0,'page','',0),(6641,7,'2014-09-15 21:24:25','2014-09-15 21:24:25','<div>\r\n\r\n[content_band inner_container=\"true\" no_margin=\"true\" border=\"top\" padding_top=\"40px\" padding_bottom=\"40px\" ]\r\n\r\n[column type=\"one-half\"][custom_headline type=\"left\" level=\"h3\" ]Training[/custom_headline] Attendees will receive the latest industry knowledge and techniques for GPU computing in CUDA and OpenCL.\r\n\r\nArrayFire offers up to four days of specialized GPU training in CUDA and OpenCL programming. We provide customized on-site training courses for customers that have 3 or more attendees from their organization. We can travel to your location and provide a CUDA or OpenCL training course tailored to meet your application-specific needs. We also offer individual trainings at our Atlanta office. Please <a href=\"mailto:sales@arrayfire.com\">contact us</a> to learn more about our training offerings.\r\n\r\nWe recommend that attendees have a working knowledge of C/C++ in order to gain the most from the training courses. For more information about the content of our training lectures and hands-on practicums, please see the following training course syllabus.\r\n\r\n[/column]\r\n\r\n[column type=\"one-half\" last=\"true\" fade=\"true\" fade_animation=\"in-from-right\" class=\"center-text\"][gap size=\"15%\"][image src=\"http://sandbox.arrayfire.com/wp-content/uploads/2014/02/Professor-AF_Exported-e1395436350363.png\" ][/column]\r\n\r\n[column type=\"one-half\" class=\"center-text\"] [gap size=\"17%\"]\r\n<div>[button type=\"flat\" shape=\"rounded\" size=\"jumbo\" href=\"mailto:sales@arrayfire.com?Subject=Training%20Inquiry\"] Register for Training[/button]</div>\r\n[/column][column type=\"one-half\" last=\"true\"][custom_headline type=\"left\" level=\"h3\"]Included in Course[/custom_headline]\r\n\r\n[icon_list] [icon_list_item type=\"angle-double-right\"]Instruction by an excellent and interesting expert, with hands-on exercises[/icon_list_item] [icon_list_item type=\"angle-double-right\"]Use of a laptop with CUDA and OpenCL capable GPUs and CPUs [/icon_list_item] [icon_list_item type=\"angle-double-right\"]Choice of Linux or Windows operating system[/icon_list_item][icon_list_item type=\"angle-double-right\"]Printed manual of lecture material[/icon_list_item][icon_list_item type=\"angle-double-right\"]Electronic copy of programming exercises[/icon_list_item][/icon_list]\r\n\r\n[/column]\r\n\r\n[gap size=\"5%\"]\r\n\r\n[custom_headline type=\"left\" level=\"h3\"]Training Course Syllabus[/custom_headline] [column type=\"one-half\"] [custom_headline type=\"left\" level=\"h5\"  accent=\"false\"]Day 1, Introduction[/custom_headline] Lectures:\r\nGPU Computing Overview\r\nThe Programming Model\r\nBasic Dataset Mapping Techniques\r\nLibraries, ArrayFire\r\nProfiling Tools\r\n\r\nPractice:\r\nA Simple Kernel\r\nEquivalent ArrayFire Example\r\nUsing Libraries\r\nMonte Carlo Pi Estimation\r\nTiming and ArrayFire\r\nDebugging Code\r\n\r\n[custom_headline type=\"left\" level=\"h5\" accent=\"false\"]Day 3, Multi-GPU[/custom_headline] Lectures:\r\nMulti-GPU Use Cases\r\nMulti-GPUs: Contexts\r\nExisting Libraries\r\nScaling Across Multiple GPUs\r\n\r\nPractice:\r\nOut of Core Problems: Matrix Multiply\r\nTask Level Parallelism: Optimization\r\nArrayFire Multi-GPU[/column]\r\n\r\n[column type=\"one-half\" last=\"true\"] [custom_headline type=\"left\" level=\"h5\" accent=\"false\"]Day 2, Optimization[/custom_headline] Lectures:\r\nArchitecture: Grids, Blocks, and Threads\r\nMemory Model: Global, Shared, and Constant Memory\r\nAdvanced Mapping Techniques\r\nStreams: Asynchronos Launches and Concurrent Execution\r\nArrayFire: Lazy Evaluation and Code Vectorization\r\n\r\nPractice:\r\nMatrix Transpose\r\nOptimization Using Shared Memory\r\nMedian Filter\r\nOptimization Using Constant Memory\r\nStream Example\r\nArrayFire Example: Nearest Neighbor Algorithm\r\n\r\n[custom_headline type=\"left\" level=\"h5\" accent=\"false\"]Day 4, Algorithm Problems[/custom_headline]\r\n\r\nLectures and Practice:\r\nReductions\r\nScan Algorithms\r\nSort\r\nConvolution\r\nCustomer-Specific Problem [/column][/content_band]\r\n\r\n</div>','Training, OPSC','','inherit','open','open','','6640-revision-v1','','','2014-09-15 21:24:25','2014-09-15 21:24:25','',6640,'http://sandbox.arrayfire.com/6640-revision-v1/',0,'revision','',0),