Graalbench

A

Graphics

Benchmark

Suite

For

Mobile

Phones

In

this

paper

we

consider

implementations

of

embedded

graphics

and

provide

evidence

indicating

that

benchmarks

employed

for

desktop

computers

are

not

suitable

for

mobile

environments

Consequently

we

present

GraalBench

a

set

of

graphics

workloads

representative

for

contemporary

and

emerging

mobile

devices

In

addition

we

present

detailed

simulation

results

for

a

typical

rasterization

pipeline

The

results

show

that

the

proposed

benchmarks

use

only

a

part

of

the

resources

offered

by

current

graphics

libraries

For

instance

while

each

benchmark

uses

the

texturing

unit

for

more

than

of

the

generated

fragments

the

alpha

unit

is

employed

for

less

than

of

the

fragments

The

Fog

unit

was

used

for

of

the

fragments

by

one

benchmark

but

the

other

benchmarks

did

not

use

it

at

all

Our

experiments

on

the

proposed

suite

suggest

that

the

texturing

depth

and

blending

units

should

be

implemented

in

hardware

while

for

instance

the

dithering

unit

may

be

omitted

from

a

hardware

implementation

Finally

we

discuss

the

architectural

implications

of

the

obtained

results

for

hardware

implementations

C.

-LSB-

Special-Purpose

and

Application-Based

Systems

-RSB-

Real-time

and

embedded

systems

Performance

Measurement

Permission

to

make

digital

or

hard

copies

of

all

or

part

of

this

work

for

personal

or

classroom

use

is

granted

without

fee

provided

that

copies

are

not

made

or

distributed

for

profit

or

commercial

advantage

and

that

copies

bear

this

notice

and

the

full

citation

on

the

first

page

To

copy

otherwise

to

republish

to

post

on

servers

or

to

redistribute

to

lists

requires

prior

specific

permission

and/or

a

fee

LCTES

June

Washington

DC

USA

Copyright

ACM

In

recent

years

mobile

computing

devices

have

been

used

for

a

broader

spectrum

of

applications

than

mobile

telephony

or

personal

digital

assistance

Several

companies

expect

that

graphics

applications

will

become

an

important

workload

of

wireless

devices

For

example

according

to

-LSB-

-RSB-

the

number

of

users

of

interactive

graphics

applications

-LRB-

in

particular

games

-RRB-

is

expected

to

increase

drastically

in

the

future

it

is

predicted

that

the

global

wireless

games

market

will

grow

to

billion

dollars

in

Because

current

wireless

devices

do

not

have

sufficient

computational

power

to

support

graphics

in

real

time

and

because

present

accelerators

consume

too

much

power

several

companies

and

universities

have

started

to

develop

a

low-power

graphics

accelerator

However

to

the

best

of

our

knowledge

there

is

no

publicly

available

benchmark

suite

that

can

be

used

to

guide

the

architectural

exploration

of

such

devices

This

paper

presents

GraalBench

a

graphics

benchmark

suite

suitable

for

graphics

on

low-power

mobile

systems

in

particular

mobile

phones

These

benchmarks

were

collected

to

facilitate

our

studies

on

low-power

graphics

accelerators

in

the

Graal

-LRB-

GRAphics

AcceLerator

-RRB-

project

-LSB-

-RSB-

It

includes

several

games

as

well

as

virtual

reality

applications

such

as

museum

guides

Applications

were

selected

on

the

basis

of

several

criteria

For

example

CAD/CAM

applications

such

as

contained

in

the

Viewperf

package

-LSB-

-RSB-

were

excluded

because

it

is

unlikely

that

they

will

be

offered

on

mobile

devices

Other

characteristics

we

considered

are

resolution

and

polygon

count

A

second

goal

of

this

paper

is

to

provide

a

detailed

quantitative

workload

characterization

of

the

collected

benchmarks

For

each

rasterization

unit

we

determine

if

it

is

used

by

the

benchmark

and

collect

several

statistics

such

as

the

number

of

fragments

that

bypass

the

unit

fragments

that

are

processed

by

the

unit

and

pass

the

test

and

fragments

that

are

processed

but

fail

the

test

Such

statistics

can

be

used

to

guide

the

development

of

mobile

graphics

architectures

For

example

a

unit

that

is

rarely

used

might

not

be

supported

by

a

low-power

accelerator

or

it

might

be

implemented

using

less

resources

Furthermore

if

many

fragments

are

discarded

before

the

final

tests

the

pixel

pipeline

of

the

last

stages

might

be

narrower

than

the

width

of

earlier

stages

This

paper

is

organized

as

follows

Previous

work

on

graphics

benchmarking

is

described

in

Section

In

this

section

we

also

give

reasons

why

current

graphics

benchmarks

are

not

appropriate

for

mobile

environments

Section

first

explains

how

the

benchmarks

were

obtained

describes

our

tracing

environment

the

simulator

we

used

to

collect

the

statistics

and

after

that

describes

the

components

of

the

proposed

benchmark

suite

and

presents

some

general

characteristics

of

the

workloads

Section

provides

a

workload

characterization

of

the

benchmarks

and

discusses

architectural

implications

Conclusions

and

directions

for

future

work

are

given

in

Section

To

the

best

of

our

knowledge

graphics

benchmarks

specifi-cally

targeted

at

low-power

architectures

have

not

been

proposed

Furthermore

existing

benchmarks

can

not

be

considered

to

be

suited

for

embedded

graphics

architectures

For

example

consider

SPEC

's

Viewperf

-LSB-

-RSB-

a

well-known

benchmark

suite

used

