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
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
|
<HTML>
<TITLE>Writing Mesa Device Drivers</TITLE>
<BODY text="#000000" bgcolor="#55bbff" link="#111188">
<center><h1>Writing Mesa Device Drivers</h1></center>
<h2>Introduction</h2>
<p>
Several different classes of drivers can be identified:
</p>
<ul>
<li><b>100% Software Driver</b> -
a software driver that does not utilize accelerated graphics hardware.
Such a driver will basically just write (and read) pixel values to the
computer's frame buffer or a malloc'd color buffer.
Examples include the X11/XMesa driver, the Windows driver and OSMesa.
</li>
<br>
<li><b>Hardware Rasterization Driver</b> -
for graphics hardware that implements accelerated point/line/triangle
rasterization, but relies on core Mesa for vertex transformation.
Examples include the DRI 3Dfx, Matrox, and Rage 128 drivers.
</li>
<br>
<li><b>Hardware Transformation and Rasterization Driver</b> -
for graphics hardware that implements accelerated rasterization and vertex
transformation.
Examples include the DRI Radeon and R200 drivers.
</li>
</ul>
<p>
Each class of driver builds on the functionality of the preceeding one.
For example, a hardware rasterization driver may need to fall back to
software rasterization when a particular OpenGL state combination is set
but not supported by the hardware (perhaps smooth, stippled, textured
triangles).
</p>
<p>
Likewise, a hardware transformation driver might need to fall back to
software-based transformation when a particular, seldom-used lighting
mode is enabled.
</p>
<h2>Getting Started</h2>
<p>
The best way to get started writing a new driver is to find an existing
driver similar to what you plan to implement, and then study it.
</p>
<p>
It's not feasible for this document to explain every detail of writing
a driver.
The minute details can be gleaned by looking at existing drivers.
This document focuses on the high-level concepts and will perhaps expand
on the details in the future.
</p>
<p>
For examples of 100% software drivers, the OSMesa and XMesa (fake/stand-alone
GLX) drivers are the best examples.
</p>
<p>
For examples of hardware drivers, the DRI Radeon and R200 drivers are good
examples.
</p>
<h2>Programming API vs. Drivers</h2>
<p>
There are two aspects to a Mesa device driver:
</p>
<ul>
<li><b>Public programming API</b> -
this is the interface which application programmers use.
Examples are the GLX, WGL and OSMesa interfaces.
If you're developing a device driver for a new operating system or
window system you'll have to design and implement an <em>OpenGL glue</em>
interface similar to these.
This interface will, in turn, communicate with the internal driver code.
</li>
<br>
<li><b>Private/internal driver code</b> -
this is the code which (effectively) translates OpenGL API calls into
rendering operations.
The device driver must manage hardware resources, track OpenGL state
and implement or dispatch the fundamental rendering operations such as
point, line, triangle and image rendering.
</li>
</ul>
<p>
The remainder of this document will focus on the later part.
Furthermore, we'll use the GLX interface for examples.
</p>
<p>
In the case of the DRI drivers, the public GLX interface is contained in
the <b>libGL.so</b> library.
libGL.so, in turn, dynamically loads one of the DRI drivers (such as
radeon_dri.so).
Both libGL.so and the driver modules talk to the X window system via the
DRI extension.
Furthermore, the driver modules interface to the graphics hardware with
the help of a kernel module and the conventional 2D X server driver.
</p>
<h2>Software Driver Overview</h2>
<p>
A software driver is primarily concerned with writing pixel values to the
system's color buffer (and reading them back).
The color buffers might be window canvases (typically the front
color buffer) and/or off-screen image buffers (typically the back color
buffer).
The depth, stencil and accumulation buffers will be implemented within
core Mesa.
</p>
<p>
The software driver must also be concerned with allocation and deallocation
of rendering contexts, frame buffers and pixel formats (visuals).
</p>
<h3>Rendering Contexts</h3>
<p>
The glue interface will always have a function for creating new rendering
contexts (such as glXCreateContext).
The device driver must have a function which allocates and initializes
a device-specific rendering context.
</p>
<h3>Frame Buffers</h3>
<p>
The <em>frame buffer</em> can either be a screen region defined by a window
or the entire screen.
</p>
<p>
In either case, the device driver must implement functions for allocating,
initializing and managing frame buffers.
<p>
<h3>Spans</h3>
<p>
The fundamental rendering operation is to write (and read)
<em>spans</em> of pixels to the front / back color buffers.
A span is a horizontal array of pixel colors with an array of mask
flags. The span begins at a particular (x,y) screen coordinate,
extends for N pixels, describes N RGBA colors (or color indexes) and
has an array of N boolean flags indicating which pixels to write and skip.
<p>
<h3>Miscellaneous functions</h3>
<p>
Additionally, a software driver will typically have functions for
binding rendering contexts to frame buffers (via glXMakeCurrent),
swapping color buffers (via glXSwapBuffers), synchronization
(via glFlush/glFinish) and queries (via glGetString).
</p>
<h3>Optimizations</h3>
<p>
A software driver might implement optimized routines for drawing lines
and triangles for common cases (such as smooth shading with depth-testing).
Then, the span functions can be bypassed for a little extra speed.
The OSMesa and XMesa drivers have examples of this.
</p>
<h2>Hardware Driver Overview</h2>
<p>
To do...
</p>
<h2>OOP-Style Inheritance and Specialization</h2>
<p>
Even though Mesa and most device drivers are written in C, object oriented
programming principles are used in several places.
</p>
<h3>Rendering Contexts</h3>
<p>
Every Mesa device driver will need to define a device-specific rendering
context structure.
</p>
<h2>State Tracking</h2>
</BODY>
</HTML>
|
