From

Thank you

Sorry

RenderScript provides a framework for running high-performance, compute-intensive tasks on Google's Android mobile platform. Developed in 2009 by Jason Sams, RenderScript features a runtime to parallelize work across all processors on a device. Sams, now the technical lead for RenderScript, spoke about the technology at the recent Linley Tech Mobile Conference in Silicon Valley, where InfoWorld Editor-at-Large Paul Krill talked to him about RenderScript and its possibilities.

InfoWorld: What is the principal benefit of RenderScript?

Sams: The principal benefit is that we're making compute easier to use for application developers. We're really exposing RenderScript in a way that allows developers to take advantage of the various hardware on the device without the complexity that some of the other APIs present.

InfoWorld: How does that work?

Sams: [We have] intrinsics, they're really an on-ramp. Developers can start using them writing very little code, and they can see immediate performance benefits. Once they've done that, then they can migrate on and write more complex custom compute code. And even there, because we provide a framework [that] generates code to bind the compute code to their application for them, it reduces the amount of code they have to write. It really provides them with easier-to-use tools for developing compute applications.

InfoWorld: Are there any plans to move RenderScript to non-Android platforms?

Sams: We don't have any current plans to do that. However, the code is out there, and it would be easy for someone who wanted to do it to do exactly that.

InfoWorld: Would this provide the same benefits that you're providing on Android?

Sams: They would get the ease-of-use benefits. If they wanted hardware acceleration, it would have to have a driver for whatever platform that they were trying to port to.

InfoWorld: I understand RenderScript is especially useful for apps performing image processing, computation, photography, or computer vision. Are there a lot of applications like that for Android?

Sams: For Android there are quite a few. If you look at the Android market, a lot of the applications there, they're camera-based, they're imaging-based. For example, the new camera app we just released for Android uses RenderScript as part of its image processing.

InfoWorld: You mention issues in getting RenderScript supported on older devices. Are you getting around that problem?

Sams: What we did is we provide a compatibility library, and the application developer can bundle that with their application. That allows their application to run on older devices.

InfoWorld: How do the compatibility libraries work?

Sams: The way the compatibility library works is when the application is developed and they compile their kernels, we bundle both the shared library compiled from their kernel and our RenderScript bit code compiled from their kernel with the application, and they include a small RenderScript runtime with their application. This allows the application, if it's running on an old device, to load the precompiled shared-library version. If it's on a new device, it just ignores the shared-library package and uses the platform version of RenderScript. So that way, they can take advantage of all the new hardware features.

InfoWorld: Would RenderScript best be described as an API or framework, or framework with an API?

Sams: It's an Android framework and API. That's probably the best way to describe it.

InfoWorld: What is next for RenderScript? What version are you on now? What's the next version and what might be in that?

Sams: We don't have a specific version because we're tied to the platform version. Right now we're working on the next version of Android, and obviously there will be a RenderScript update with it

InfoWorld: You mentioned a new wave of Java developers is adopting compute. When you say compute, what specifically do you mean?

Sams: The reason we just say compute is we're processor-agnostic. What the developers really want is their code to run well. They don't really care where it runs. So we just call what most people call GPU compute, we just refer to it as compute. We're agnostic to the processor type. What we really mean by compute is the application developer can have a large amount of data they want to process as fast as they possibly can, and we provide the RenderScript framework for doing that where we'll automatically take advantage of however many CPU cores are on the device, or we'll take advantage of a GPU if it's there, and make sure whatever workflow they have can be done as efficiently or as fast as possible.