to

evaluate

graphics

accelerator

cards

employed

in

desktop

computers

These

benchmarks

are

unsuitable

for

low-power

graphics

because

of

the

following

The

Viewperf

benchmarks

are

designed

for

high-resolution

output

devices

but

the

displays

of

current

wireless

systems

have

a

limited

resolution

Specifically

by

default

the

Viewperf

package

is

running

at

resolutions

above

SVGA

-LRB-

pixels

-RRB-

while

common

display

resolutions

for

mobile

phones

are

QCIF

-LRB-

-RRB-

and

QVGA

-LRB-

-RRB-

The

Viewperf

benchmarks

use

a

large

number

of

polygons

in

order

to

obtain

high

picture

quality

-LRB-

most

benchmarks

have

more

than

triangles

per

frame

-LSB-

-RSB-

-RRB-

Translated

to

a

mobile

platform

most

rendered

polygons

will

be

smaller

than

one

pixel

so

their

contribution

to

the

generated

images

will

be

small

or

even

invisible

Specifically

the

polygon

count

of

the

Viewperf

benchmarks

DRV

DX

ProCDRS

and

MedMCAD

is

too

high

for

mobile

devices

Some

benchmarks

of

Viewperf

are

CAD/CAM

applications

and

use

wire-frame

rendering

modes

It

is

unlikely

that

such

applications

will

be

offered

on

mobile

platforms

Except

Viewperf

there

are

no

publicly-available

portable

graphics

benchmark

suites

Although

there

are

several

benchmarking

suites

-LSB-

-RSB-

based

on

the

DirectX

API

they

are

not

suitable

for

our

study

since

DirectX

implementations

are

available

only

on

Windows

systems

There

have

been

several

studies

related

to

graphics

workload

characterization

-LRB-

e.g.

-LSB-

-RSB-

-RRB-

Most

related

to

our

investigation

is

the

study

of

Mitra

and

Chiueh

-LSB-

-RSB-

since

they

also

considered

dynamic

polygonal

graphics

workloads

Dynamic

means

that

the

workloads

consist

of

several

consecutive

image

frames

rather

than

individual

images

which

allows

to

study

techniques

that

exploit

the

coherence

between

consecutive

frames

Polygonal

means

that

the

basic

primitives

are

polygons

which

are

supported

by

all

existing

chips

The

main

differences

between

that

study

and

our

workload

characterization

are

that

Mitra

and

Chiueh

considered

high-end

applications

-LRB-

Viewperf

among

others

-RRB-

and

measured

different

statistics

Recently

a

number

of

mobile

graphics

accelerators

-LSB-

-RSB-

have

been

presented

In

both

works

particular

benchmarks

were

employed

to

evaluate

the

accelerators

However

little

information

is

provided

about

the

benchmarks

and

they

have

not

been

made

publicly

available

Another

reason

for

the

limited

availability

of

mobile

graphics

benchmarks

is

that

until

recently

there

was

no

generally

accepted

API

for

graphics

on

mobile

phones

Recently

due

to

high

interest

in

embedded

graphics

APIs

suitable

for

mobile

graphics

such

as

OpenGL

ES

-LSB-

-RSB-

Java

mobile

Graphics

API

-LRB-

-RRB-

-LSB-

-RSB-

and

Mobile

GL

-LSB-

-RSB-

have

appeared

Currently

however

there

are

no

benchmarks

written

using

these

APIs

So

we

have

used

OpenGL

applications

Furthermore

our

benchmarks

use

only

a

part

of

the

OpenGL

functionality

which

is

also

supported

by

OpenGL

ES

In

this

section

we

describe

the

environment

we

used

to

create

the

benchmarks

the

components

of

our

benchmark

set

and

also

some

general

characteristics

of

the

workloads

Tracing

Environment

Due

to

their

interactive

nature

games

are

generally

not

repeatable

In

order

to

obtain

a

set

of

repeatable

workloads

we

traced

existing

applications

logging

all

OpenGL

calls

Our

tracing

environment

consists

of

two

components

a

tracer

and

a

trace

player

Our

tracer

is

based

on

GLtrace

from

Hawksoft

-LSB-

-RSB-

It

intercepts

and

logs

OpenGL

calls

made

by

a

running

application

and

then

calls

the

OpenGL

function

invoked

by

the

application

No

source

code

is

required

provided

the

application

links

dynamically

with

the

OpenGL

library

meaning

that

the

executable

only

holds

links

to

the

required

functions

which

are

bounded

to

the

corresponding

functions

at

run-time

Statically

linked

applications

in

which

case

the

required

libraries

are

encapsulated

in

the

executable

image

can

not

be

traced

using

this

mechanism

when

the

source

code

is

not

available

We

improved

GLtrace

in

two

ways

First

GLtrace

does

not

log

completely

reproducible

OpenGL

calls

-LRB-

for

example

textures

are

not

logged

-RRB-

We

modified

the

GLtrace

library

so

that

all

OpenGL

calls

are

completely

reproducible

Second

the

trace

produced

by

GLtrace

is

a

text

trace

which

is

rather

slow

We

improved

its

performance

by

adding

a

binary

logging

mode

that

significantly

reduces

the

tracing

overhead

In

addition

we

developed

a

trace

player

that

plays

the

obtained

traces

It

can

play

recorded

frames

as

fast

as

the

OpenGL

implementation

allows

It

does

not

skip

any

frame

so

the

workload

generated

is

always

the

same

The

workload

statistics

were

collected

using

our

own

OpenGL

simulator

based

on

Mesa

-LSB-

-RSB-

which

