From 864090eeaa5241f9fcf17420a3d0123c95052b96 Mon Sep 17 00:00:00 2001
From: Robert Ly Renderscript exposes a set of compute APIs that you can use to do intensive computational
-operations. You can use the compute APIs in the context of a graphics Renderscript such as
-calculating the positions of many objects in a scene. You can also create standalone compute
-Renderscripts such as one that does image processing for a photo editor application. Compute Renderscripts scale to the amount of
+ Renderscript offers a high performance computation API at the native
+level that you write in C (C99 standard). Renderscript gives your apps the ability to run
+operations with automatic parallelization across all available processor cores.
+It also supports different types of processors such as the CPU, GPU or DSP. Renderscript
+is useful for apps that do image processing, mathematical modeling, or any operations
+that require lots of mathematical computation. In addition, you have access to all of these features without having to write code to
+support different architectures or a different amount of processing cores. You also
+do not need to recompile your application for different processor types, because Renderscript
+code is compiled on the device at runtime. Deprecation Notice: Earlier versions of Renderscript included
+ an experimental graphics engine component. This component
+is now deprecated as of Android 4.1 (most of the APIs in The Renderscript runtime operates at the native level and still needs to communicate
+with the Android VM, so the way a Renderscript application is set up is different from a pure VM
+application. An application that uses Renderscript is still a traditional Android application that
+runs in the VM, but you write Renderscript code for the parts of your program that require
+it. No matter what you use it for, Renderscript remains platform
+independent, so you do not have to target multiple architectures (for example,
+ARM v5, ARM v7, x86). The Renderscript system adopts a control and slave architecture where the low-level Renderscript runtime
+code is controlled by the higher level Android system that runs in a virtual machine (VM). The
+Android VM still retains all control of memory management and binds memory that it allocates to
+the Renderscript runtime, so the Renderscript code can access it. The Android framework makes
+asynchronous calls to Renderscript, and the calls are placed in a message queue and processed
+as soon as possible. Figure 1 shows how the Renderscript system is structured. Figure 1. Renderscript system overview When using Renderscript, there are three layers of APIs that enable communication between the
+ Renderscript runtime and Android framework code: Because of the way Renderscript is structured, the main advantages are: The main disadvantages are: For a more detailed explanation of how all of these layers work together, see
+ Advanced Renderscript.
+
+
+ Renderscripts scale to the amount of
processing cores available on the device. This is enabled through a function named
Implementing a compute Renderscript creating a Implementing a Renderscript involves creating a Figure 1. Compute Renderscript overview Figure 1. Renderscript overview The following sections describe how to create a simple compute Renderscript and use it in an
+ The following sections describe how to create a simple Renderscript and use it in an
Android application. This example uses the HelloCompute Renderscript
sample that is provided in the SDK as a guide (some code has been modified from its original
form for simplicity). Your Renderscript code resides in rs_graphics.rsh
+and the corresponding APIs in {@link android.renderscript}).
+If you have apps that render graphics with Renderscript, we highly
+recommend you convert your code to another Android graphics rendering option.Renderscript System Overview
+
+
+
+
+
+
+
+
+
+
+Creating a Renderscript
+
+rsForEach()
(or the forEach_root()
method at the Android framework level).
that automatically partitions work across available processing cores on the device.
-For now, compute Renderscripts can only take advantage of CPU
+For now, Renderscript can only take advantage of CPU
cores, but in the future, they can potentially run on other types of processors such as GPUs and
DSPs.Creating a Compute Renderscript
-
-.rs
file that contains
+.rs
file that contains
your Renderscript code and calling it at the Android framework level with the
forEach_root()
or at the Renderscript runtime level with the
-rsForEach()
function. The following diagram describes how a typical compute
+rsForEach()
function. The following diagram describes how a typical
Renderscript is set up:
-
Creating the Renderscript file
+Creating the Renderscript file
.rs
and .rsh
files in the
-<project_root>/src/
directory. This code contains the compute logic
+<project_root>/src/
directory. This code contains the computation logic
and declares all necessary variables and pointers.
-Every compute .rs
file generally contains the following items:.rs
file generally contains the following items:
#pragma rs java_package_name(package.name)
)
@@ -74,13 +150,13 @@ Every compute .rs
file generally contains the following items:
#pragma version(1)
) that declares the version of
Renderscript that you are using (1 is the only value for now).root()
function that is the main worker function. The root function is
+ A root()
function that is the main worker function. The root function is
called by the rsForEach
function, which allows the Renderscript code to be called and
executed on multiple cores if they are available. The root()
function must return
- void
and accept the following arguments:
+ void
and accept the following arguments:
You can do Renderscript to Renderscript calls with rsForEach
in situations
-such as when a graphics Renderscript needs to do a lot of computational operations. The Renderscript
-Balls sample shows how
-this is setup. The balls.rs
-graphics Renderscript calls the balls_physics.rs
-compute Renderscript to calculate the location of the balls that are rendered to the screen.
Another way to use a compute Renderscript is to call it from your Android framework code by +
You can call the Renderscript from your Android framework code by
creating a Renderscript object by instantiating the (ScriptC_script_name
)
class. This class contains a method, forEach_root()
, that lets you invoke
rsForEach
. You give it the same parameters that you would if you were invoking it
at the Renderscript runtime level. This technique allows your Android application to offload
intensive mathematical calculations to Renderscript. See the HelloCompute sample to see
-how a simple Android application can utilize a compute Renderscript.
To call a compute Renderscript at the Android framework level:
+To call Renderscript at the Android framework level:
forEach_root()
, passing in the allocations, the
Renderscript, and any optional user-defined data. The output allocation will contain the output
- of the compute Renderscript.In the following example, taken from the The following example, taken from the HelloCompute sample, processes
a bitmap and outputs a black and white version of it. The
-createScript()
method carries out the steps described previously. This method the compute
+createScript()
method carries out the steps described previously. This method calls the
Renderscript, mono.rs
, passing in memory allocations that store the bitmap to be processed
as well as the eventual output bitmap. It then displays the processed bitmap onto the screen:
@@ -224,19 +291,17 @@ public class HelloCompute extends Activity { }-
To call a compute Renderscript from another Renderscript file:
+To call Renderscript from another Renderscript file:
rsForEach()
, passing in the allocations and any optional user-defined data.
- The output allocation will contain the output of the compute Renderscript.The following example, taken from the Renderscript -Balls sample, demonstrates how to do make a script to script call:
+rs_script script; rs_allocation in_allocation; @@ -245,9 +310,31 @@ UserData_t data; ... rsForEach(script, in_allocation, out_allocation, &data, sizeof(data));- +
In this example, assume that the script and memory allocations have already been
allocated and bound at the Android framework level and that UserData_t
is a struct
declared previously. Passing a pointer to a struct and the size of the struct to rsForEach
-is optional, but useful if your compute Renderscript requires additional information other than
+is optional, but useful if your Renderscript requires additional information other than
the necessary memory allocations.
You can define the floating point precision required by your compute algorithms. This is useful if you + require less precision than the IEEE 754-2008 standard (used by default). You can define +the floating-point precision level of your script with the following pragmas:
+ +#pragma rs_fp_full
(default if nothing is specified): For apps that
+ require floating point precision as outlined by the IEEE 754-2008 standard.
+#pragma rs_fp_relaxed
- For apps that donât require
+ strict IEEE 754-2008 compliance and can tolerate less precision. This mode enables
+ flush-to-zero for denorms and round-towards-zero.
+#pragma rs_fp_imprecise
- For apps that donât have stringent precision requirements. This mode enables
+ everything in rs_fp_relaxed
along with the following:
+Renderscript provides a platform-independent computation engine that operates at the native level. + Use it to accelerate your apps that require extensive computational horsepower.
+For ICS, Renderscript (RS) has been updated with several new features to simplify + adding compute acceleration to your application. RS is interesting for compute + acceleration when you have large buffers of data on which you need to do significant + processing. In this example we will look at applying a levels/saturation operation + on a bitmap.
+ + + +In Introducing Renderscript I gave a brief overview of this technology. + In this post Iâll look at "compute" in more detail. In Renderscript we use + "compute" to mean offloading of data processing from Dalvik code to + Renderscript code which may run on the same or different processor(s).
+ +