1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510
|
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
<!ENTITY % version-entities SYSTEM "version.entities">
%version-entities;
<!ENTITY % local.common.attrib "xmlns:xi CDATA #FIXED 'http://www.w3.org/2003/XInclude'">
]>
<refentry id="orc-tutorial" revision="29 may 2009">
<refmeta>
<refentrytitle>Orc Tutorial</refentrytitle>
<manvolnum>3</manvolnum>
<refmiscinfo>Orc</refmiscinfo>
</refmeta>
<refnamediv>
<refname>Orc Tutorial</refname>
<refpurpose>
Getting started writing Orc code.
</refpurpose>
</refnamediv>
<refsect1>
<title>Orc Tutorial</title>
<para>
This section walks you through several examples of increasing
complexity to get you started working with Orc. Each of these
examples are available in the Orc source code, in the examples
directory. The first three examples use static Orc code that
is in a source file, and is compiled into intermediate C code
by the orcc tool.
</para>
<para>
The first example demonstrates how to add two arrays of 16-bit
signed integers together. A possible use case for this is
combining two stereo audio streams together.
</para>
<para>
The second example builds from the first, replacing one of the
stereo input streams with a mono stream, converting it to stereo
in the process, and also adjusting the volume of the stream.
</para>
<para>
The third example shows how to convert a planar 4:2:0 video
image into a packed 4:4:4 video image with an alpha channel.
</para>
</refsect1>
<refsect1>
<title>Example 1</title>
<para>
This example demonstrates combining two stereo audio streams
by adding. Uncompressed audio streams (i.e., PCM format) can
be in a variety of formats, but one of the most common is
interleaved signed 16-bit integers, and we will choose that
for the purposes of this example. Extending to other formats
is left as an exercise for the reader. Interleaved means that
left and right channel samples are consecutive: in memory, the
data look like LRLRLR... The sampling rate is unimportant, as
long as both streams are the same.
</para>
<para>
One important feature/limitation of signed 16-bit audio samples
is that adding two together could cause an overflow. For example,
adding the value 25000 to 10000 gives 35000, but this overflows
16 bits, so a standard addition would instead give the value
-30536 (35000-65536). Overflows handled this way sound like
crackling or worse, so we would like a better solution. One
solution is to use saturating addition: in this case, the addition
of 25000 and 10000 would be limited by the upper end of signed
16-bit values to give 32767. Although this still causes
distortion in the output signal, it is much less audible and
annoying.
</para>
<para>
In normal C code, 16-bit saturating addition is difficult to express
without using 32-bit intermediates. In Orc, saturating addition
is a basic operation with opcodes for each size, both signed and
unsigned. In this case, we want "addssw", for "add signed saturated
word".
</para>
<para>
Also, we're going to make a one simplification: Adding two
interleaved stereo streams is the same as adding two mono streams
with twice as many samples. So we'll use 2*n_samples in the calling
code.
</para>
<para>
To the code:
<programlisting>
.function audio_add_s16
.dest 2 d1
.source 2 s1
.source 2 s2
addssw d1, s1, s2
</programlisting>
</para>
<para>
Line by line:
<programlisting>
.function audio_add_s16
</programlisting>
This starts a function. A function (represented internally by the
object OrcProgram) is equivalent to a C function. When you generate
C code from this Orc exmaple using the orcc tool, it generates a C
stub function called "audio_add_s16()", which at runtime will
generate an OrcProgram object corresponding to the above code,
compile it, and then run it.
<programlisting>
.dest 2 d1 short
</programlisting>
This specifies that you want a destination (output) array named "d1",
with the element size being 2. Orc does not differentiate between
signed and unsigned arrays (or even floating point), however, you
may optionally specify a type afterwards that will be used in any
autogenerated C code.
<programlisting>
.source 2 s1 short
.source 2 s2 short
</programlisting>
This specifies that you want two source (input) arrays, "s1" and "s2",
similar to the destination array.
<programlisting>
addssw d1, s1, s2
</programlisting>
This specifies the (only) opcode that we want for this program: signed
saturated addition of each member of the two source arrays, and store
the result in the destination array.
</para>
<para>
A few notes about the above program: The loop over the array members
is implied. Everything that Orc does is based on looping over each
array element and executing the opcodes in a program.
</para>
<para>
When you generate C code from the above Orc code using
'orcc --implementation example1.orc',
you get a bunch of boilerplate code, plus three C functions:
<programlisting>
/* audio_add_s16 */
#ifdef DISABLE_ORC
void
audio_add_s16 (int16 * d1, const int16 * s1, const int16 * s2, int n)
{
...
}
</programlisting>
This function is used if DISABLE_ORC is defined. As one might guess,
if you define DISABLE_ORC, no runtime Orc features are used, and all
calls to audio_add_s16() use this function. The interior of the function
is a for() loop that implements the Orc function. The generated code
may not necessarily be easy to read, but it is straightforward: all
the verbosity and use of unions is to avoid compiler warnings without
making the compiler too complex. But this is the place to go if you
are trying to understand what Orc is doing.
<programlisting>
#else
static void
_backup_audio_add_s16 (OrcExecutor * ORC_RESTRICT ex)
{
...
}
</programlisting>
This function is used when runtime Orc is enabled, but Orc was unable
to generate code for the function at runtime. There are various
reasons why that might happen -- unimplemented rules for a target, or
more temporary variables used than available registers.
<programlisting>
void
audio_add_s16 (short * d1, const short * s1, const short * s2, int n)
{
...
}
</programlisting>
The third generated function is the important part: It is used when
Orc is enabled at runtime, and creates the OrcProgram corresponding
to the function you defined. Then it compiles the function and
calls it.
</para>
<para>
After generating the C code, you should generate the header file,
using: 'orcc --header example1orc.orc -o example1orc.h'.
After similar boilerplate code, there is the expected declaration
of audio_add_s16():
<programlisting>
void audio_add_s16 (short * d1, const short * s1, const short * s2, int n);
</programlisting>
</para>
<para>
Some C code to generate sample data, call the generated code, and
print out the results:
<programlisting>
#include <stdio.h>
#include "example1orc.h"
#define N 10
short a[N];
short b[N];
short c[N];
int
main (int argc, char *argv[])
{
int i;
/* Create some data in the source arrays */
for(i=0;i < N;i++){
a[i] = 100*i;
b[i] = 32000;
}
/* Call a function that uses Orc */
audio_add_s16 (c, a, b, N);
/* Print the results */
for(i=0;i < N;i++){
printf("%d: %d %d -> %d\n", i, a[i], b[i], c[i]);
}
return 0;
}
</programlisting>
</para>
<para>
The output of the program:
<programlisting>
0: 0 32000 -> 32000
1: 100 32000 -> 32100
2: 200 32000 -> 32200
3: 300 32000 -> 32300
4: 400 32000 -> 32400
5: 500 32000 -> 32500
6: 600 32000 -> 32600
7: 700 32000 -> 32700
8: 800 32000 -> 32767
9: 900 32000 -> 32767
</programlisting>
</para>
<para>
</para>
</refsect1>
<refsect1>
<title>Example 2</title>
<para>
In this example, we will expand on the previous example by making
one of the input arrays a mono stream, and also scale the mono
input stream by a volume. Rather than iterating over each
signed 16-bit value, in this example we will iterate over samples,
meaning the member size for the stereo arrays is 4, since each
array member contains a left and right 16 bit value.
</para>
<para>
<programlisting>
.function audio_add_mono_to_stereo_scaled_s16
.dest 4 d1 short
.source 4 s1 short
.source 2 s2 short
.param 2 volume
.temp 4 s2_scaled
.temp 2 t
.temp 4 s2_stereo
mulswl s2_scaled, s2, volume
shrsl s2_scaled, s2_scaled, 12
convssslw t, s2_scaled
mergewl s2_stereo, t, t
x2 addssw d1, s1, s2_stereo
</programlisting>
Piece by piece:
<programlisting>
.function audio_add_mono_to_stereo_scaled_s16
.dest 4 d1 short
.source 4 s1 short
.source 2 s2 short
</programlisting>
This is the same as the previous example, except that the stereo
arrays are increased in size to 4. However, we'll use the short
type, since Orc does not care what type we use, and short is
the type of the array we want to use in the C code.
<programlisting>
.param 2 volume
</programlisting>
This specifies a parameter, which is an integer that is passed to
an Orc function. In the generated C code, parameters are always of
type int. There are also float parameters for the floating point
equivalent.
<programlisting>
.temp 4 s2_scaled
.temp 2 t
.temp 4 s2_stereo
</programlisting>
This specifies a few temporary variables that are used later in the
code. These definitions are similar to defining local variables in
C code. Note that the size is important: each opcode has
specific sizes for source and destination operands, and it is
important to match these correctly with temporary variables.
<programlisting>
mulswl s2_scaled, s2, volume
shrsl s2_scaled, s2_scaled, 12
</programlisting>
This scales the mono input: signed multiply of s2 and volume, giving
a 32-bit value, and then a signed right shift by 12. Since the
second operand of mulswl is 16-bit, only the lower 16 bits of
volume will be used in the multiply. The right shift is
effectively the same as dividing by 4096. Thus, a neutral scaling
that does not increase or decrease the mono input would correspond
to calling the function with a parameter value of 4096.
<programlisting>
convssslw t, s2_scaled
mergewl s2_stereo, t, t
</programlisting>
The first instruction is "convert saturated signed 32-bit to signed
16-bit", and the second merges the two values of (16 bit) t into the
high and low halves of s2_stereo. This duplicates the mono signal
into the right and left channels. It is important to use the
saturated conversion, since the effective scaling value may have
been greater than 1.0, thus the larger values may need to be clipped.
<programlisting>
x2 addssw d1, s1, s2_stereo
</programlisting>
The "x2" prefix indicates that we want the operation specified to be
done twice, first to the upper half of all operands, and again
separately to the lower half of all operands. Since addssw is
normally a 16-bit operation, the x2 prefix causes it to be a 32-bit
operation. And so, it adds the newly created right and left values
of the scaled mono signal into the s1 signal.
</para>
<para>
There are several variations of the above program that might be
more suitable for a particular application. This function only
handles a limited dynamic range of volume scaling factors, however,
by changing the shift constant, or turning the shift into a
parameter, the dynamic range can be increased significantly.
</para>
</refsect1>
<refsect1>
<title>Example 3</title>
<para>
The third example shows how to convert a planar 4:2:0 video
image into a packed 4:4:4 video image with an alpha channel. The
first format is often referred to as I420 and the second as AYUV.
</para>
<para>
For simplicity in the following discussion, we'll assume that the
image dimensions are 640x480. The 4:2:0 subsampling means the
input chroma planes are 320x240 (subsampled by 2 in each direction).
These need to be upsampled to 640x480, then repacked with the input
Y plane, with an added dummy alpha value. There are many ways to
perform upsampling; the simplest is to duplicate each value
horizontally and vertically. The result is low quality, but
adequate for demonstration purposes.
</para>
<para>
There are several choices for the Orc array size and dimensionality.
Iterating vertically can be done in the C code or in the Orc code. If
done in the Orc code, we would need to use an array size of 240 and
have two separate arrays for the even and odd Y rows. If done in the
C code, there is no such limitation. Horizontally, the story is
different: we can use the loadupsdb opcode to duplicate each byte in
the U and V arrays, so we can iterate over 640 array elements. It
is also possible to iterate over 320 elements and duplicate the U
and V elements using mergebw. There is a very slight speed
advantage to iterating vertically in Orc, and for demonstration
purposes, we will choose to use the loadupsdb opcode, thus we will
be iterating over 320x240 elements.
</para>
<para>
The code:
<programlisting>
.function convert_I420_AYUV
.flags 2d
.dest 4 d1
.dest 4 d2
.source 1 y1
.source 1 y2
.source 1 u
.source 1 v
.const 1 c255 255
.temp 2 uv
.temp 2 ay
.temp 1 tu
.temp 1 tv
loadupdb tu, u
loadupdb tv, v
mergebw uv, tu, tv
mergebw ay, c255, y1
mergewl d1, ay, uv
mergebw ay, c255, y2
mergewl d2, ay, uv
</programlisting>
A few things of note: The ".flags 2d" line is used to indicate that
Orc should iterate over two dimensions, and generate a prototype that
includes row strides for each array and a size parameter for the
second dimension.
</para>
<para>
Since we are working on two input Y lines and two output AYUV lines
at a time, we need two source and destination arrays corresponding
to the even and odd lines. The row strides for these are doubled
compared to the normal 2-D array.
</para>
<para>
The mergebw and mergewl opcodes join two 8-bit values into one 16-bit
value (or 16-bit values into a 32-bit value) by concatinating them
in memory order. Thus, to get AYUV in memory order, we merge AY and
UV, and to get UV, we merge U and V. Since we're duplicating each
U and V line, we use the same UV value for the even and odd output
lines.
</para>
<para>
The prototype that is generated is:
<programlisting>
void convert_I420_AYUV (orc_uint32 * d1, int d1_stride, orc_uint32 * d2,
int d2_stride, const orc_uint8 * s1, int s1_stride, const orc_uint8 * s2,
int s2_stride, const orc_uint8 * s3, int s3_stride, const orc_uint8 * s4,
int s4_stride, int n, int m);
</programlisting>
The orcc tool unhelpfully changed the names of the parameters,
however, the order is standard: first destinations, then sources, then
parameters, then array sizes. Think of it like memcpy() or memset().
</para>
<para>
Calling the function:
<programlisting>
convert_I420_AYUV (output, 1280*4, output + 640, 1280 * 4,
input_y, 1280, input_y + 640, 1280,
input_u, 320, input_v, 320,
320, 240);
</programlisting>
</para>
</refsect1>
</refentry>
|