is

a

public-domain

implementation

of

OpenGL

The

Benchmarks

The

proposed

benchmark

suite

consists

of

the

following

components

and

Quake

III

-LSB-

-RSB-

or

for

short

is

a

popular

interactive

game

belonging

to

the

shooter

games

category

A

screenshot

of

this

game

is

depicted

in

Figure

-LRB-

a

-RRB-

Even

though

it

can

be

considered

outdated

for

contemporary

PC-class

graphics

accelerators

it

is

an

appropriate

and

demanding

application

for

low-power

devices

has

a

flexible

design

and

permits

many

settings

to

be

changed

such

as

image

size

and

depth

texture

quality

geometry

detail

types

of

texture

filtering

etc.

We

used

two

profiles

for

this

workload

in

-LRB-

a

-RRB-

-LRB-

b

-RRB-

Tux

-LRB-

c

-RRB-

AW

-LRB-

d

-RRB-

ANL

-LRB-

e

-RRB-

GRA

-LRB-

f

-RRB-

DIN

Figure

Screenshots

of

the

GraalBench

workloads

order

to

determine

the

implications

of

different

image

sizes

and

object

complexity

The

first

profile

which

will

be

re-ferred

to

as

uses

a

relatively

high

image

resolution

and

objects

detail

The

second

profile

employs

a

low

resolution

and

objects

detail

makes

extensive

use

of

blending

operations

in

order

to

implement

multiple

texture

passes

Tux

Racer

-LRB-

Tux

-RRB-

-LSB-

-RSB-

This

is

a

freely

available

game

that

runs

on

Linux

The

goal

of

this

game

is

to

drive

a

penguin

down

a

mountain

terrain

as

quickly

as

possible

while

collecting

herring

The

image

quality

is

higher

than

that

of

Tux

makes

extensive

use

of

automatic

texture

coordinate

generation

functions

A

screenshot

can

be

seen

in

Figure

-LRB-

b

-RRB-

-LRB-

AW

-RRB-

-LSB-

-RSB-

This

test

is

part

of

the

Viewperf

package

In

this

test

a

fully

textured

human

model

is

viewed

from

different

angles

and

distances

As

remarked

before

the

other

test

in

the

Viewperf

package

are

not

suitable

for

low-power

accelerators

because

they

represent

high-end

applications

or

are

from

an

application

domain

not

likely

to

be

offered

on

mobile

platforms

A

screenshot

of

AW

is

depicted

in

Figure

-LRB-

c

-RRB-

ANL

GRA

and

DIN

These

three

VRML

scenes

were

chosen

based

on

their

diversity

and

complexity

ANL

is

a

virtual

model

of

Austrian

National

Library

and

consists

of

polygons

GRA

is

a

model

of

Graz

University

of

Technology

Austria

and

consists

of

polygons

and

Dino

-LRB-

DIN

-RRB-

is

a

model

of

a

dinosaur

consisting

of

polygons

In

order

to

obtain

a

workload

similar

to

one

that

might

be

generated

by

a

typical

user

we

created

fly-by

scenes

Initially

we

used

VR-Web

-LSB-

-RSB-

to

navigate

through

the

scenes

but

we

found

that

the

VRMLView

-LSB-

-RSB-

navigator

produces

less

texture

traffic

because

it

uses

the

glBindTexture

mechanism

Screenshots

of

ANL

GRA

and

DIN

are

depicted

in

Figure

-LRB-

d

-RRB-

-LRB-

e

-RRB-

and

-LRB-

f

-RRB-

respectively

GraalBench

is

the

result

of

extensive

searching

on

the

World

Wide

Web

The

applications

were

selected

on

the

basis

of

several

criteria

First

since

the

display

resolution

of

contemporary

mobile

phones

is

at

most

we

excluded

applications

with

substantially

higher

resolution

Specifically

we

used

a

maximum

resolution

of

Second

the

applications

should

be

relevant

for

a

mobile

phone

i.e.

it

should

be

likely

that

it

will

be

offered

on

a

mobile

phone

CAD/CAM

applications

were

excluded

for

this

reason

Third

the

level

of

details

of

the

applications

should

not

be

too

high

because

otherwise

most

rendered

polygons

will

be

smaller

than

one

pixel

on

the

display

of

a

mobile

phone

Fourth

and

finally

the

benchmarks

should

have

different

characteristics

For

example

several

links

to

games

have

recently

been

provided

on

Mesa

's

website

-LRB-

-RRB-

However

these

games

such

as

Doom

Heretic

and

Quake

II

belong

to

the

same

category

as

Quake

III

and

Tux

Racer

and

therefore

do

not

represent

benchmarks

with

substantially

different

characteristics

We

therefore

decided

not

to

include

them

Applications

using

the

latest

technologies

-LRB-

Vertex

and

Pixel

Sha-ders

-RRB-

available

on

desktop

graphics

accelerators

were

also

not

included

since

these

technologies

are

not

supported

by

the

embedded

graphics

APIs

mentioned

in

Section

We

expect

that

more

graphics

applications

for

low-power

mobile

devices

will

appear

when

accelerators

for

these

platforms

will

be

introduced

General

Characteristics

Table

present

some

general

statistics

of

the

workloads

The

characteristics

and

statistics

presented

in

this

table

are

Image

resolution

Currently

low-power

accelerator

should

be

able

to

handle

scenes

with

a

typical

resolution

of

pixels

Since

in

the

near

future

the

typical

resolution

is

expected

to

increase

we

decided

to

use

a

resolution

of

The

benchmark

uses

a

lower

resolution

-LRB-

