blob: fd53d905570016b21f43f7500d9c138fde27bfca (
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
|
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:
Xorg’s DDX driver could leverage glamor-egl package to
create an egl context without any native X system. This
package can support every platform which has OpenGL and
gbm and drm libraries.
Now the xf86-intel-video driver uses glamor as one of its
option. When you build it with --enable-glamor, then it
will use glamor as its rendering enginee.
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 functional identical to
the normal 2D driver.
Where to get more information about the driver
----------------------------------------------
http://www.freedesktop.org/wiki/Software/Glamor
Mailing list for communication with users and developers of
glamor:
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.
|
