Android/frameworks_base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge "Update RenderScript API guide." into jb-mr2-dev

Browse Source
This commit is contained in:
Tim Murray
2013-06-05 20:45:00 +00:00
committed by Android (Google) Code Review
parent ea45ab6fbc 015d26837c
commit 47c892e5b0
4 changed files with 252 additions and 426 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/html/guide/guide_toc.cs
View File

@@ -326,11 +326,11 @@
</a></div>
<ul>
<li><a href="<?cs var:toroot ?>guide/topics/renderscript/compute.html">
<span class="en">Renderscript</span></a>
<span class="en">RenderScript</span></a>
</li>
<li><a href="<?cs var:toroot ?>guide/topics/renderscript/advanced.html">
<span class="en">Advanced Renderscript</span></a>
<span class="en">Advanced RenderScript</span></a>
</li>
<li><a href="<?cs var:toroot ?>guide/topics/renderscript/reference.html">
<span class="en">Runtime API Reference</span></a>

158
docs/html/guide/topics/renderscript/advanced.jd
View File

@@ -1,4 +1,4 @@
page.title=Advanced Renderscript
page.title=Advanced RenderScript
parent.title=Computation
parent.link=index.html
@@ -9,7 +9,7 @@ parent.link=index.html
<h2>In this document</h2>
<ol>
<li><a href="#native">Renderscript Runtime Layer</a></li>
<li><a href="#native">RenderScript Runtime Layer</a></li>
<li><a href="#reflected">Reflected Layer</a>
<ol>
<li><a href="#func">Functions</a></li>
@@ -25,7 +25,7 @@ parent.link=index.html
<li>
<a href="#memory">Working with Memory</a>
<ol>
<li><a href="#allocating-mem">Allocating and binding memory to the Renderscript</a></li>
<li><a href="#allocating-mem">Allocating and binding memory to the RenderScript</a></li>
<li><a href="#read-write">Reading and writing to memory</a></li>
@@ -37,36 +37,36 @@ parent.link=index.html
<p></p>
<p>Because applications that utilize Renderscript still run inside of the Android VM,
<p>Because applications that utilize RenderScript still run inside of the Android VM,
you have access to all of the framework APIs that you are familiar with, but can
utilize Renderscript when appropriate. To facilitate this interaction between
the framework and the Renderscript runtime, an intermediate layer of code is also
utilize RenderScript when appropriate. To facilitate this interaction between
the framework and the RenderScript runtime, an intermediate layer of code is also
present to facilitate communication and memory management between the two levels of code.
This document goes into more detail about these
different layers of code as well as how memory is shared between the Android VM and
Renderscript runtime.</p>
RenderScript runtime.</p>
<h2 id="native">Renderscript Runtime Layer</h2>
<h2 id="native">RenderScript Runtime Layer</h2>
<p>Your Renderscript code is compiled and
executed in a compact and well-defined runtime layer. The Renderscript runtime APIs offer support for
<p>Your RenderScript code is compiled and
executed in a compact and well-defined runtime layer. The RenderScript runtime APIs offer support for
intensive computation that is portable and automatically scalable to the
amount of cores available on a processor.
</p>
<p class="note"><strong>Note:</strong> The standard C functions in the NDK must be
guaranteed to run on a CPU, so Renderscript cannot access these libraries,
because Renderscript is designed to run on different types of processors.</p>
guaranteed to run on a CPU, so RenderScript cannot access these libraries,
because RenderScript is designed to run on different types of processors.</p>
<p>You define your Renderscript code in <code>.rs</code>
<p>You define your RenderScript code in <code>.rs</code>
and <code>.rsh</code> files in the <code>src/</code> directory of your Android project. The code
is compiled to intermediate bytecode by the
<code>llvm</code> compiler that runs as part of an Android build. When your application
runs on a device, the bytecode is then compiled (just-in-time) to machine code by another
<code>llvm</code> compiler that resides on the device. The machine code is optimized for the
device and also cached, so subsequent uses of the Renderscript enabled application does not
device and also cached, so subsequent uses of the RenderScript enabled application does not
recompile the bytecode.</p>
<p>Some key features of the Renderscript runtime libraries include:</p>
<p>Some key features of the RenderScript runtime libraries include:</p>
<ul>
@@ -79,20 +79,20 @@ amount of cores available on a processor.
<li>Conversion routines for primitive data types and vectors, matrix routines, and date and time
routines</li>
<li>Data types and structures to support the Renderscript system such as Vector types for
<li>Data types and structures to support the RenderScript system such as Vector types for
defining two-, three-, or four-vectors.</li>
<li>Logging functions</li>
</ul>
<p>See the Renderscript runtime API reference for more information on the available functions.
<p>See the RenderScript runtime API reference for more information on the available functions.
<h2 id="reflected">Reflected Layer</h2>
<p>The reflected layer is a set of classes that the Android build tools generate to allow access
to the Renderscript runtime from the Android framework. This layer also provides methods
to the RenderScript runtime from the Android framework. This layer also provides methods
and constructors that allow you to allocate and work with memory for pointers that are defined in
your Renderscript code. The following list describes the major
your RenderScript code. The following list describes the major
components that are reflected:</p>
<ul>
@@ -105,9 +105,9 @@ following items reflected from the <code>.rs</code> file:
<ul>
<li>Non-static functions</li>
<li>Non-static, global Renderscript variables. Accessor methods are generated for each
variable, so you can read and write the Renderscript variables from the Android
framework. If a global variable is initialized at the Renderscript runtime layer, those
<li>Non-static, global RenderScript variables. Accessor methods are generated for each
variable, so you can read and write the RenderScript variables from the Android
framework. If a global variable is initialized at the RenderScript runtime layer, those
values are used to initialize the corresponding values in the Android framework layer. If global
variables are marked as <code>const</code>, then a <code>set</code> method is not
generated.</p></li>
@@ -128,7 +128,7 @@ generated.</p></li>
<h3 id="func">Functions</h3>
<p>Functions are reflected into the script class itself, located in
<code>project_root/gen/package/name/ScriptC_renderscript_filename</code>. For
example, if you declare the following function in your Renderscript code:</p>
example, if you declare the following function in your RenderScript code:</p>
<pre>
void touch(float x, float y, float pressure, int id) {
@@ -155,14 +155,14 @@ public void invoke_touch(float x, float y, float pressure, int id) {
}
</pre>
<p>
Functions cannot have a return value, because the Renderscript system is designed to be
asynchronous. When your Android framework code calls into Renderscript, the call is queued and is
executed when possible. This restriction allows the Renderscript system to function without constant
Functions cannot have a return value, because the RenderScript system is designed to be
asynchronous. When your Android framework code calls into RenderScript, the call is queued and is
executed when possible. This restriction allows the RenderScript system to function without constant
interruption and increases efficiency. If functions were allowed to have return values, the call
would block until the value was returned.</p>
<p>
If you want the Renderscript code to send a value back to the Android framework, use the
If you want the RenderScript code to send a value back to the Android framework, use the
<a href="{@docRoot}reference/renderscript/rs__core_8rsh.html"><code>rsSendToClient()</code></a>
function.
</p>
@@ -172,7 +172,7 @@ function.
<p>Variables of supported types are reflected into the script class itself, located in
<code>project_root/gen/package/name/ScriptC_renderscript_filename</code>. A set of accessor
methods are generated for each variable. For example, if you declare the following variable in
your Renderscript code:</p>
your RenderScript code:</p>
<pre>uint32_t unsignedInteger = 1;</pre>
<p>then the following code is generated:</p>
@@ -329,7 +329,7 @@ public class ScriptField_Point extends android.renderscript.Script.FieldBase {
</pre>
<p>The generated code is provided to you as a convenience to allocate memory for structs requested
by the Renderscript runtime and to interact with <code>struct</code>s
by the RenderScript runtime and to interact with <code>struct</code>s
in memory. Each <code>struct</code>'s class defines the following methods and constructors:</p>
<ul>
@@ -356,11 +356,11 @@ in memory. Each <code>struct</code>'s class defines the following methods and co
</ul>
<p>You can specify multiple memory spaces by using the bitwise <code>OR</code> operator. Doing so
notifies the Renderscript runtime that you intend on accessing the data in the
notifies the RenderScript runtime that you intend on accessing the data in the
specified memory spaces. The following example allocates memory for a custom data type
in both the script and vertex memory spaces:</p>
<pre>
ScriptField_Point touchPoints = new ScriptField_Point(myRenderscript, 2,
ScriptField_Point touchPoints = new ScriptField_Point(myRenderScript, 2,
Allocation.USAGE_SCRIPT | Allocation.USAGE_GRAPHICS_VERTEX);
</pre>
</li>
@@ -370,13 +370,13 @@ in memory. Each <code>struct</code>'s class defines the following methods and co
with the <code>struct</code> in your Android code. When you are done manipulating the object,
you can push the object to the allocated memory by calling <code>set(Item i, int index,
boolean copyNow)</code> and setting the <code>Item</code> to the desired position in
the array. The Renderscript runtime automatically has access to the newly written memory.
the array. The RenderScript runtime automatically has access to the newly written memory.
<li>Accessor methods to get and set the values of each field in a struct. Each of these
accessor methods have an <code>index</code> parameter to specify the <code>struct</code> in
the array that you want to read or write to. Each setter method also has a
<code>copyNow</code> parameter that specifies whether or not to immediately sync this memory
to the Renderscript runtime. To sync any memory that has not been synced, call
to the RenderScript runtime. To sync any memory that has not been synced, call
<code>copyAll()</code>.</li>
<li>The <code>createElement()</code> method creates a description of the struct in memory. This
@@ -387,7 +387,7 @@ expand previously allocated memory, maintaining the current values that were pre
created.</li>
<li><code>copyAll()</code> synchronizes memory that was set on the framework level to the
Renderscript runtime. When you call a set accessor method on a member, there is an optional
RenderScript runtime. When you call a set accessor method on a member, there is an optional
<code>copyNow</code> boolean parameter that you can specify. Specifying
<code>true</code> synchronizes the memory when you call the method. If you specify false,
you can call <code>copyAll()</code> once, and it synchronizes memory for all the
@@ -397,7 +397,7 @@ properties that are not yet synchronized.</li>
<h3 id="pointer">Pointers</h3>
<p>Pointers are reflected into the script class itself, located in
<code>project_root/gen/package/name/ScriptC_renderscript_filename</code>. You
can declare pointers to a <code>struct</code> or any of the supported Renderscript types, but a
can declare pointers to a <code>struct</code> or any of the supported RenderScript types, but a
<code>struct</code> cannot contain pointers or nested arrays. For example, if you declare the
following pointers to a <code>struct</code> and <code>int32_t</code></p>
@@ -438,7 +438,7 @@ public Allocation get_intPointer() {
<p>A <code>get</code> method and a special method named <code>bind_<em>pointer_name</em></code>
(instead of a <code>set()</code> method) is generated. This method allows you to bind the memory
that is allocated in the Android VM to the Renderscript runtime (you cannot allocate
that is allocated in the Android VM to the RenderScript runtime (you cannot allocate
memory in your <code>.rs</code> file). For more information, see <a href="#memory">Working
with Allocated Memory</a>.
</p>
@@ -446,14 +446,14 @@ with Allocated Memory</a>.
<h2 id="mem-allocation">Memory Allocation APIs</h2>
<p>Applications that use Renderscript still run in the Android VM. The actual Renderscript code, however, runs natively and
<p>Applications that use RenderScript still run in the Android VM. The actual RenderScript code, however, runs natively and
needs access to the memory allocated in the Android VM. To accomplish this, you must
attach the memory that is allocated in the VM to the Renderscript runtime. This
process, called binding, allows the Renderscript runtime to seamlessly work with memory that it
attach the memory that is allocated in the VM to the RenderScript runtime. This
process, called binding, allows the RenderScript runtime to seamlessly work with memory that it
requests but cannot explicitly allocate. The end result is essentially the same as if you had
called <code>malloc</code> in C. The added benefit is that the Android VM can carry out garbage collection as well as
share memory with the Renderscript runtime layer. Binding is only necessary for dynamically allocated memory. Statically
allocated memory is automatically created for your Renderscript code at compile time. See <a href="#figure1">Figure 1</a>
share memory with the RenderScript runtime layer. Binding is only necessary for dynamically allocated memory. Statically
allocated memory is automatically created for your RenderScript code at compile time. See <a href="#figure1">Figure 1</a>
for more information on how memory allocation occurs.
</p>
@@ -479,11 +479,11 @@ understand how these classes work, it is useful to think of them in relation to
<p>In most situations, you do not need to call these memory allocation APIs directly. The reflected layer
classes generate code to use these APIs automatically and all you need to do to allocate memory is call a
constructor that is declared in one of the reflected layer classes and then bind
the resulting memory {@link android.renderscript.Allocation} to the Renderscript.
the resulting memory {@link android.renderscript.Allocation} to the RenderScript.
There are some situations where you would want to use these classes directly to allocate memory on your
own, such as loading a bitmap from a resource or when you want to allocate memory for pointers to
primitive types. You can see how to do this in the
<a href="#allocating-mem">Allocating and binding memory to the Renderscript</a> section.
<a href="#allocating-mem">Allocating and binding memory to the RenderScript</a> section.
The following table describes the three memory management classes in more detail:</p>
<table id="mem-mgmt-table">
@@ -500,12 +500,12 @@ understand how these classes work, it is useful to think of them in relation to
<p>An element describes one cell of a memory allocation and can have two forms: basic or
complex.</p>
<p>A basic element contains a single component of data of any valid Renderscript data type.
<p>A basic element contains a single component of data of any valid RenderScript data type.
Examples of basic element data types include a single <code>float</code> value, a <code>float4</code> vector, or a
single RGB-565 color.</p>
<p>Complex elements contain a list of basic elements and are created from
<code>struct</code>s that you declare in your Renderscript code. For instance an allocation
<code>struct</code>s that you declare in your RenderScript code. For instance an allocation
can contain multiple <code>struct</code>s arranged in order in memory. Each struct is considered as its
own element, rather than each data type within that struct.</p>
</td>
@@ -552,64 +552,64 @@ understand how these classes work, it is useful to think of them in relation to
<h2 id="memory">Working with Memory</h2>
<p>Non-static, global variables that you declare in your Renderscript are allocated memory at compile time.
You can work with these variables directly in your Renderscript code without having to allocate
<p>Non-static, global variables that you declare in your RenderScript are allocated memory at compile time.
You can work with these variables directly in your RenderScript code without having to allocate
memory for them at the Android framework level. The Android framework layer also has access to these variables
with the provided accessor methods that are generated in the reflected layer classes. If these variables are
initialized at the Renderscript runtime layer, those values are used to initialize the corresponding
initialized at the RenderScript runtime layer, those values are used to initialize the corresponding
values in the Android framework layer. If global variables are marked as const, then a <code>set</code> method is
not generated.</p>
<p class="note"><strong>Note:</strong> If you are using certain Renderscript structures that contain pointers, such as
<p class="note"><strong>Note:</strong> If you are using certain RenderScript structures that contain pointers, such as
<code>rs_program_fragment</code> and <code>rs_allocation</code>, you have to obtain an object of the
corresponding Android framework class first and then call the <code>set</code> method for that
structure to bind the memory to the Renderscript runtime. You cannot directly manipulate these structures
at the Renderscript runtime layer. This restriction is not applicable to user-defined structures
structure to bind the memory to the RenderScript runtime. You cannot directly manipulate these structures
at the RenderScript runtime layer. This restriction is not applicable to user-defined structures
that contain pointers, because they cannot be exported to a reflected layer class
in the first place. A compiler error is generated if you try to declare a non-static, global
struct that contains a pointer.
</p>
<p>Renderscript also has support for pointers, but you must explicitly allocate the memory in your
<p>RenderScript also has support for pointers, but you must explicitly allocate the memory in your
Android framework code. When you declare a global pointer in your <code>.rs</code> file, you
allocate memory through the appropriate reflected layer class and bind that memory to the native
Renderscript layer. You can interact with this memory from the Android framework layer as well as
the Renderscript layer, which offers you the flexibility to modify variables in the most
RenderScript layer. You can interact with this memory from the Android framework layer as well as
the RenderScript layer, which offers you the flexibility to modify variables in the most
appropriate layer.</p>
<h3 id="allocating-mem">Allocating and binding dynamic memory to the Renderscript</h3>
<h3 id="allocating-mem">Allocating and binding dynamic memory to the RenderScript</h3>
<p>To allocate dynamic memory, you need to call the constructor of a
{@link android.renderscript.Script.FieldBase} class, which is the most common way. An alternative is to create an
{@link android.renderscript.Allocation} manually, which is required for things such as primitive type pointers. You should
use a {@link android.renderscript.Script.FieldBase} class constructor whenever available for simplicity.
After obtaining a memory allocation, call the reflected <code>bind</code> method of the pointer to bind the allocated memory to the
Renderscript runtime.</p>
RenderScript runtime.</p>
<p>The example below allocates memory for both a primitive type pointer,
<code>intPointer</code>, and a pointer to a struct, <code>touchPoints</code>. It also binds the memory to the
Renderscript:</p>
RenderScript:</p>
<pre>
private RenderScript myRenderscript;
private RenderScript myRenderScript;
private ScriptC_example script;
private Resources resources;
public void init(RenderScript rs, Resources res) {
myRenderscript = rs;
myRenderScript = rs;
resources = res;
//allocate memory for the struct pointer, calling the constructor
ScriptField_Point touchPoints = new ScriptField_Point(myRenderscript, 2);
ScriptField_Point touchPoints = new ScriptField_Point(myRenderScript, 2);
//Create an element manually and allocate memory for the int pointer
intPointer = Allocation.createSized(myRenderscript, Element.I32(myRenderscript), 2);
intPointer = Allocation.createSized(myRenderScript, Element.I32(myRenderScript), 2);
//create an instance of the Renderscript, pointing it to the bytecode resource
mScript = new ScriptC_example(myRenderscript, resources, R.raw.example);
//create an instance of the RenderScript, pointing it to the bytecode resource
mScript = new ScriptC_example(myRenderScript, resources, R.raw.example);
//bind the struct and int pointers to the Renderscript
//bind the struct and int pointers to the RenderScript
mScript.bind_touchPoints(touchPoints);
script.bind_intPointer(intPointer);
@@ -618,29 +618,29 @@ public void init(RenderScript rs, Resources res) {
</pre>
<h3>Reading and writing to memory</h3>
<p>You can read and write to statically and dynamically allocated memory both at the Renderscript runtime
<p>You can read and write to statically and dynamically allocated memory both at the RenderScript runtime
and Android framework layer.</p>
<p>Statically allocated memory comes with a one-way communication restriction
at the Renderscript runtime level. When Renderscript code changes the value of a variable, it is not
at the RenderScript runtime level. When RenderScript code changes the value of a variable, it is not
communicated back to the Android framework layer for efficiency purposes. The last value
that is set from the Android framework is always returned during a call to a <code>get</code>
method. However, when Android framework code modifies a variable, that change can be communicated to
the Renderscript runtime automatically or synchronized at a later time. If you need to send data
from the Renderscript runtime to the Android framework layer, you can use the
the RenderScript runtime automatically or synchronized at a later time. If you need to send data
from the RenderScript runtime to the Android framework layer, you can use the
<a href="{@docRoot}reference/renderscript/rs__core_8rsh.html"><code>rsSendToClient()</code></a> function
to overcome this limitation.
</p>
<p>When working with dynamically allocated memory, any changes at the Renderscript runtime layer are propagated
<p>When working with dynamically allocated memory, any changes at the RenderScript runtime layer are propagated
back to the Android framework layer if you modified the memory allocation using its associated pointer.
Modifying an object at the Android framework layer immediately propagates that change back to the Renderscript
Modifying an object at the Android framework layer immediately propagates that change back to the RenderScript
runtime layer.</p>
<h4>Reading and writing to global variables</h4>
<p>Reading and writing to global variables is a straightforward process. You can use the accessor methods
at the Android framework level or set them directly in the Renderscript code. Keep in mind that any
changes that you make in your Renderscript code are not propagated back to the Android framework layer.</p>
at the Android framework level or set them directly in the RenderScript code. Keep in mind that any
changes that you make in your RenderScript code are not propagated back to the Android framework layer.</p>
<p>For example, given the following struct declared in a file named <code>rsfile.rs</code>:</p>
<pre>
@@ -659,8 +659,8 @@ point.x = 1;
point.y = 1;
</pre>
<p>You can assign values to the struct at the Android framework layer like this. These values are
propagated back to the Renderscript runtime level:</p>
<p>You can assign values to the struct at the Android framework layer like this. These values are
propagated back to the RenderScript runtime level:</p>
<pre>
ScriptC_rsfile mScript;
@@ -672,7 +672,7 @@ i.y = 1;
mScript.set_point(i);
</pre>
<p>You can read the values in your Renderscript code like this:</p>
<p>You can read the values in your RenderScript code like this:</p>
<pre>
rsDebug("Printing out a Point", point.x, point.y);
@@ -680,7 +680,7 @@ rsDebug("Printing out a Point", point.x, point.y);
<p>You can read the values in the Android framework layer with the following code. Keep in mind that this
code only returns a value if one was set at the Android framework level. You will get a null pointer
exception if you only set the value at the Renderscript runtime level:</p>
exception if you only set the value at the RenderScript runtime level:</p>
<pre>
Log.i("TAGNAME", "Printing out a Point: " + mScript.get_point().x + " " + mScript.get_point().y);
@@ -689,9 +689,9 @@ System.out.println(point.get_x() + " " + point.get_y());
<h4>Reading and writing global pointers</h4>
<p>Assuming that memory has been allocated in the Android framework level and bound to the Renderscript runtime,
<p>Assuming that memory has been allocated in the Android framework level and bound to the RenderScript runtime,
you can read and write memory from the Android framework level by using the <code>get</code> and <code>set</code> methods for that pointer.
In the Renderscript runtime layer, you can read and write to memory with pointers as normal and the changes are propagated
In the RenderScript runtime layer, you can read and write to memory with pointers as normal and the changes are propagated
back to the Android framework layer, unlike with statically allocated memory.</p>
<p>For example, given the following pointer to a <code>struct</code> in a file named <code>rsfile.rs</code>:</p>
@@ -726,5 +726,5 @@ ScriptField_Point p = new ScriptField_Point(mRS, 1);
points.get_x(0);
</pre>
<p>Once memory is already bound, you do not have to rebind the memory to the Renderscript
<p>Once memory is already bound, you do not have to rebind the memory to the RenderScript
runtime every time you make a change to a value.</p>

496
docs/html/guide/topics/renderscript/compute.jd
View File

@@ -1,4 +1,4 @@
page.title=Renderscript Computation
page.title=RenderScript
parent.title=Computation
parent.link=index.html
@@ -9,15 +9,8 @@ parent.link=index.html
<h2>In this document</h2>
<ol>
<li><a href="#overview">Renderscript System Overview</a></li>
<li><a href="#filterscript">Filterscript</a></li>
<li>
<a href="#creating-renderscript">Creating a Computation Renderscript</a>
<ol>
<li><a href="#creating-rs-file">Creating the Renderscript file</a></li>
<li><a href="#calling">Calling the Renderscript code</a></li>
</ol>
</li>
<li><a href="#writing-an-rs-kernel">Writing a RenderScript Kernel</a></li>
<li><a href="#using-rs-from-java">Using RenderScript from Java Code</a></li>
</ol>
<h2>Related Samples</h2>
@@ -29,371 +22,204 @@ parent.link=index.html
</div>
</div>
<p>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.</p>
<p>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.</p>
<p class="note"><strong>Deprecation Notice</strong>: 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 <code>rs_graphics.rsh</code>
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.</p>
<h2 id="overview">Renderscript System Overview</h2>
<p>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).</p>
<p>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.</p>
<img id="figure1" src="{@docRoot}images/rs_overview.png" />
<p class="img-caption"><strong>Figure 1.</strong> Renderscript system overview</p>
<p>When using Renderscript, there are three layers of APIs that enable communication between the
Renderscript runtime and Android framework code:</p>
<ul>
<li>The Renderscript runtime APIs allow you to do the computation
that is required by your application.</li>
<li>The reflected layer APIs are a set of classes that are reflected from your Renderscript
runtime code. It is basically a wrapper around the Renderscript code that allows the Android
framework to interact with the Renderscript runtime. The Android build tools automatically generate the
classes for this layer during the build process. These classes eliminate the need to write JNI glue
code, like with the NDK.</li>
<li>The Android framework layer calls the reflected layer to access the Renderscript
runtime.</li>
</ul>
<p>Because of the way Renderscript is structured, the main advantages are:</p>
<ul>
<li>Portability: Renderscript is designed to run on many types of devices with different
processor (CPU, GPU, and DSP for instance) architectures. It supports all of these architectures without
having to target each device, because the code is compiled and cached on the device
at runtime.</li>
<li>Performance: Renderscript provides a high performance computation API with seamless parallelization
across the amount of cores on the device.</li>
<li>Usability: Renderscript simplifies development when possible, such as eliminating JNI glue code.</li>
</ul>
<p>The main disadvantages are:</p>
<ul>
<li>Development complexity: Renderscript introduces a new set of APIs that you have to learn.</li>
<li>Debugging visibility: Renderscript can potentially execute (planned feature for later releases)
on processors other than the main CPU (such as the GPU), so if this occurs, debugging becomes more difficult.
</li>
</ul>
<p>For a more detailed explanation of how all of these layers work together, see
<a href="{@docRoot}guide/topics/renderscript/advanced.html">Advanced Renderscript</a>.<p>
<h2 id="filterscript">Filterscript</h2>
<p>Introduced in Android 4.2 (API Level 17), Filterscript defines a subset of Renderscript
that focuses on image processing operations, such as those
that you would typically write with an OpenGL ES fragment shader. You still write your scripts
using the standard Renderscript runtime APIs, but within stricter
constraints that ensure wider compatibility and improved optimization across
CPUs, GPUs, and DSPs. At compile time, the precompiler evaluates Filterscript files and
applies a more stringent set of warnings and errors than
it does for standard Renderscript files. The following list describes the major constraints
of Filterscript when compared to Renderscript:</p>
<p>RenderScript is a framework for running computationally intensive tasks at high performance on
Android. RenderScript is primarily oriented for use with data-parallel computation, although serial
computationally intensive workloads can benefit as well. The RenderScript runtime will parallelize
work across all processors available on a device, such as multi-core CPUs, GPUs, or DSPs, allowing
you to focus on expressing algorithms rather than scheduling work or load balancing. RenderScript is
especially useful for applications performing image processing, computational photography, or
computer vision.</p>
<p>To begin with RenderScript, there are two main concepts you should understand:</p>
<ul>
<li>Inputs and return values of root functions cannot contain pointers. The default root function
signature contains pointers, so you must use the <code>__attribute__((kernel))</code> attribute to declare a custom
root function when using Filterscript.</li>
<li>Built-in types cannot exceed 32-bits.</li>
<li>Filterscript must always use relaxed floating point precision by using the
<code>rs_fp_relaxed</code> pragma.</li>
<li>Filterscript files must end with an <code>.fs</code> extension, instead of an <code>.rs</code> extension.</li>
<li>High-performance compute kernels are written in a C99-derived language.</li>
<li>A Java API is used for managing the lifetime of RenderScript resources and controlling kernel
execution.</li>
</ul>
<h2 id="creating-renderscript">Creating a Renderscript</h2>
<h2 id="writing-an-rs-kernel">Writing a RenderScript Kernel</h2>
<p>Renderscript scales to the amount of
processing cores available on the device. This is enabled through a function named
<code>rsForEach()</code> (or the <code>forEach_root()</code> method at the Android framework level).
that automatically partitions work across available processing cores on the device.</p>
<p>Implementing a Renderscript involves creating a <code>.rs</code> file that contains
your Renderscript code and calling it at the Android framework level with the
<code>forEach_root()</code> or at the Renderscript runtime level with the
<code>rsForEach()</code> function. The following diagram describes how a typical
Renderscript is set up:</p><img src="{@docRoot}images/rs_compute.png">
<p class="img-caption"><strong>Figure 1.</strong> Renderscript overview</p>
<p>The following sections describe how to create a simple Renderscript and use it in an
Android application. This example uses the <a href=
"{@docRoot}resources/samples/RenderScript/HelloCompute/index.html">HelloCompute Renderscript
sample</a> that is provided in the SDK as a guide (some code has been modified from its original
form for simplicity).</p>
<h3 id="creating-rs-file">Creating the Renderscript file</h3>
<p>Your Renderscript code resides in <code>.rs</code> and <code>.rsh</code> files in the
<code>&lt;project_root&gt;/src/</code> directory. This code contains the computation logic
and declares all necessary variables and pointers.
Every <code>.rs</code> file generally contains the following items:</p>
<p>A RenderScript kernel typically resides in a <code>.rs</code> file in the
<code>&lt;project_root&gt;/src/</code> directory; each <code>.rs</code> file is called a
script. Every script contains its own set of kernels, functions, and variables. A script can
contain:</p>
<ul>
<li>A pragma declaration (<code>#pragma rs java_package_name(<em>package.name</em>)</code>)
that declares the package name of the <code>.java</code> reflection of this Renderscript.</li>
<li>A pragma declaration (<code>#pragma version(1)</code>) that declares the version of the
RenderScript kernel language used in this script. Currently, 1 is the only valid value.</li>
<li>A pragma declaration (<code>#pragma version(1)</code>) that declares the version of
Renderscript that you are using (1 is the only value for now).</li>
<li><p>A root function (or kernel) that is the main entry point to your Renderscript.
The default <code>root()</code> function must return
<code>void</code> and accept the following arguments:</p>
<li>A pragma declaration (<code>#pragma rs java_package_name(com.example.app)</code>) that
declares the package name of the Java classes reflected from this script.</li>
<ul>
<li>Pointers to memory allocations that are used for the input and output of the
Renderscript. Both of these pointers are required for Android 3.2 (API level 13) platform
versions or older. Android 4.0 (API level 14) and later requires one or both of these
allocations.</li>
</ul>
<li>Some number of invokable functions. An invokable function is a single-threaded RenderScript
function that you can call from your Java code with arbitrary arguments. These are often useful for
initial setup or serial computations within a larger processing pipeline.</li>
<p>The following arguments are optional, but both must be supplied if you choose to use
them:</p>
<li>Some number of script globals. A script global is equivalent to a global variable in C. You can
access script globals from Java code, and these are often used for parameter passing to RenderScript
kernels.</li>
<ul>
<li>A pointer for user-defined data that the Renderscript might need to carry out
computations in addition to the necessary allocations. This can be a pointer to a simple
primitive or a more complex struct.</li>
<li>Some number of compute kernels. A kernel is a parallel function that executes across every
{@link android.renderscript.Element} within an {@link android.renderscript.Allocation}.
<li>The size of the user-defined data.</li>
</ul>
<p>A simple kernel may look like the following:</p>
<p>Starting in Android 4.1 (API Level 16), you can choose to define your own root function arguments
without adhering to the default root function signature described previously. In addition,
you can declare multiple root functions in the same Renderscript. To do this, use the <code>__attribute__((kernel))</code>
attribute to define a custom root function. For example, here's a root function
that returns a <code>uchar4</code> and accepts two <code>uint32_t</code> types: </p>
<pre>uchar4 __attribute__((kernel)) invert(uchar4 in, uint32_t x, uint32_t y) {
uchar4 out = in;
out.r = 255 - in.r;
out.g = 255 - in.g;
out.b = 255 - in.b;
return out;
}</pre>
<pre>
uchar4 __attribute__((kernel)) root(uint32_t x, uint32_t y) {
...
}
</pre>
</li>
<p>In most respects, this is identical to a standard C function. The first notable feature is the
<code>__attribute__((kernel))</code> applied to the function prototype. This denotes that the
function is a RenderScript kernel instead of an invokable function. The next feature is the
<code>in</code> argument and its type. In a RenderScript kernel, this is a special argument that is
automatically filled in based on the input {@link android.renderscript.Allocation} passed to the
kernel launch. By default, the kernel is run across an entire {@link
android.renderscript.Allocation}, with one execution of the kernel body per {@link
android.renderscript.Element} in the {@link android.renderscript.Allocation}. The third notable
feature is the return type of the kernel. The value returned from the kernel is automatically
written to the appropriate location in the output {@link android.renderscript.Allocation}. The
RenderScript runtime checks to ensure that the {@link android.renderscript.Element} types of the
input and output Allocations match the kernel's prototype; if they do not match, an exception is
thrown.</p>
<li>An optional <code>init()</code> function. This allows you to do any initialization
before the root function runs, such as initializing variables. This
function runs once and is called automatically when the Renderscript starts, before anything
else in your Renderscript.</li>
<p>A kernel may have an input {@link android.renderscript.Allocation}, an output {@link
android.renderscript.Allocation}, or both. A kernel may not have more than one input or one output
{@link android.renderscript.Allocation}. If more than one input or output is required, those objects
should be bound to <code>rs_allocation</code> script globals and accessed from a kernel or invokable
function via <code>rsGetElementAt_<em>type</em>()</code> or
<code>rsSetElementAt_<em>type</em>()</code>.</p>
<li>Any variables, pointers, and structures that you wish to use in your Renderscript code (can
be declared in <code>.rsh</code> files if desired)</li>
</ul>
<p>A kernel may access the coordinates of the current execution using the <code>x</code>,
<code>y</code>, and <code>z</code> arguments. These arguments are optional, but the type of the
coordinate arguments must be <code>uint32_t</code>.</p></li>
<p>The following code shows how the <a href=
"{@docRoot}resources/samples/RenderScript/HelloCompute/src/com/example/android/rs/hellocompute/mono.html">
mono.rs</a> file is implemented:</p>
<pre>
#pragma version(1)
#pragma rs java_package_name(com.example.android.rs.hellocompute)
<li>An optional <code>init()</code> function. An <code>init()</code> function is a special type of
invokable function that is run when the script is first instantiated. This allows for some
computation to occur automatically at script creation.</li>
//multipliers to convert a RGB colors to black and white
const static float3 gMonoMult = {0.299f, 0.587f, 0.114f};
void root(const uchar4 *v_in, uchar4 *v_out) {
//unpack a color to a float4
float4 f4 = rsUnpackColor8888(*v_in);
//take the dot product of the color and the multiplier
float3 mono = dot(f4.rgb, gMonoMult);
//repack the float to a color
*v_out = rsPackColorTo8888(mono);
}
</pre>
<li>Some number of static script globals and functions. A static script global is equivalent to a
script global except that it cannot be set from Java code. A static function is a standard C
function that can be called from any kernel or invokable function in the script but is not exposed
to the Java API. If a script global or function does not need to be called from Java code, it is
highly recommended that those be declared <code>static</code>.</li> </ul>
<h4>Setting floating point precision</h4>
<p>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:</p>
<p>You can control the required level of floating point precision in a script. This is useful if
full IEEE 754-2008 standard (used by default) is not required. The following pragmas can set a
different level of floating point precision:</p>
<ul>
<li><code>#pragma rs_fp_full</code> (default if nothing is specified): For apps that
require floating point precision as outlined by the IEEE 754-2008 standard.
<li><code>#pragma rs_fp_full</code> (default if nothing is specified): For apps that require
floating point precision as outlined by the IEEE 754-2008 standard.
</li>
<li><code>#pragma rs_fp_relaxed</code> - 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.
<li><code>#pragma rs_fp_relaxed</code> - 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.
</li>
<li><code>#pragma rs_fp_imprecise</code> - For apps that don’t have stringent precision requirements. This mode enables
everything in <code>rs_fp_relaxed</code> along with the following:
<li><code>#pragma rs_fp_imprecise</code> - For apps that don’t have stringent precision
requirements. This mode enables everything in <code>rs_fp_relaxed</code> along with the
following:
<ul>
<li>Operations resulting in -0.0 can return +0.0 instead.</li>
<li>Operations on INF and NAN are undefined.</li>
</ul>
</li>
</ul>
<h4>Script intrinsics</h4>
<p>Renderscript adds support for a set of script intrinsics, which are pre-implemented
filtering primitives that reduce the amount of
code that you need to write. They also are implemented to ensure that your app gets the
maximum performance gain possible.</p>
<p>Most applications can use <code>rs_fp_relaxed</code> without any side effects. This may be very
beneficial on some architectures due to additional optimizations only available with relaxed
precision (such as SIMD CPU instructions).</p>
<h2 id="using-rs-from-java">Using RenderScript from Java Code</h2>
<p>Using RenderScript from Java code relies on the {@link android.renderscript} APIs. Most
applications follow the same basic usage patterns:</p>
<ol>
<li><strong>Initialize a RenderScript context.</strong> The {@link
android.renderscript.RenderScript} context, created with {@link
android.renderscript.RenderScript#create}, ensures that RenderScript can be used and provides an
object to control the lifetime of all subsequent RenderScript objects. You should consider context
creation to be a potentially long-running operation, since it may create resources on different
pieces of hardware; it should not be in an application's critical path if at all
possible. Typically, an application will have only a single RenderScript context at a time.</li>
<li><strong>Create at least one {@link android.renderscript.Allocation} to be passed to a
script.</strong> An {@link android.renderscript.Allocation} is a RenderScript object that provides
storage for a fixed amount of data. Kernels in scripts take {@link android.renderscript.Allocation}
objects as their input and output, and {@link android.renderscript.Allocation} objects can be
accessed in kernels using <code>rsGetElementAt_<em>type</em>()</code> and
<code>rsSetElementAt_<em>type</em>()</code> when bound as script globals. {@link
android.renderscript.Allocation} objects allow arrays to be passed from Java code to RenderScript
code and vice-versa. {@link android.renderscript.Allocation} objects are typically created using
{@link android.renderscript.Allocation#createTyped} or {@link
android.renderscript.Allocation#createFromBitmap}.</li>
<li><strong>Create whatever scripts are necessary.</strong> There are two types of scripts available
to you when using RenderScript:
<p>
Intrinsics are available for the following:
<ul>
<li>{@link android.renderscript.ScriptIntrinsicBlend Blends}</li>
<li>{@link android.renderscript.ScriptIntrinsicBlur Blur}</li>
<li>{@link android.renderscript.ScriptIntrinsicColorMatrix Color matrix}</li>
<li>{@link android.renderscript.ScriptIntrinsicConvolve3x3 3x3 convolve}</li>
<li>{@link android.renderscript.ScriptIntrinsicConvolve5x5 5x5 convolve}</li>
<li>{@link android.renderscript.ScriptIntrinsicLUT Per-channel lookup table}</li>
<li>{@link android.renderscript.ScriptIntrinsicYuvToRGB Converting an Android YUV buffer to RGB}</li>
</ul>
<h3 id="calling">Calling the Renderscript code</h3>
<li><strong>ScriptC</strong>: These are the user-defined scripts as described in <a
href="#writing-an-rs-kernel">Writing a RenderScript Kernel</a> above. Every script has a Java class
reflected by the RenderScript compiler in order to make it easy to access the script from Java code;
this class will have the name <code>ScriptC_<em>filename</em></code>. For example, if the kernel
above was located in <code>invert.rs</code> and a RenderScript context was already located in
<code>mRS</code>, the Java code to instantiate the script would be:
<p>You can call the Renderscript from your Android framework code by
creating a Renderscript object by instantiating the (<code>ScriptC_<em>script_name</em></code>)
class. This class contains a method, <code>forEach_root()</code>, that lets you invoke
<code>rsForEach</code>. 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 <a href=
"{@docRoot}resources/samples/RenderScript/HelloCompute/index.html">HelloCompute</a> sample to see
how a simple Android application can utilize Renderscript.</p>
<pre>ScriptC_invert invert = new ScriptC_invert(mRenderScript);</pre></li>
<p>To call Renderscript at the Android framework level:</p>
<li><strong>ScriptIntrinsic</strong>: These are built-in RenderScript kernels for common operations,
such as Gaussian blur, convolution, and image blending. For more information, see the subclasses of
{@link android.renderscript.ScriptIntrinsic}.</li>
<ol>
<li>Allocate memory that is needed by the Renderscript in your Android framework code.
You need an input and output {@link android.renderscript.Allocation} for Android 3.2 (API level
13) platform versions and older. The Android 4.0 (API level 14) platform version requires only
one or both {@link android.renderscript.Allocation}s.</li>
</ul></li>
<li>Create an instance of the <code>ScriptC_<em>script_name</em></code> class.</li>
<li><strong>Populate Allocations with data.</strong> Except for Allocations created with {@link
android.renderscript#createFromBitmap}, an Allocation will be populated with empty data when it is
first created. To populate an Allocation, use one of the <code>copy</code> methods in {@link
android.renderscript.Allocation}.</li>
<li>Call <code>forEach_root()</code>, passing in the allocations, the
Renderscript, and any optional user-defined data. The output allocation will contain the output
of the Renderscript.</li>
</ol>
<li><strong>Set any necessary script globals.</strong> Globals may be set using methods in the same
<code>ScriptC_<em>filename</em></code> class with methods named
<code>set_<em>globalname</em></code>. For example, in order to set an <code>int</code> named
<code>elements</code>, use the Java method <code>set_elements(int)</code>. RenderScript objects can
also be set in kernels; for example, the <code>rs_allocation</code> variable named
<code>lookup</code> can be set with the method <code>set_lookup(Allocation)</code>.</li>
<p>The following example, taken from the <a href=
"{@docRoot}resources/samples/RenderScript/HelloCompute/index.html">HelloCompute</a> sample, processes
a bitmap and outputs a black and white version of it. The
<code>createScript()</code> method carries out the steps described previously. This method calls the
Renderscript, <code>mono.rs</code>, 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:</p>
<pre>
package com.example.android.rs.hellocompute;
<li><strong>Launch the appropriate kernels.</strong> Methods to launch a given kernel will be
reflected in the same <code>ScriptC_<em>filename</em></code> class with methods named
<code>forEach_<em>kernelname</em>()</code>. These launches are asynchronous, and launches will be
serialized in the order in which they are launched. Depending on the arguments to the kernel, the
method will take either one or two Allocations. By default, a kernel will execute over the entire
input or output Allocation; to execute over a subset of that Allocation, pass an appropriate {@link
android.renderscript.Script.LaunchOptions} as the last argument to the <code>forEach</code> method.
import android.app.Activity;
import android.os.Bundle;
import android.graphics.BitmapFactory;
import android.graphics.Bitmap;
import android.renderscript.RenderScript;
import android.renderscript.Allocation;
import android.widget.ImageView;
<p>Invoked functions can be launched using the <code>invoke_<em>functionname</em></code> methods
reflected in the same <code>ScriptC_<em>filename</em></code> class.</p></li>
public class HelloCompute extends Activity {
private Bitmap mBitmapIn;
private Bitmap mBitmapOut;
<li><strong>Copy data out of {@link android.renderscript.Allocation} objects.</strong> In order to
access data from an {@link android.renderscript.Allocation} from Java code, that data must be copied
back to Java buffers using one of the <code>copy</code> methods in {@link
android.renderscript.Allocation}. These functions will synchronize with asynchronous kernel and
function launches as necessary.</li>
private RenderScript mRS;
private Allocation mInAllocation;
private Allocation mOutAllocation;
private ScriptC_mono mScript;
&#064;Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
mBitmapIn = loadBitmap(R.drawable.data);
mBitmapOut = Bitmap.createBitmap(mBitmapIn.getWidth(), mBitmapIn.getHeight(),
mBitmapIn.getConfig());
ImageView in = (ImageView) findViewById(R.id.displayin);
in.setImageBitmap(mBitmapIn);
ImageView out = (ImageView) findViewById(R.id.displayout);
out.setImageBitmap(mBitmapOut);
createScript();
}
private void createScript() {
mRS = RenderScript.create(this);
mInAllocation = Allocation.createFromBitmap(mRS, mBitmapIn,
Allocation.MipmapControl.MIPMAP_NONE,
Allocation.USAGE_SCRIPT);
mOutAllocation = Allocation.createTyped(mRS, mInAllocation.getType());
mScript = new ScriptC_mono(mRS, getResources(), R.raw.mono);
mScript.forEach_root(mInAllocation, mOutAllocation);
mOutAllocation.copyTo(mBitmapOut);
}
private Bitmap loadBitmap(int resource) {
final BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Bitmap.Config.ARGB_8888;
return BitmapFactory.decodeResource(getResources(), resource, options);
}
}
</pre>
<p>To call Renderscript from another Renderscript file:</p>
<ol>
<li>Allocate memory that is needed by the Renderscript in your Android framework code.
You need an input and output {@link android.renderscript.Allocation} for Android 3.2 (API level
13) platform versions and older. The Android 4.0 (API level 14) platform version requires only
one or both {@link android.renderscript.Allocation}s.</li>
<li>Call <code>rsForEach()</code>, passing in the allocations and any optional user-defined data.
The output allocation will contain the output of the Renderscript.</li>
</ol>
<pre>
rs_script script;
rs_allocation in_allocation;
rs_allocation out_allocation;
UserData_t data;
...
rsForEach(script, in_allocation, out_allocation, &amp;data, sizeof(data));
</pre>
</p>
<p>In this example, assume that the script and memory allocations have already been
allocated and bound at the Android framework level and that <code>UserData_t</code> is a struct
declared previously. Passing a pointer to a struct and the size of the struct to <code>rsForEach</code>
is optional, but useful if your Renderscript requires additional information other than
the necessary memory allocations.</p>
<h4>Script groups</h4>
<p>You can group Renderscript scripts together and execute them all with a single call as though
they were part of a single script. This allows Renderscript to optimize execution of the scripts
in ways that it could not do if the scripts were executed individually.</p>
<p>To build a script groupm, use the {@link android.renderscript.ScriptGroup.Builder} class to create a {@link android.renderscript.ScriptGroup}
defining the operations. At execution time, Renderscript optimizes the run order and the connections between these
operations for best performance.
<p class="note"><strong>Important:</strong> The script group must be a direct acyclic graph for this feature to work.</p>
<li><strong>Tear down the RenderScript context.</strong> The RenderScript context can be destroyed
with {@link android.renderscript.RenderScript#destroy} or by allowing the RenderScript context
object to be garbage collected. This will cause any further use of any object belonging to that
context to throw an exception.</li> </ol>

20
docs/html/guide/topics/renderscript/index.jd
View File

@@ -1,6 +1,6 @@
page.title=Computation
page.landing=true
page.landing.intro=Renderscript provides a platform-independent computation engine that operates at the native level. Use it to accelerate your apps that require extensive computational horsepower.
page.landing.intro=RenderScript provides a platform-independent computation engine that operates at the native level. Use it to accelerate your apps that require extensive computational horsepower.
page.landing.image=
@jd:body
@@ -12,16 +12,16 @@ page.landing.image=
<a
href="http://android-developers.blogspot.com/2013/01/evolution-of-renderscript-performance.html">
<h4>Evolution of Renderscript Performance</h4>
<p>It’s been a year since the last blog post on Renderscript, and with the release
<h4>Evolution of RenderScript Performance</h4>
<p>It’s been a year since the last blog post on RenderScript, and with the release
of Android 4.2, it’s a good time to talk about the performance work that we’ve done
since then. One of the major goals of this past year was to improve the performance
of common image-processing operations with Renderscript.</p> </a>
of common image-processing operations with RenderScript.</p> </a>
<a
href="http://android-developers.blogspot.com/2012/01/levels-in-renderscript.html">
<h4>Levels in Renderscript</h4>
<p>For ICS, Renderscript (RS) has been updated with several new features to simplify
<h4>Levels in RenderScript</h4>
<p>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
@@ -30,11 +30,11 @@ href="http://android-developers.blogspot.com/2012/01/levels-in-renderscript.html
<a
href="http://android-developers.blogspot.com/2011/03/renderscript.html">
<h4>Renderscript Part 2</h4>
<p>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
<h4>RenderScript Part 2</h4>
<p>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).</p>
RenderScript code which may run on the same or different processor(s).</p>
</a>
</div>