-RRB-

in

order

to

study

the

impact

of

changing

the

resolution

Frames

The

total

number

of

frames

in

each

test

Avg

triangles

The

average

number

of

triangles

sent

to

the

rasterizer

per

frame

Avg

processed

triangles

The

average

number

of

triangles

per

frame

that

remained

after

backface

culling

i.e.

the

triangles

that

remained

after

eliminating

the

triangles

that

are

invisible

because

they

are

facing

backwards

from

the

observer

's

viewpoint

Avg

area

The

average

number

per

frame

of

fragments/pixels

after

scan

conversion

Texture

size

The

total

size

of

all

textures

per

workload

This

quantity

gives

an

indication

of

the

amount

of

texture

memory

required

Maximum

triangles

The

maximum

number

of

triangles

that

were

sent

for

one

frame

Because

most

graphics

accelerators

implement

only

rasterization

this

statistic

is

an

approximation

of

the

bandwidth

required

for

geometry

information

since

triangles

need

to

be

transferred

from

the

CPU

to

the

accelerator

via

a

system

bus

We

assume

that

triangles

are

represented

individually

Sharing

vertices

between

adjacent

triangles

allows

to

reduce

the

bus

bandwidth

required

This

quantity

also

determines

the

throughput

required

in

order

to

achieve

real-time

frame

rates

We

remark

that

the

maximum

number

rather

than

the

average

number

of

triangles

per

frame

determines

the

required

bandwidth

and

throughput

Maximum

processed

triangles

per

frame

The

maximum

number

of

triangles

that

remained

after

backface

culling

over

all

frames

Maximum

area

per

frame

The

maximum

number

of

fragments

after

scan

conversion

over

all

frames

Several

observations

can

be

drawn

from

Table

First

it

can

be

observed

from

the

columns

labeled

Received

triangles

that

the

scenes

generated

by

Tux

and

Dino

have

a

relatively

low

complexity

that

ANL

and

Graz

consist

of

medium

complexity

scenes

and

that

AW

produces

the

most

complex

scenes

by

far

Second

backface

culling

is

effective

in

eliminating

invisible

triangles

It

eliminates

approximately

of

all

triangles

in

the

benchmarks

in

Graz

and

more

than

half

-LRB-

-RRB-

of

all

triangles

in

AW

Backface

culling

is

not

enabled

in

the

ANL

and

Dino

workloads

If

we

consider

the

largest

number

of

triangles

remaining

after

backface

culling

-LRB-

for

ANL

-RRB-

and

assume

that

each

triangle

is

represented

individually

and

requires

bytes

-LRB-

xyz

coordinates

bytes

each

rgb

for

color

and

alpha

for

transparency

byte

each

and

uvw

texture

coordinates

bytes

each

-RRB-

for

each

of

its

vertices

the

required

bus

bandwidth

is

approximately

MB/frame

or

MB/s

to

render

frames

per

second

Finally

we

remark

that

the

largest

amount

of

texture

memory

is

required

by

the

and

Tux

benchmarks

and

that

the

other

benchmarks

require

a

relatively

small

amount

of

texture

memory

Table

Stress

variation

and

stress

strength

on

various

stages

of

the

graphics

pipeline

Bench

T&L

Rasterization

Var

Str

Var

Str

med

med

med

med

med

med

med

high

Tux

var

low

low

med

AW

low

high

high

low

ANL

high

med

med

med

GRA

high

med

med

low

DIN

low

med

med

low

This

section

provides

the

detailed

analysis

of

results

we

obtained

by

running

the

proposed

benchmark

set

For

each

unit

of

a

typical

rasterization

pipeline

we

present

the

relevant

characteristics

followed

by

the

architectural

implications

Detailed

Workload

Statistics

One

important

aspect

for

graphics

benchmarking

is

to

determine

possible

bottlenecks

in

a

graphics

environment

since

the

graphics

environment

has

a

pipeline

structure

and

different

parts

of

the

pipeline

can

be

implemented

on

separate

computing

resources

such

as

general

purpose

processors

or

graphics

accelerators

Balancing

the

load

on

the

resources

is

an

important

decision

Bottlenecks

in

the

transform

lighting

-LRB-

T&L

-RRB-

part

of

the

pipeline

can

be

generated

by

applications

that

have

a

large

number

of

primitives

i.e.

substantial

geometry

computation

load

where

each

primitive

has

a

small

size

i.e.

reduced

impact

on

the

rasterization

part

of

the

pipeline

while

bottlenecks

in

the

rasterization

part

are

usu-ally

generated

by

fill

intensive

applications

that

are

using

a

small

number

of

primitives

where

each

primitive

covers

a

substantial

part

of

the

scene

An

easy

way

to

determine

if

an

application

is

for

instance

rasterization

intensive

is

to

remove

the

rasterization

part

from

the

graphics

pipeline

and

determine

the

speed

up

The

components

of

the

GraalBench

were

also

chosen

to

stress

various

parts

of

the

pipeline

For

instance

the

AW

and

DIN

components

generate

an

almost

constant

number

of

primitives

while

the

generated

area

varies

substantially

across

frames

thus

in

these

scenarios

the

T&L

part

of

the

pipeline

has

a

virtually

constant

load

while

the

rasterization

part

has

a

variable

load

This

behavior

depicted

in

Figure

-LRB-

c

d

g

h

-RRB-

can

emphasize

the

role

of

the

rasterization

part

of

the

pipeline

The

number

of

triangles

received

gives

an

indication

of

the

triangles

that

have

to

be

transformed

and

lit

while

the

number

of

