Ignore:
Timestamp:
May 5, 2011, 5:36:53 AM (15 years ago)
Author:
Dmitry A. Kuminov
Message:

trunk: Merged in qt 4.7.2 sources from branches/vendor/nokia/qt.

Location:
trunk
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • trunk

  • trunk/doc/src/platforms/emb-hardwareacceleration.qdocinc

    r561 r846  
    1        \section1 Hardware Acceleration
    2        
    3         When designing applications for embedded devices there is often a
    4         compromise between graphics effects and performance. On most
    5         devices, you cannot have both simply because the hardware needed
    6         for such operations just is not there. With a growing number of
    7         devices that use hardware dedicated to graphics operations there is
    8         less need to compromise.
    9        
    10         In addition to enabling dynamic graphics effects, there are two
    11         other benefits to using graphics acceleration. One is that graphics
    12         acceleration hardware is more power efficient than using the CPU.
    13         The reason for this is that the CPU might require a clock speed
    14         that is up to 20 times higher than the GPU, achieving the same
    15         results. E.g. a typical hardware accelerated mobile graphics unit
    16         can rasterize one or two bilinear texture fetches in one cycle,
    17         while a software implementation takes easily more than 20 cycles.
    18         Typical \e {System-on-a-chip} (SoC) graphics hardware generally have
    19         a much lower clock speed and memory bandwidth, and different level
    20         of acceleration than desktop GPUs. One example is that many GPUs
    21         leave out transformation and lighting from the graphics pipeline
    22         and only implements rasterization.
    23        
    24         Another reason to use a GPU is to offload the main CPU, either for
    25         power saving or to perform other operations in parallel. Often
    26         drawing speed with a GPU is not that much faster than a CPU but
    27         the clear benefit of using the GPU is to free up the CPU to perform
    28         other tasks which can be used to create a more responsive use
    29         experience.
    30        
    31         The key to writing good applications for devices is therefore to
    32         limit the wow factor down to what the target hardware can handle,
    33         and to take advantage of any graphics dedicated hardware. Qt
    34         provides several ways to both render advanced effects on the screen
    35         and speed up your application using hardware accelerated graphics.
    36        
    37         \tableofcontents
    38        
    39         \section2 Qt for Embedded Graphics pipeline
    40        
    41         Qt uses QPainter for all graphics operations. By using the same API
    42         regardless of platform, the code can be reused on different devices.
    43         QPainter use different paint engines implemented in the QPaintEngine API to
    44         do the actual painting.
    45        
    46         The QPaintEngine API provides paint engines for each window system and
    47         painting framework supported by Qt. In regards to Qt for Embedded, this
    48         also includes implementations for OpenGL ES versions 1.1 and 2.0, as well
    49         as OpenVG and DirectFB(Embedded Linux only).
    50        
    51         By using one of these paint engines, you will be able to improve the
    52         graphics performance of your Qt application. However, if the graphics
    53         operations used are not supported, this might as well be a trap, slowing
    54         down your application significantly. This all depends on what kind of
    55         graphics operations that are supported by the target devices hardware
    56         configuration.
    57        
    58         \image platformHWAcc.png
    59        
    60         The paint engine will direct all graphics operations supported by the
    61         devices hardware to the GPU, and from there they are sent to the
    62         framebuffer. Unsupported graphics operations falls back to the
    63         QRasterPaintEngine and are handled by the CPU before sent to the
    64         framebuffer. In the end, the operating system sends the paint updates off
    65         to the screen/display. The fallback operation is quite expensive in regards
    66         to memory consumption, and should be avoided.
    67        
    68         \section2 Hardware configuration requirements
    69        
    70         Before implementing any application using hardware acceleration, it is wise
    71         to get an overview of what kind of hardware accelerated graphics operations
    72         that are available for the target device.
    73        
    74         \note On devices with no hardware acceleration, Qt will use
    75         QRasterPaintEngine, which handles the acceleration using software. On
    76         devices supporting OpenGL ES, OpenVG or DirectFB(not supported by Windows
    77         CE), Qt will use the
    78         respective paint engines to accelerate painting. However, hardware
    79         configurations that only support a limited set of hardware acceleration
    80         features, might slow the application graphics down rather than speeding it
    81         up when using unsupported operations that must fall back to the raster
    82         engine.
    83        
    84         \section3 Different architectures
    85        
    86         Based on the architecture used in a device we can make a recommendation on
    87         which hardware acceleration techniques to use. There are mainly two
    88         different architectures on embedded devices. These are devices with a
    89         Unified Memory Architecture (UMA), and devices with dedicated graphics
    90         memory. Generally, high-end devices will have dedicated graphics memory.
    91         Low-end devices will just use system memory, sometimes reserving a memory
    92         region and sometimes not.
    93        
    94         In addition to this, we can categorize the devices into five types based on
    95         the different graphics operations supported by their hardware.
    96        
    97         \list 1
    98                 \o No support for graphics acceleration.
    99                 \o Support for blitter and alpha blending.
    100                 \o Support for path based 2D vector graphics.
    101                 \o Support for fixed function 3D graphics.
    102                 \o Support for programmable 3D graphics.
    103         \endlist
    104        
    105         Based on these characteristics the table below recommends which paint
    106         engines to use with the different types of hardware configurations.
    107        
    108         \section3 Recommended use of hardware acceleration based on hardware
    109        
    110         \table
    111                 \header
    112                         \o Type
    113                         \o UMA
    114                         \o Non-UMA
    115                 \row
    116                         \o \bold {None}
    117                         \o Qt Raster Engine
    118                         \o Qt Raster Engine
    119                 \row
    120                         \o \bold {Blitter}
    121                         \o DirectFB
    122                         \o DirectFB
    123                 \row
    124                         \o \bold {2D Vector}
    125                         \o OpenVG
    126                         \o OpenVG
    127                 \row
    128                         \o \bold {Fixed 3D}
    129                         \o OpenGL (ES) 1.x
    130                         \o OpenGL (ES) 1.x
    131                 \row
    132                         \o \bold {Programmable 3D}
    133                         \o OpenGL (ES) 2.x
    134                         \o OpenGL (ES) 2.x
    135         \endtable
    136        
    137         \note Since the DirectFB API is quite primitive, the raster paint engine
    138         handles most of the operations.
    139        
    140         \note Blitter and Alpha blending is currently not supported on Windows CE.
     1\section1 Hardware Acceleration
     2
     3When designing applications for embedded devices there is often a
     4compromise between graphics effects and performance. On most
     5devices, you cannot have both simply because the hardware needed
     6for such operations just is not there. With a growing number of
     7devices that use hardware dedicated to graphics operations there is
     8less need to compromise.
     9
     10In addition to enabling dynamic graphics effects, there are two
     11other benefits to using graphics acceleration. One is that graphics
     12acceleration hardware is more power efficient than using the CPU.
     13The reason for this is that the CPU might require a clock speed
     14that is up to 20 times higher than the GPU, achieving the same
     15results. E.g. a typical hardware accelerated mobile graphics unit
     16can rasterize one or two bilinear texture fetches in one cycle,
     17while a software implementation takes easily more than 20 cycles.
     18Typical \e {System-on-a-chip} (SoC) graphics hardware generally have
     19a much lower clock speed and memory bandwidth, and different level
     20of acceleration than desktop GPUs. One example is that many GPUs
     21leave out transformation and lighting from the graphics pipeline
     22and only implements rasterization.
     23
     24Another reason to use a GPU is to offload the main CPU, either for
     25power saving or to perform other operations in parallel. Often
     26drawing speed with a GPU is not that much faster than a CPU but
     27the clear benefit of using the GPU is to free up the CPU to perform
     28other tasks which can be used to create a more responsive use
     29experience.
     30
     31The key to writing good applications for devices is therefore to
     32limit the wow factor down to what the target hardware can handle,
     33and to take advantage of any graphics dedicated hardware. Qt
     34provides several ways to both render advanced effects on the screen
     35and speed up your application using hardware accelerated graphics.
     36
     37\tableofcontents
     38
     39\section2 Qt for Embedded Graphics pipeline
     40
     41Qt uses QPainter for all graphics operations. By using the same API
     42regardless of platform, the code can be reused on different devices.
     43QPainter use different paint engines implemented in the QPaintEngine API to
     44do the actual painting.
     45
     46The QPaintEngine API provides paint engines for each window system and
     47painting framework supported by Qt. In regards to Qt for Embedded, this
     48also includes implementations for OpenGL ES versions 1.1 and 2.0, as well
     49as OpenVG and DirectFB(Embedded Linux only).
     50
     51By using one of these paint engines, you will be able to improve the
     52graphics performance of your Qt application. However, if the graphics
     53operations used are not supported, this might as well be a trap, slowing
     54down your application significantly. This all depends on what kind of
     55graphics operations that are supported by the target devices hardware
     56configuration.
     57
     58\image platformHWAcc.png
     59
     60The paint engine will direct all graphics operations supported by the
     61devices hardware to the GPU, and from there they are sent to the
     62framebuffer. Unsupported graphics operations falls back to the
     63QRasterPaintEngine and are handled by the CPU before sent to the
     64framebuffer. In the end, the operating system sends the paint updates off
     65to the screen/display. The fallback operation is quite expensive in regards
     66to memory consumption, and should be avoided.
     67
     68\section2 Hardware configuration requirements
     69
     70Before implementing any application using hardware acceleration, it is wise
     71to get an overview of what kind of hardware accelerated graphics operations
     72that are available for the target device.
     73
     74\note On devices with no hardware acceleration, Qt will use
     75QRasterPaintEngine, which handles the acceleration using software. On
     76devices supporting OpenGL ES, OpenVG or DirectFB(not supported by Windows
     77CE), Qt will use the
     78respective paint engines to accelerate painting. However, hardware
     79configurations that only support a limited set of hardware acceleration
     80features, might slow the application graphics down rather than speeding it
     81up when using unsupported operations that must fall back to the raster
     82engine.
     83
     84\section3 Different architectures
     85
     86Based on the architecture used in a device we can make a recommendation on
     87which hardware acceleration techniques to use. There are mainly two
     88different architectures on embedded devices. These are devices with a
     89Unified Memory Architecture (UMA), and devices with dedicated graphics
     90memory. Generally, high-end devices will have dedicated graphics memory.
     91Low-end devices will just use system memory, sometimes reserving a memory
     92region and sometimes not.
     93
     94In addition to this, we can categorize the devices into five types based on
     95the different graphics operations supported by their hardware.
     96
     97\list 1
     98    \o No support for graphics acceleration.
     99    \o Support for blitter and alpha blending.
     100    \o Support for path based 2D vector graphics.
     101    \o Support for fixed function 3D graphics.
     102    \o Support for programmable 3D graphics.
     103\endlist
     104
     105Based on these characteristics the table below recommends which paint
     106engines to use with the different types of hardware configurations.
     107
     108\section3 Recommended use of hardware acceleration based on hardware
     109
     110\table
     111    \header
     112        \o Type
     113        \o UMA
     114        \o Non-UMA
     115    \row
     116        \o \bold {None}
     117        \o Qt Raster Engine
     118        \o Qt Raster Engine
     119    \row
     120        \o \bold {Blitter}
     121        \o DirectFB
     122        \o DirectFB
     123    \row
     124        \o \bold {2D Vector}
     125        \o OpenVG
     126        \o OpenVG
     127    \row
     128        \o \bold {Fixed 3D}
     129        \o OpenGL (ES) 1.x
     130        \o OpenGL (ES) 1.x
     131    \row
     132        \o \bold {Programmable 3D}
     133        \o OpenGL (ES) 2.x
     134        \o OpenGL (ES) 2.x
     135\endtable
     136
     137\note Since the DirectFB API is quite primitive, the raster paint engine
     138handles most of the operations.
     139
     140\note Blitter and Alpha blending is currently not supported on Windows CE.
Note: See TracChangeset for help on using the changeset viewer.