|
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. |