triangles

processed

gives

an

indication

of

the

triangles

that

were

sent

to

the

rasterization

stage

after

clipping

and

culling

Other

components

e.g.

Tux

generate

a

variable

number

of

triangles

while

the

generated

area

is

almost

constant

thus

they

can

be

used

to

profile

bottlenecks

in

the

T&L

part

of

the

graphics

pipeline

Another

important

aspect

beside

the

variation

of

the

workload

for

a

certain

pipeline

stage

is

also

the

stress

strength

of

the

various

workload

For

convenience

in

Table

is

also

presented

a

rough

view

of

the

stress

variation

and

stress

strength

along

the

graphics

pipeline

The

stress

variation

represents

how

much

varies

a

workload

from

one

frame

to

another

while

the

stress

strength

represents

the

load

generated

by

each

workload

On

the

proposed

benchmarks

we

determined

that

for

a

software

implementation

the

most

computationally

intensive

part

of

Table

General

statistics

of

the

benchmarks

Bench

Resolution

Frames

Textures

-LRB-

MB

-RRB-

Received

Triangles

Avg

Max

Processed

Triangles

Avg

Max

Area

Avg

Max

k

k

k

k

k

k

k

k

k

k

k

Tux

k

k

k

k

AW

k

k

k

ANL

k

k

k

k

k

GRA

k

k

k

k

DIN

k

k

k

k

Blending

Depth

Test

Alpha

Test

Scissor

Test

Stencil

Test

Pixel

Ownership

Dithering

LogicOp

Texture

Unit

Color

Stencil

Texturing

Color

Sum

Edge

Walk

Span

Interpolation

Triangle

Setup

Texture

Memory

Memory

Primitives

sent

fom

the

Transform

Lighting

Stage

Depth

Fog

Clear

Figure

Graphics

pipeline

for

rasterization

the

graphics

pipeline

is

the

rasterization

part

This

is

the

reason

why

only

the

rasterizer

stage

was

additionally

studied

The

units

for

which

we

further

gathered

results

are

depicted

in

Figure

and

described

in

the

following

Triangle

Setup

EdgeWalk

and

Span

Interpolation

These

units

convert

primitives

to

fragments

We

used

the

same

algorithm

as

employed

in

the

Mesa

library

rasterizer

We

remark

that

the

number

of

processed

triangles

in

Table

is

smaller

than

the

number

of

processed

triangles

in

Table

because

some

triangles

were

small

and

discarded

using

supplementary

tests

such

as

a

small

triangle

filter

The

average

number

of

processed

triangles

is

the

lowest

for

Tux

medium

for

and

VRML

components

and

substantially

higher

for

AW

considering

that

the

number

of

triangles

for

the

AW

and

VRML

components

were

generated

in

approximatively

half

as

many

frames

as

the

number

of

frames

in

and

Tux

The

numbers

of

generated

spans

and

fragments

also

give

an

indication

of

the

processing

power

required

at

the

EdgeWalk

and

Span

Interpolation

units

The

AW

benchmark

generates

on

average

only

spans

per

triangle

and

approximately

fragments

per

span

These

results

show

that

the

benchmark

that

could

create

a

pipeline

bottleneck

in

these

units

is

the

AW

benchmark

since

it

has

small

triangles

-LRB-

small

impact

on

the

rest

of

the

pipeline

-RRB-

and

it

has

the

largest

number

of

triangles

-LRB-

that

are

processed

at

the

Triangle

Setup

-RRB-

Clear

Unit

The

clear

unit

is

used

to

fill

the

Depth

buffer

and/or

the

Color

buffer

with

a

default

value

As

can

be

seen

in

Table

the

benchmark

uses

only

depth

buffer

clearing

except

for

one

initial

color

buffer

clear

exploits

the

observation

that

all

pixels

from

a

scene

are

going

to

be

filled

at

least

once

so

there

is

no

need

to

clear

the

color

buffer

The

other

benchmarks

have

an

equal

number

of

depth

and

color

buffer

clears

Although

the

clear

function

is

called

a

relatively

small

number

of

times

the

number

of

cleared

pixels

can

be

as

high

as

of

the

pixels

generated

by

the

rasterizer

This

implies

that

this

unit

should

be

optimized

for

long

write

burst

to

the

graphics

memory

Texture

Unit

When

enabled

this

unit

combines

the

color

of

the

incoming

fragment

with

a

texture

sample

color

Depending

on

the

texturing

filter

chosen

the

texture

color

is

obtained

by

a

direct

look-up

in

a

texture

map

or

by

a

linear

interpolation

between

several

colors

-LRB-

up

to

colors

in

the

case

of

trilinear

interpolation

-RRB-

The

results

obtained

for

the

texture

unit

are

depicted

in

Figure

The

and

VV

benchmarks

used

the

texture

unit

for

all

fragments

while

the

Tux

and

AW

benchmarks

used

texturing

for

and

of

the

fragments

respectively

This

unit

is

the

most

computationally

intensive

unit

of

a

rasterizer

and

can

easily

become

a

pipeline

bottleneck

thus

it

should

be

highly

optimized

for

speed

Beside

requiring

high

computational

power

this

unit

also

requires

a

large

number

of

accesses

to

the

texture

memory

However

due

to

high

spatial

locality

even

by

adding

a

small

texture

cache

the

traffic

from

the

off-chip

texture

memory

to

the

texture

unit

can

be

substantially

reduced

-LSB-

-RSB-

Fog

Unit

The

Fog

unit

is

to

used

modify

the

fragment

color

in

order

to

simulate

atmospheric

effects

