Graphics -Hardware Acceleration

Graphics -Hardware AccelerationThis topic describes some of the issues surrounding the use of -graphics hardware to improve graphics performance. It also provides a summary -of the components that device creators need to adapt to take advantage of -graphics hardware. -

Background

Graphics acceleration hardware

A -graphics accelerator or Graphics Processing Unit (GPU) is a dedicated hardware -processor that works in parallel with the main processor (CPU). By relieving -the CPU of highly intensive graphics processing, a GPU makes it is possible -to achieve sophisticated screen displays (such as video, animated graphics -and 3D games) without compromising other aspects of performance.

Animations

Animation -involves transferring and manipulating large amounts of data (stored as bitmaps -or instructions) from one area of memory and putting them into another (the -screen buffer). Frame rates may be between 10 and 30 frames per second (depending -on requirements and sources).

Composition

Manufacturers -of smartphones face the complexity of displaying on the screen a mixture of -different types of content, such as streaming video, the camera viewfinder -and regular UI elements with animated icons. These different types of content -come from different places—such as multimedia sources (streaming video), camera -hardware, the Window Server and EGL (3D and vector graphics). The different -types of content are displayed in different areas of the screen and are updated -by different processes. The graphics system must be capable not only of creating -sophisticated graphical output from each source simultaneously but also of -composing (compositing) them at up to 30 frames per second. For an introduction -to how ScreenPlay handles this challenge, see Graphics -Composition.

Optimization

GPUs work best when -they do so uninterrupted. They usually have a 'long processing pipe' (a lot -of data cached in memory) and flushing it or allowing it to empty reduces -effectiveness. This can be avoided by avoiding the following:

Context switching. -The working data (such as color information, vertex positions, transformations -and textures) is known as the context. If more than one application -wants to use the processor at the same time, the processor must swap between -them. This involves the processor saving the context from one application, -flushing its buffers, and loading the context from the next. Context switching -is time consuming and disruptive.
Copying and reformatting -data. Changing the format and copying pixel data involves time and memory. -If the GPU and CPU cannot share memory and data formats, much time, processing -power and memory is required to copy and convert data.

ScreenPlay avoids context switching and reformatting and copying -data wherever possible.

Hardware variety

The combination -of hardware acceleration, animation and composition would be a substantial -challenge in a fixed, dedicated hardware architecture. The Symbian platform, -however, is designed to operate on a variety of hardware architectures, only -some of which are capable of graphics acceleration and processing. The Symbian -graphics subsystem can be customized to take advantage of a variety graphics -processing hardware. Customization is via 'back end' components which do not -affect the public API.

The hardware adaptation components

Here we provide -information about which graphics components device creators can adapt or replace. -Components that can be adapted or replaced to suit the hardware are generally -called adaptations. Adaptable and replaceable components that do not -depend on the hardware are called customizations and are indicated -by an asterisk (*) in the following table.

The details vary depending -on whether the ScreenPlay or non-ScreenPlay variant -is in use.

- - - -ScreenPlay -Non-ScreenPlay - - - - -OpenGLES Implementation -OpenGLES Implementation - - -OpenVG Implementation -OpenVG Implementation - - -EGL Implementation -EGL Implementation - - -Screen Driver -Screen Driver - - -Extended Bitmap -Rasterizer Plug-in -Extended Bitmap -Rasterizer Plug-in - - -DirectGDI Adaptation - - - -Graphics Resource -Adaptation - - - - -OpenWF Composition -Engine - - - -Surface Manager - - - -Surface Update - - - -Render Stages* - - - - -

-Graphics -Concepts -The ScreenPlay -Architecture -The Non-ScreenPlay -Architecture + + + + + +Graphics +Hardware AccelerationThis topic describes some of the issues surrounding the use of +graphics hardware to improve graphics performance. It also provides a summary +of the components that device creators need to adapt to take advantage of +graphics hardware. +

Background

Graphics acceleration hardware

A +graphics accelerator or Graphics Processing Unit (GPU) is a dedicated hardware +processor that works in parallel with the main processor (CPU). By relieving +the CPU of highly intensive graphics processing, a GPU makes it is possible +to achieve sophisticated screen displays (such as video, animated graphics +and 3D games) without compromising other aspects of performance.

Animations

Animation +involves transferring and manipulating large amounts of data (stored as bitmaps +or instructions) from one area of memory and putting them into another (the +screen buffer). Frame rates may be between 10 and 30 frames per second (depending +on requirements and sources).

Composition

Manufacturers +of smartphones face the complexity of displaying on the screen a mixture of +different types of content, such as streaming video, the camera viewfinder +and regular UI elements with animated icons. These different types of content +come from different places—such as multimedia sources (streaming video), camera +hardware, the Window Server and EGL (3D and vector graphics). The different +types of content are displayed in different areas of the screen and are updated +by different processes. The graphics system must be capable not only of creating +sophisticated graphical output from each source simultaneously but also of +composing (compositing) them at up to 30 frames per second. For an introduction +to how ScreenPlay handles this challenge, see Graphics +Composition.

Optimization

GPUs work best when +they do so uninterrupted. They usually have a 'long processing pipe' (a lot +of data cached in memory) and flushing it or allowing it to empty reduces +effectiveness. This can be avoided by avoiding the following:

Context switching. +The working data (such as color information, vertex positions, transformations +and textures) is known as the context. If more than one application +wants to use the processor at the same time, the processor must swap between +them. This involves the processor saving the context from one application, +flushing its buffers, and loading the context from the next. Context switching +is time consuming and disruptive.
Copying and reformatting +data. Changing the format and copying pixel data involves time and memory. +If the GPU and CPU cannot share memory and data formats, much time, processing +power and memory is required to copy and convert data.

ScreenPlay avoids context switching and reformatting and copying +data wherever possible.

Hardware variety

The combination +of hardware acceleration, animation and composition would be a substantial +challenge in a fixed, dedicated hardware architecture. The Symbian platform, +however, is designed to operate on a variety of hardware architectures, only +some of which are capable of graphics acceleration and processing. The Symbian +graphics subsystem can be customized to take advantage of a variety graphics +processing hardware. Customization is via 'back end' components which do not +affect the public API.

The hardware adaptation components

Here we provide +information about which graphics components device creators can adapt or replace. +Components that can be adapted or replaced to suit the hardware are generally +called adaptations. Adaptable and replaceable components that do not +depend on the hardware are called customizations and are indicated +by an asterisk (*) in the following table.

The details vary depending +on whether the ScreenPlay or non-ScreenPlay variant +is in use.

+ + + +ScreenPlay +Non-ScreenPlay + + + + +OpenGLES Implementation +OpenGLES Implementation + + +OpenVG Implementation +OpenVG Implementation + + +EGL Implementation +EGL Implementation + + +Screen Driver +Screen Driver + + +Extended Bitmap +Rasterizer Plug-in +Extended Bitmap +Rasterizer Plug-in + + +DirectGDI Adaptation + + + +Graphics Resource +Adaptation + + + + +OpenWF Composition +Engine + + + +Surface Manager + + + +Surface Update + + + +Render Stages* + + + + +

+Graphics +Concepts +The ScreenPlay +Architecture +The Non-ScreenPlay +Architecture

\ No newline at end of file