blob: 0034af8f739373e088b65be709e652405f12ab3e (
plain)
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
100
101
102
103
104
105
106
107
|
glamor
Open-source X.org graphics common driver based on GL library.
What is glamor
------------------------
The glamor module is an open-source 2D graphics common driver for
the X Window System as implemented by X.org. It supports a variety of
graphics chipsets which have OpenGL/EGL/GBM supports.
It’s a GL-based rendering acceleration library for X server only:
It uses normal texture to represent a drawable pixmap
if possible.
It calls GL functions to render to the texture directly.
It consists of two packages:
glamor : Rendering library. All the rendering functions
are implemented in this package.
glamor-egl : EGL support library. This package provides
functions to create and initialize OpenGL/EGL context.
It’s somehow hardware independently. And could be a building
block of any X server’s DDX driver:
Xephyr or any other X-in-X server could use glamor to
acclerate the rendering if the hostX has glx support.
Xorg’s DDX driver could leverage glamor-egl package to
create a egl context without any native X system. This
package can support every platform which has OpenGL and
gbm and drm libraries.
Why glamor
----------------------------------------------
Basiclly, two intentions come to my mind of why we want to
develop glamor.
1. Graphic device has powerful 3D capability. To use 3D function
to accelerate 2D rendering is possible and many drivers already
do so. OpenGL provides a more convenient and standard interface
to leverage GFX device’s 3D power. It would be better to call
OpenGL directly rather than manually write 3D pipeline control
code for each different GFX device.
2. We have heard of complains about why we need to develop two
version drivers for a single graphic device for a long time.
One is for mesa’s DRI driver and the other is for 2D DDX driver.
One of glamor’s purpose is to eliminate the latter one.
How glamor works
----------------------------------------------
One prerequisite is that Xorg’s upper layer never access a
drawable directly. It always use low level DDX functions to
handle rendering.
All DDX functions access those drawables through two methods:
First method is to use DRM to map the drawable to a virtual
memory buffer, and then use libfb to access it directly.
In many cases, this way is the fallback path.
Second method is to setup appropriate 2D or 3D pipeline
according to the rendering request. Normally, it will prepare
a serial of hardware dependent command, and then upload the
command to the GFX device through DRM interface.
Glamor just providess the third access method:
Each pixmap has a normal texture object. Bind the texture
object to a frame buffer object. Writing shaders according
to the rendering type and then call GL functions to render
to the texture directly.
Eventually, the DRI driver in the openGL implementation (mesa)
will setup appropriate 2D or 3D pipeline to perform the rendering
operation. Functionally, it should be identical to the normal
2D driver.
Where to get more information about the driver
----------------------------------------------
TBD.
Documentation specific to the glamor common module including
possible configuration options for the xorg.conf file can be found in
the glamor(4) manual page. After installing the module this
documentation can be read with the following command:
man glamor
Mailing list for communication with users and developers of
glamor:
TBD
Note: Subscription is required before posting, but anyone is
free to subscribe. See instructions (and archives) here:
http://lists.freedesktop.org/mailman/listinfo/glamor
To report bugs encountered with the driver, see:
TBD.
To see bugs that are targeted to be fixed in the next release:
TBD.
|
