SYCL and Other Announcements

>> Sunday, March 23, 2014

The Game Developers Conference took place last week and there were many announcements related to OpenCL. For one thing, the WebCL 1.0 standard has been released. The page says that "Security is top priority" but I haven't seen any tools or programming constructs that prevent kernels from locking up the GPU. And it doesn't look like WebGL-WebCL interoperability is a significant concern. Ah well.

The GDC announcement that I found especially interesting involves a new programming layer called SYCL. According to its Khronos page, the goal is to make OpenCL and SPIR accessible through C++. I thought Benedict Gaster did a fine job with his cl.hpp wrapper, but I look forward to using the new SYCL API.

The SYCL effort is led by CodePlay, whose CEO, Andrew Richards, discussed OpenCL in an interview I mentioned in a previous post. He appreciates the importance of OpenCL-OpenGL interoperability, and if SYCL can simplify the coding process, that will be a wonderful thing. The FAQ for SYCL is here, but it doesn't answer the burning question: What does SYCL stand for? If you're going to make up a *CL acronym, why use four letters instead of three?


Chromium and WebCL

>> Sunday, March 16, 2014

Some time ago, I was very interested in using Google's Native Client to enable OpenCL processing in Chrome. As it turns out, the Native Client doesn't allow that sort of thing, but AMD hasn't given up. They've added WebCL to Google's Chromium project, which is the open-source version of Chrome.

AMD has made the source code for Chromium-WebCL available here. I've downloaded it and I'll give it my full attention when the time presents itself.


Book News

>> Wednesday, February 12, 2014

A coworker pointed out that two of my book's examples don't work properly: device_ext_test and buffer_check. After testing both on my Linux/AMD system, I was forced to agree. So I fixed the code and sent the updated zip files to the publisher.

The device_ext_test application fails because of clGetDeviceIDs. This doesn't seem to work properly when you want to determine how many devices are present. To be specific, the following line of code causes the error:

clGetDeviceIDs(platform, CL_DEVICE_TYPE_ALL, 1, NULL, &num_devices);

When this executes, it returns CL_INVALID_VALUE. I have no idea why this is, but I removed the call to clGetDeviceIDs and the error disappears.

My second error is more interesting. buffer_check fails because of the call to clCreateSubBuffer. My original code set the sub-buffer's origin to 120. This isn't an aligned memory address, and when I wrote the application, alignment wasn't a concern. But now my call to clCreateSubBuffer produces CL_MISALIGNED_SUB_BUFFER_OFFSET, a new error that was introduced in OpenCL 1.2. To clear this, I set the origin to 0x100. Now all is well.

In other news, Manning has made my book the Deal of the Day for February 13. Woo-hoo! That Oculus Rift book looks pretty incredible as well...


RenderScript and OpenCL

>> Monday, January 20, 2014

I decided it was time to learn RenderScript, so I spent the weekend reading through documentation and testing code on my Galaxy S4. For those unfamiliar, a RenderScript project requires at least three files:

  • a native file (*.rs) containing high-performance C code
  • a Java file automatically generated from the *.rs file
  • a Java file that calls the methods in the generated file
This is complicated, but RenderScript is much easier to deal with than the Java Native Interface.

Code in a *.rs file can operate on scalar and vector types and can call functions like dot, sin, and ilogb. The functions are declared in RenderScript headers (*.rsh) and one of the most prominent headers is rs_cl.rsh.

Looking through rs_cl.rsh, I was surprised by how similar its functions are to OpenCL's kernel functions. That's when it dawned on me—the 'cl' in rs_cl.rsh refers to OpenCL. So RenderScript isn't really competing with OpenCL. RenderScript is a Java layer on top of OpenCL's kernel API.

As I investigated further, the parallels between the two languages became more apparent. RenderScript's Allocations serve the same role as OpenCL's memory objects. In OpenCL, work-items have identifiers with one, two, or three dimensions. In RenderScript, kernels access similar dimensions as function parameters.

Of course, RenderScript differs from OpenCL in many respects. RenderScript doesn't let you choose the target device and each kernel can only access one or two Allocations (memory objects). Also, developers can't specify the usage of global, local, or private memory.


OpenCL Disabled on Android

>> Saturday, August 10, 2013

Alas, Rahul Garg's assessment of OpenCL on Android is accurate. As of version 4.3, Android devices do not allow OpenCL kernels to be compiled. I've verified this on the Nexus 10, but I can't speak for other devices.

Google has tolerated OpenCL in the past, but as of version 4.3, they've put their foot down. For high-performance computing on Android devices, Renderscript Compute is now the only option.

ETA: Vincent Hindriksen has an excellent write-up on the topic here. I agree wholeheartedly.


Article on Missing Libraries

I submitted this post without fully examining OpenCL on the Android. Please see the next post.

I have a high opinion of Rahul Garg, but his article conflicts with my experience. I just installed the 4.3 factory image for the Nexus 10, and using adb, I verified that was still in the system/vendor/lib/egl directory. When I launched my OpenCL testing app, it told me the GPU supports OpenCL 1.1. For the Nexus 10 at least, it appears that OpenCL development is still available.

I don't own a Nexus 7, so I can't answer as to whether its libraries are still available or not.



>> Saturday, July 27, 2013

I received an e-mail pointing out that the links to my old articles are broken. In response, I've transplanted three articles to

Outside of codeproject, here are two OpenCL articles of note:


  © Blogger template Werd by 2009

Back to TOP