diff options
Diffstat (limited to 'doc/src/platforms')
| -rw-r--r-- | doc/src/platforms/emb-hardwareacceleration.qdocinc | 280 |
1 files changed, 140 insertions, 140 deletions
diff --git a/doc/src/platforms/emb-hardwareacceleration.qdocinc b/doc/src/platforms/emb-hardwareacceleration.qdocinc index fb00e09c29..83ecef5148 100644 --- a/doc/src/platforms/emb-hardwareacceleration.qdocinc +++ b/doc/src/platforms/emb-hardwareacceleration.qdocinc @@ -1,140 +1,140 @@ - \section1 Hardware Acceleration - - When designing applications for embedded devices there is often a - compromise between graphics effects and performance. On most - devices, you cannot have both simply because the hardware needed - for such operations just is not there. With a growing number of - devices that use hardware dedicated to graphics operations there is - less need to compromise. - - In addition to enabling dynamic graphics effects, there are two - other benefits to using graphics acceleration. One is that graphics - acceleration hardware is more power efficient than using the CPU. - The reason for this is that the CPU might require a clock speed - that is up to 20 times higher than the GPU, achieving the same - results. E.g. a typical hardware accelerated mobile graphics unit - can rasterize one or two bilinear texture fetches in one cycle, - while a software implementation takes easily more than 20 cycles. - Typical \e {System-on-a-chip} (SoC) graphics hardware generally have - a much lower clock speed and memory bandwidth, and different level - of acceleration than desktop GPUs. One example is that many GPUs - leave out transformation and lighting from the graphics pipeline - and only implements rasterization. - - Another reason to use a GPU is to offload the main CPU, either for - power saving or to perform other operations in parallel. Often - drawing speed with a GPU is not that much faster than a CPU but - the clear benefit of using the GPU is to free up the CPU to perform - other tasks which can be used to create a more responsive use - experience. - - The key to writing good applications for devices is therefore to - limit the wow factor down to what the target hardware can handle, - and to take advantage of any graphics dedicated hardware. Qt - provides several ways to both render advanced effects on the screen - and speed up your application using hardware accelerated graphics. - - \tableofcontents - - \section2 Qt for Embedded Graphics pipeline - - Qt uses QPainter for all graphics operations. By using the same API - regardless of platform, the code can be reused on different devices. - QPainter use different paint engines implemented in the QPaintEngine API to - do the actual painting. - - The QPaintEngine API provides paint engines for each window system and - painting framework supported by Qt. In regards to Qt for Embedded, this - also includes implementations for OpenGL ES versions 1.1 and 2.0, as well - as OpenVG and DirectFB(Embedded Linux only). - - By using one of these paint engines, you will be able to improve the - graphics performance of your Qt application. However, if the graphics - operations used are not supported, this might as well be a trap, slowing - down your application significantly. This all depends on what kind of - graphics operations that are supported by the target devices hardware - configuration. - - \image platformHWAcc.png - - The paint engine will direct all graphics operations supported by the - devices hardware to the GPU, and from there they are sent to the - framebuffer. Unsupported graphics operations falls back to the - QRasterPaintEngine and are handled by the CPU before sent to the - framebuffer. In the end, the operating system sends the paint updates off - to the screen/display. The fallback operation is quite expensive in regards - to memory consumption, and should be avoided. - - \section2 Hardware configuration requirements - - Before implementing any application using hardware acceleration, it is wise - to get an overview of what kind of hardware accelerated graphics operations - that are available for the target device. - - \note On devices with no hardware acceleration, Qt will use - QRasterPaintEngine, which handles the acceleration using software. On - devices supporting OpenGL ES, OpenVG or DirectFB(not supported by Windows - CE), Qt will use the - respective paint engines to accelerate painting. However, hardware - configurations that only support a limited set of hardware acceleration - features, might slow the application graphics down rather than speeding it - up when using unsupported operations that must fall back to the raster - engine. - - \section3 Different architectures - - Based on the architecture used in a device we can make a recommendation on - which hardware acceleration techniques to use. There are mainly two - different architectures on embedded devices. These are devices with a - Unified Memory Architecture (UMA), and devices with dedicated graphics - memory. Generally, high-end devices will have dedicated graphics memory. - Low-end devices will just use system memory, sometimes reserving a memory - region and sometimes not. - - In addition to this, we can categorize the devices into five types based on - the different graphics operations supported by their hardware. - - \list 1 - \o No support for graphics acceleration. - \o Support for blitter and alpha blending. - \o Support for path based 2D vector graphics. - \o Support for fixed function 3D graphics. - \o Support for programmable 3D graphics. - \endlist - - Based on these characteristics the table below recommends which paint - engines to use with the different types of hardware configurations. - - \section3 Recommended use of hardware acceleration based on hardware - - \table - \header - \o Type - \o UMA - \o Non-UMA - \row - \o \bold {None} - \o Qt Raster Engine - \o Qt Raster Engine - \row - \o \bold {Blitter} - \o DirectFB - \o DirectFB - \row - \o \bold {2D Vector} - \o OpenVG - \o OpenVG - \row - \o \bold {Fixed 3D} - \o OpenGL (ES) 1.x - \o OpenGL (ES) 1.x - \row - \o \bold {Programmable 3D} - \o OpenGL (ES) 2.x - \o OpenGL (ES) 2.x - \endtable - - \note Since the DirectFB API is quite primitive, the raster paint engine - handles most of the operations. - - \note Blitter and Alpha blending is currently not supported on Windows CE. +\section1 Hardware Acceleration + +When designing applications for embedded devices there is often a +compromise between graphics effects and performance. On most +devices, you cannot have both simply because the hardware needed +for such operations just is not there. With a growing number of +devices that use hardware dedicated to graphics operations there is +less need to compromise. + +In addition to enabling dynamic graphics effects, there are two +other benefits to using graphics acceleration. One is that graphics +acceleration hardware is more power efficient than using the CPU. +The reason for this is that the CPU might require a clock speed +that is up to 20 times higher than the GPU, achieving the same +results. E.g. a typical hardware accelerated mobile graphics unit +can rasterize one or two bilinear texture fetches in one cycle, +while a software implementation takes easily more than 20 cycles. +Typical \e {System-on-a-chip} (SoC) graphics hardware generally have +a much lower clock speed and memory bandwidth, and different level +of acceleration than desktop GPUs. One example is that many GPUs +leave out transformation and lighting from the graphics pipeline +and only implements rasterization. + +Another reason to use a GPU is to offload the main CPU, either for +power saving or to perform other operations in parallel. Often +drawing speed with a GPU is not that much faster than a CPU but +the clear benefit of using the GPU is to free up the CPU to perform +other tasks which can be used to create a more responsive use +experience. + +The key to writing good applications for devices is therefore to +limit the wow factor down to what the target hardware can handle, +and to take advantage of any graphics dedicated hardware. Qt +provides several ways to both render advanced effects on the screen +and speed up your application using hardware accelerated graphics. + +\tableofcontents + +\section2 Qt for Embedded Graphics pipeline + +Qt uses QPainter for all graphics operations. By using the same API +regardless of platform, the code can be reused on different devices. +QPainter use different paint engines implemented in the QPaintEngine API to +do the actual painting. + +The QPaintEngine API provides paint engines for each window system and +painting framework supported by Qt. In regards to Qt for Embedded, this +also includes implementations for OpenGL ES versions 1.1 and 2.0, as well +as OpenVG and DirectFB(Embedded Linux only). + +By using one of these paint engines, you will be able to improve the +graphics performance of your Qt application. However, if the graphics +operations used are not supported, this might as well be a trap, slowing +down your application significantly. This all depends on what kind of +graphics operations that are supported by the target devices hardware +configuration. + +\image platformHWAcc.png + +The paint engine will direct all graphics operations supported by the +devices hardware to the GPU, and from there they are sent to the +framebuffer. Unsupported graphics operations falls back to the +QRasterPaintEngine and are handled by the CPU before sent to the +framebuffer. In the end, the operating system sends the paint updates off +to the screen/display. The fallback operation is quite expensive in regards +to memory consumption, and should be avoided. + +\section2 Hardware configuration requirements + +Before implementing any application using hardware acceleration, it is wise +to get an overview of what kind of hardware accelerated graphics operations +that are available for the target device. + +\note On devices with no hardware acceleration, Qt will use +QRasterPaintEngine, which handles the acceleration using software. On +devices supporting OpenGL ES, OpenVG or DirectFB(not supported by Windows +CE), Qt will use the +respective paint engines to accelerate painting. However, hardware +configurations that only support a limited set of hardware acceleration +features, might slow the application graphics down rather than speeding it +up when using unsupported operations that must fall back to the raster +engine. + +\section3 Different architectures + +Based on the architecture used in a device we can make a recommendation on +which hardware acceleration techniques to use. There are mainly two +different architectures on embedded devices. These are devices with a +Unified Memory Architecture (UMA), and devices with dedicated graphics +memory. Generally, high-end devices will have dedicated graphics memory. +Low-end devices will just use system memory, sometimes reserving a memory +region and sometimes not. + +In addition to this, we can categorize the devices into five types based on +the different graphics operations supported by their hardware. + +\list 1 + \o No support for graphics acceleration. + \o Support for blitter and alpha blending. + \o Support for path based 2D vector graphics. + \o Support for fixed function 3D graphics. + \o Support for programmable 3D graphics. +\endlist + +Based on these characteristics the table below recommends which paint +engines to use with the different types of hardware configurations. + +\section3 Recommended use of hardware acceleration based on hardware + +\table + \header + \o Type + \o UMA + \o Non-UMA + \row + \o \bold {None} + \o Qt Raster Engine + \o Qt Raster Engine + \row + \o \bold {Blitter} + \o DirectFB + \o DirectFB + \row + \o \bold {2D Vector} + \o OpenVG + \o OpenVG + \row + \o \bold {Fixed 3D} + \o OpenGL (ES) 1.x + \o OpenGL (ES) 1.x + \row + \o \bold {Programmable 3D} + \o OpenGL (ES) 2.x + \o OpenGL (ES) 2.x +\endtable + +\note Since the DirectFB API is quite primitive, the raster paint engine +handles most of the operations. + +\note Blitter and Alpha blending is currently not supported on Windows CE. |