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.

1 comments:

Sean Lumly January 21, 2014 at 2:13 PM  

It will be interesting when you begin to do testing and compare performance to OpenCL (if possible), or even suggest optimization techniques you have tripped upon. Documentation still seems scarce for Renderscript over a year after it's official rollout.

Post a Comment

  © Blogger template Werd by Ourblogtemplates.com 2009

Back to TOP