222 lines
6.0 KiB
HTML
222 lines
6.0 KiB
HTML
|
<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>
|