such

as

haze

mist

or

smoke

Only

the

Tux

benchmark

uses

the

fog

unit

and

it

was

enabled

for

of

the

fragments

From

the

three

types

of

fog

-LRB-

linear

exponential

and

squared

exponential

-RRB-

only

linear

was

used

The

results

suggest

that

for

these

low-end

applications

the

fog

unit

is

seldomly

used

and

that

it

might

be

implemented

using

slower

components

or

that

this

unit

can

be

implemented

off

the

critical

path

Table

Triangle

Setup

Edge

Walk

and

Span

Interpolation

units

statistics

Tux

AW

ANL

GRA

DIN

Triangles

processed

k

k

k

k

k

k

k

Generated

spans

k

k

k

k

k

k

k

Generated

fragments

-LRB-

frags

-RRB-

k

k

k

k

k

k

k

Table

Clear

unit

statistics

Tux

AW

ANL

GRA

DIN

Clear

depth

calls

Clear

color

calls

Clear

depth

pixels

k

k

k

k

k

k

k

Clear

color

pixels

k

k

k

k

k

Scissor

Unit

This

unit

is

used

to

discard

fragments

that

are

outside

of

a

specified

rectangular

area

Only

employed

scissoring

All

incoming

fragments

were

processed

and

passed

the

test

so

even

in

this

case

the

test

is

redundant

since

no

fragments

were

rejected

Normally

the

scissor

unit

is

used

to

restrict

the

drawing

process

to

a

certain

rectangular

region

of

the

image

space

In

this

unit

besides

being

always

enabled

for

the

whole

size

of

the

image

space

-LRB-

to

clip

primitives

outside

it

-RRB-

in

some

cases

it

is

also

used

to

clear

the

depth

component

of

a

specific

region

of

the

image

so

that

certain

objects

-LRB-

interface

objects

-RRB-

will

always

be

in

front

of

other

objects

-LRB-

normal

scene

-RRB-

Even

though

it

might

be

used

intensively

by

some

applications

this

unit

performs

simple

computations

such

as

comparisons

and

performs

no

memory

accesses

so

it

does

not

require

substantial

computational

power

Alpha

Unit

This

unit

discards

fragments

based

on

their

alpha

color

component

This

unit

was

used

only

in

and

Tux

Furthermore

used

the

alpha

unit

only

for

a

very

small

number

of

fragments

-LRB-

-RRB-

The

only

comparison

function

used

was

Greater

or

Equal

However

this

is

not

a

significant

property

since

the

other

comparison

functions

-LRB-

modes

-RRB-

do

not

require

a

substantial

amount

of

extra

hardware

to

be

implemented

The

number

of

passed

fragments

could

not

be

determined

since

the

texturing

unit

of

our

graphics

simulator

is

not

yet

complete

and

the

alpha

test

depends

on

the

alpha

component

that

can

be

modified

by

the

texture

processing

unit

However

this

unit

is

used

significantly

only

for

the

Tux

benchmark

so

this

is

the

only

benchmark

that

could

have

produced

different

results

Furthermore

the

propagated

error

for

the

results

we

obtained

can

be

at

most

since

of

the

fragments

generated

by

Tux

bypassed

this

unit

We

therefore

assumed

that

all

fragments

passed

the

alpha

test

This

corresponds

to

the

worst

case

Since

this

unit

is

seldomly

used

it

could

be

implemented

using

a

more

conservative

strategy

toward

allocated

resources

Depth

Unit

This

unit

discards

a

fragment

based

on

a

comparison

between

its

depth

value

and

the

depth

value

stored

in

the

depth

buffer

in

the

fragment

's

corresponding

position

This

unit

was

used

intensively

by

all

benchmarks

as

can

be

seen

in

Table

While

the

Tux

Aw

and

VRML

benchmarks

write

almost

all

fragments

that

passed

the

depth

test

to

the

depth

buffer

the

benchmark

writes

to

the

depth

buffer

only

of

the

fragments

that

passed

the

test

This

is

expected

since

uses

multiple

steps

to

apply

textures

to

primitives

and

so

it

does

not

need

to

write

to

the

depth

buffer

at

each

step

This

unit

should

definitely

be

implemented

in

an

aggressive

manner

with

respect

to

throughput

-LRB-

processing

power

-RRB-

and

latency

since

for

instance

the

depth

buffer

read/write

operations

used

at

this

unit

are

quite

expensive

Blending

Unit

This

unit

combines

the

color

of

the

incoming

fragment

with

the

color

stored

at

the

corresponding

position

in

the

framebuffer

As

depicted

in

Figure

this

unit

is

used

only

by

the

and

Tux

benchmarks

The

AW

and

VRML

benchmarks

do

not

use

this

unit

since

they

use

only

single

textured

primitives

and

all

blending

operations

are

performed

at

the

texturing

stage

on

the

other

hand

uses

a

variety

of

blending

modes

while

Tux

employs

only

a

very

common

blending

mode

-LRB-

source

incoming

pixel

alpha

and

dest

incoming

pixel

alpha

-RRB-

An

explanation

why

Tux

manages

to

use

only

this

mode

is

that

Tux

uses

the

alpha

test

instead

of

multiple

blending

modes

Alpha

tests

are

supposed

to

be

less

computationally

intensive

than

blending

operations

since

there

is

only

one

comparison

per

fragment

while

the

blending

unit

performs

up

to

multiplications

and

additions

per

fragment

Based

on

its

usage

and

computational

power

required

the

implementation

of

this

unit

should

be

tuned

toward

performance

Unused

Units

The

LogicOp

