1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
|
'''OpenGL extension QCOM.tiled_rendering
This module customises the behaviour of the
OpenGL.raw.GLES2.QCOM.tiled_rendering to provide a more
Python-friendly API
Overview (from the spec)
In the handheld graphics space, a typical challenge is achieving efficient
rendering performance given the different characteristics of the various
types of graphics memory. Some types of memory ("slow" memory) are less
expensive but have low bandwidth, higher latency, and/or higher power
consumption, while other types ("fast" memory) are more expensive but have
higher bandwidth, lower latency, and/or lower power consumption. In many
cases, it is more efficient for a graphics processing unit (GPU) to render
directly to fast memory, but at most common display resolutions it is not
practical for a device to contain enough fast memory to accommodate both the
full color and depth/stencil buffers (the frame buffer). In some devices,
this problem can be addressed by providing both types of memory; a large
amount of slow memory that is sufficient to store the entire frame buffer,
and a small, dedicated amount of fast memory that allows the GPU to render
with optimal performance. The challenge lies in finding a way for the GPU
to render to fast memory when it is not large enough to contain the actual
frame buffer.
One approach to solving this problem is to design the GPU and/or driver
using a tiled rendering architecture. With this approach the render target
is subdivided into a number of individual tiles, which are sized to fit
within the available amount of fast memory. Under normal operation, the
entire scene will be rendered to each individual tile using a multi-pass
technique, in which primitives that lie entirely outside of the tile being
rendered are trivially discarded. After each tile has been rendered, its
contents are saved out to the actual frame buffer in slow memory (a process
referred to as the "resolve"). The resolve introduces significant overhead,
both for the CPU and the GPU. However, even with this additional overhead,
rendering using this method is usually more efficient than rendering
directly to slow memory.
This extension allows the application to specify a rectangular tile
rendering area and have full control over the resolves for that area. The
information given to the driver through this API can be used to perform
various optimizations in the driver and hardware. One example optimization
is being able to reduce the size or number of the resolves. Another
optimization might be to reduce the number of passes needed in the tiling
approach mentioned above. Even traditional rendering GPUs that don't use
tiles may benefit from this extension depending on their implemention of
certain common GPU operations.
One typical use case could involve an application only rendering to select
portions of the render target using this technique (which shall be referred
to as "application tiling"), leaving all other portions of the render target
untouched. Therefore, in order to preserve the contents of the untouched
portions of the render target, the application must request an EGL (or other
context management API) configuration with a non-destructive swap. A
destructive swap may only be used safely if the application renders to the
entire area of the render target during each frame (otherwise the contents
of the untouched portions of the frame buffer will be undefined).
Additionally, care must be taken to avoid the cost of mixing rendering with
and without application tiling within a single frame. Rendering without
application tiling ("normal" rendering) is most efficient when all of the
rendering for the entire scene can be encompassed within a single resolve.
If any portions of the scene are rendered prior to that resolve (such as via
a prior resolve, or via application tiling), then that resolve becomes much
more heavyweight. When this occurs, prior to rendering each tile the fast
memory must be populated with the existing contents of the frame buffer
region corresponding to that tile. This operation can double the cost of
resolves, so it is recommended that applications avoid mixing application
tiling and normal rendering within a single frame. If both rendering
methods must be used in the same frame, then the most efficient approach is
to perform all normal rendering first, followed by rendering done with
application tiling. An implicit resolve will occur (if needed) at the start
of application tiling, so any pending normal rendering operations will be
flushed at the time application tiling is initiated. This extension
provides interfaces for the application to communicate to the driver whether
or not rendering done with application tiling depends on the existing
contents of the specified tile, and whether or not the rendered contents of
the specified tile need to be preserved upon completion. This mechanism can
be used to obtain optimal performance, e.g. when the application knows that
every pixel in a tile will be completely rendered or when the resulting
contents of the depth/stencil buffers do not need to be preserved.
The official definition of this extension is available here:
http://www.opengl.org/registry/specs/QCOM/tiled_rendering.txt
'''
from OpenGL import platform, constant, arrays
from OpenGL import extensions, wrapper
import ctypes
from OpenGL.raw.GLES2 import _types, _glgets
from OpenGL.raw.GLES2.QCOM.tiled_rendering import *
from OpenGL.raw.GLES2.QCOM.tiled_rendering import _EXTENSION_NAME
def glInitTiledRenderingQCOM():
'''Return boolean indicating whether this extension is available'''
from OpenGL import extensions
return extensions.hasGLExtension( _EXTENSION_NAME )
### END AUTOGENERATED SECTION
|
