summaryrefslogtreecommitdiff
path: root/README
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.