Stencil

and

Color

Sum

units

are

not

used

by

any

benchmark

The

dithering

unit

is

used

only

by

the

AW

benchmark

-LRB-

for

all

fragments

that

passed

the

blending

stage

-RRB-

Since

these

units

are

expected

to

be

hardly

used

their

implementation

could

be

tuned

toward

low-power

efficiency

Architectural

Implications

Based

on

Unit

Usage

In

this

section

the

usage

of

each

unit

for

the

selected

benchmarks

is

presented

The

statistics

are

gathered

separately

for

each

benchmark

Figure

breaks

down

the

number

of

fragments

received

by

each

unit

into

fragments

that

bypassed

the

unit

fragments

that

were

processed

by

the

unit

and

passed

the

test

and

fragments

that

failed

the

test

All

values

are

normalized

to

the

number

of

fragments

generated

by

the

Span

Interpolation

unit

From

Figure

it

can

be

seen

that

the

benchmark

is

quite

scalable

and

the

results

obtained

for

the

low

resolution

profile

-LRB-

-RRB-

are

similar

with

the

results

obtained

for

the

high

resolution

profile

-LRB-

-RRB-

The

benchmark

can

be

characterized

as

an

application

that

uses

textures

for

most

of

its

primitives

The

Tux

component

is

also

using

textures

for

more

than

of

its

primitives

and

it

also

uses

the

fog

unit

The

AW

component

does

not

use

the

scissor

test

Table

Depth

unit

statistics

Tux

AW

ANL

GRA

DIN

Incoming

frags

k

k

k

k

k

k

k

Processed

frags

k

k

k

k

k

k

k

Passed

frags

k

k

k

k

k

k

k

Frags

written

to

the

depth

buffer

k

k

k

k

k

k

k

DIN

Q

A

NL

G

ra

A

w

Tux

Q

Texture

Fog

Scissor

Alpha

Depth

Blending

Dithering

F

r

agments

Passed

Failed

Bypassed

Figure

Rasterization

pipeline

units

usage

as

the

others

are

doing

and

also

it

has

no

pixels

rejected

at

the

depth

test

Another

difference

from

the

previous

components

is

that

AW

is

also

using

the

dithering

mechanism

in

order

to

improve

the

image

quality

on

displays

with

a

low

color

depth

Some

architectural

implications

based

on

the

units

usage

are

Some

of

the

units

such

as

Color

sum

LogicOp

and

Stencil

were

not

used

so

they

might

not

be

implemented

in

hardware

Some

units

such

as

Fog

and

Alpha

were

less

used

and

they

can

be

also

be

implemented

outside

the

critical

path

The

Depth

and

Blending

units

should

be

hard-wired

units

and

tuned

toward

performance

The

texture

unit

should

be

definitely

focused

upon

for

a

high

performance

implementation

since

due

to

the

processing

power

required

it

can

easily

become

a

bottleneck

for

the

graphics

pipeline

Although

high-end

graphics

benchmarks

have

been

available

for

some

time

there

are

no

benchmark

suites

dedicated

to

embedded

graphics

accelerators

In

this

paper

we

have

described

a

set

of

relevant

applications

for

embedded

graphics

accelerators

performance

evaluation

Also

one

of

the

objectives

of

this

paper

was

to

determine

what

features

of

graphics

implementations

are

used

in

relevant

graphics

applications

We

have

also

identified

a

number

of

units

from

the

graphics

pipeline

which

are

intensively

used

such

as

the

texture

and

the

depth

units

while

for

instance

stencil

fog

and

dithering

units

being

rarely

used

The

OpenGL

applications

that

were

used

to

create

the

benchmarks

and

the

GLtrace

tracer

are

accessible

via

the

first

author

's

website

-LRB-

-RRB-

The

benchmarks

-LRB-

i.e.

the

traces

-RRB-

can

not

be

made

public

currently

because

they

are

of

no

use

without

the

trace

player

and

the

trace

player

is

confidential

at

the

moment

However

the

Quake

III

-LRB-

demo

version

-RRB-

and

the

components

do

not

require

the

use

of

the

trace

player

in

order

to

generate

repeatable

workloads

We

hope

to

be

able

to

make

the

benchmark

suite

publicly

available

in

the

future

As

future

work

we

intend

to

extend

the

number

of

components

for

this

benchmark

suite

and

we

also

intend

to

extend

the

statistics

to

include

results

from

embedded

graphics

architectures

that

are

using

a

tile-based

rendering

mechanism

-LSB-

-RSB-

T.

Akenine-M

oller

and

J.

Str

om

Graphics

for

the

Masses

A

Hardware

Rasterization

Architecture

for

Mobile

Phones

ACM

Trans

on

Graph.

vol

nr

pp.

-LSB-

-RSB-

I.

Antochi

B.H.H.

Juurlink

A.

G.

M.

Cilio

and

P.

Liuha

Trading

Efficiency

for

Energy

in

a

Texture

Cache

Architecture

Proc

Euromicro

Conf

on

Massively-Parallel

Computing

Systems

-LRB-

MPCS

-RRB-

Ischia

Italy

pp.

-LSB-

-RSB-

Futuremark

Corporation

Available

at

-LSB-

-RSB-

Futuremark

Corporation

Available

at

-LSB-

-RSB-

D.

Crisu

S.D.

Cotofana

S.

Vassiliadis

and

P.

Liuha

GRAAL

A

Development

Framework

for

Embedded

Graphics

Accelerators

Proc

Design

Automation

and

Test

in

Europe

-LRB-

DATE

-RRB-

Paris

France

February

-LSB-

-RSB-

J.C.

Dunwoody

and

M.A.

Linton

Tracing

Interactive

Graphics

Programs

Proc

ACM

Symp

on

Interactive

Graphics

Frame

Triangles

Received

Processed

-LRB-

a

-RRB-

Triangles

950 1000 1050 1100

1150 1200 1250 1300

Frame

Are

a

-LRB-

b

-RRB-

Area

Frame

Triangles

Received

Processed

-LRB-

c

-RRB-

Tux

Triangles

950 1000 1050 1100

1150 1200 1250 1300

Frame

Are

a

-LRB-

d

-RRB-

Tux

Area

Frame

Triangles

Received

Processed

-LRB-

e

-RRB-

DIN

Triangles

Frame

Are

a

-LRB-

f

-RRB-

DIN

Area

Frame

Triangles

Received

Processed

-LRB-

g

-RRB-

AW

Triangles

Frame

Area

-LRB-

h

-RRB-

AW

Area

Frame

Triangles

Received

Processed

-LRB-

i

-RRB-

GRA

Triangles

Frame

Are

a

-LRB-

j

-RRB-

GRA

Area

Frame

Triangles

Received

Processed

-LRB-

k

-RRB-

ANL

Triangles

Frame

Are

a

-LRB-

l

-RRB-

ANL

Area

Figure

Triangle

and

area

statistics

for

the

GraalBench

components

-LSB-

-RSB-

Expert

Group

Mobile

Graphics

API

for

Java

TM

Micro

Edition

Available

at

-LSB-

-RSB-

The

Khronos

Group

OpenGL

ES

Overview

Available

at

-LSB-

-RSB-

Id

Software

Inc.

Quake

III

Available

at

-LSB-

-RSB-

ARM

Ltd.

ARM

Graphics

Solutions

Available

at

-LSB-

-RSB-

T.

Mitra

and

T.

Chiueh

Dynamic

Graphics

Workload

Characterization

and

the

Architectural

Implications

Proc

ACM/IEEE

Int

Symp

on

Microarchitecture

-LRB-

MICRO

-RRB-

pp.

-LSB-

-RSB-

Systems

in

Motion

VRMLView

Available

at

-LSB-

-RSB-

M.

Pichler

G.

Orasche

K.

Andrews

E.

Grossman

and

M.

McCahill

VRweb

a

Multi-System

VRML

Viewer

Proc

First

Symp

on

Virtual

Reality

Modeling

Language

San

Diego

California

United

States

pp.

-LSB-

-RSB-

The

Mesa

Project

The

Mesa

Graphics

Library

Available

at

-LSB-

-RSB-

Hawk

Software

GLTrace

Programming

Utility

Available

at

-LSB-

-RSB-

J.

Sohn

R.

Woo

and

H.J.

Yoo

Optimization

of

Portable

System

Architecture

for

Real-Time

Graphics

Proc

IEEE

Int

Symp

on

Circuits

and

Systems

-LRB-

ISCAS

-RRB-

Volume

May

pp

vol

-LSB-

-RSB-

SourceForge

spyGLass

an

OpenGL

Call

Tracer

and

Debugging

Tool

Available

at

-LSB-

-RSB-

SPEC

SPECviewperf

Available

at

-LSB-

-RSB-

Sunspire

Studios

Tux

Racer

Available

at

-LSB-

-RSB-

Portable

Research

Group

at

Korea

Advanced

Institute

of

Science

and

Technology

MobileGL

The

Standard

for

Embedded

Graphics

Available

at

ac.kr

html/main

mgl

defnition.htm

-LSB-

-RSB-

Stanford

University

GLSim

GLTrace

Available

at

http

-LSB-

-RSB-

Yonsei

University

Graphics

Accelerator

Group

B O O B I B O O B I O O O O O O O B I I O O O O O O O O O O O O O O O B I O O O O O B O O O O B I O O O O O O B I O O O O O O O O O O O O B B O O O O O O O O O O O O O O O O O O B I O O O O O O O B O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O B O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O B O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O B I B O O O B I O O O O O O O O B I O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O B B O O O O O O O O O B O O O O B O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O B I O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O B I I O O O O B I O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O B O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B I B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O B O O O O O O O B I B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O B O B I O B I O O O O O O O O B I I O O O O O B I O O B O O O O O O O B I B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O B B O O O O O B O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I B O O O O O O O O O O O O B I I O O O O O O O O O O B I I O O B I O O O B O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B O O O O O O O O O O B O O O O B O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O B O O O O O O O O O B I B O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B O O O B B O O O O O O O O O O O O O B B O O O O B I I O O O O B O O B I O O O B I O O O B O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O B O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O B O O O O O O B O O O O O O O O O O O O B O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O B O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B I B O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O B O O O O O O O B O O O O B O O O O O O O O B O O O O O O O O B O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B O O O O O O O O O O O O O O O O O B O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O B O O O O O B O O O O O O O O O O O O B O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O B I I O O O O O O O O O O B O O O B I I B O O O O O O O O O O O O O B I I B B O O O O O O O O O O O O O O O O B I O O O O O B I I O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B B O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O B I B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O B I B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O

mobile phones
triangles
pipeline
accelerators
3d graphics benchmarking
mobile environments
embedded 3d graphics
benchmark
mechanism
architecture
statistics
3d graphics applications
api
bottlenecks
graalbench
performance
3d graphics benchmarks
opengl
workload characterization
embedded systems
mobile devices
rasterization
3d graphics
workload
unit
measurement

transform and lighting
embedded 3d graphics architectures
real-time