diff -urN /tmp/wiki.V9dGLk/wiki/text/Building /home/groups/d/dr/dri/wiki/text/Building
--- /tmp/wiki.V9dGLk/wiki/text/Building 2004-05-19 02:35:16.000000000 -0700
+++ /home/groups/d/dr/dri/wiki/text/Building 2004-05-20 16:55:38.000000000 -0700
@@ -241,6 +241,12 @@
* Gentoo users only need to make sure `xfree` or `xorg-x11` have already been emerged.
+==== Requires /usr/X11R6/lib/libXau.a ====
+
+The libXau from DRI trunk CVS tree is non-existant. Instead, the build links against your system's existing `/usr/X11R6/lib/libXau.a`. This means you need to have an X server installed before you try to build DRI.
+
+"The official word is I'm about to open a [http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=652 bug] about it but that the problem will eventually go away when we stop building DRI from the X tree" (ajax @ freenode/#dri)
+
==== Compilation fails when building the kernel modules ====
When building the kernel modules, the compilation might fail for some modules. In a recent CVS snapshot, I got the following:
@@ -256,7 +262,7 @@
make[2]: *** [savage_drv.o] Error 1
}}}
-You can avoid this problem by only building the modules you need. See the DRM section above for the bit about the DRM_MODULES variable.
+You can avoid this problem by only building the modules you need. See the DRM section above for the bit about the `DRM_MODULES` variable.
==== xf86cfg/xorgcfg doesn't compile/link ====
xf86cfg requires libXaw (and appropriate headers) to be installed in order to build. You can either install the relevant packages for your distribution, or else add the line:
diff -urN /tmp/wiki.V9dGLk/wiki/text/MesaDriver /home/groups/d/dr/dri/wiki/text/MesaDriver
--- /tmp/wiki.V9dGLk/wiki/text/MesaDriver 2004-03-01 20:41:20.000000000 -0800
+++ /home/groups/d/dr/dri/wiki/text/MesaDriver 2004-05-20 14:51:25.000000000 -0700
@@ -8,7 +8,7 @@
Second, implement the internal functions needed by the "DD" interface. Look at the `osmesa.c` file and grep for "ctx->Driver. = ". This is where the driver hooks itself into the core of Mesa. In many cases we hook in fall-back functions (like _swrast_DrawPixels).
-This isn't simple (or even as straight-forward as is used to be) but the system's designed for efficiently, flexibility and modularity. If the device driver interface were made for simplicity above all else there would probably only be two driver functions: dd_function_table::ReadPixels() and dd_function_table::DrawPixels().
+This isn't simple (or even as straight-forward as it used to be) but the system's designed for efficiency, flexibility and modularity. If the device driver interface were made for simplicity above all else there would probably only be two driver functions: dd_function_table::ReadPixels() and dd_function_table::DrawPixels().
The OSMesa driver is pretty simple. The only complexity comes from supporting all the different frame buffer formats like !RGB, !RGBA, !BGRA, !ABGR, etc. I think the Windows driver is in pretty good shape too. The XMesa driver (upon which Mesa's GLX is layered) is rather large because of lots of frame buffer formats and optimized point/line/triangle rendering functions.
@@ -39,7 +39,7 @@
The new approach of buffering many vertices and then transforming, lighting and clip testing is faster because it's done in a "vectorized" manner. See gl_transform_points in m_xform.c for an example.
-For best performance Mesa clients should try to maximize the number of vertices between glBegin/glEnd pairs and used connected primitives when possible.
+For best performance Mesa clients should try to maximize the number of vertices between glBegin/glEnd pairs and use connected primitives when possible.
==== Rasterization ====
@@ -49,7 +49,7 @@
==== Pixel spans ====
- Point, Line, Triangle, glDrawPixel, glCopyPixels and glBitmap all use the sw_span structure and functions in s_span.c generate horizontal runs of pixels called spans. Processing includes window clipping, depth testing, stenciling, texturing, etc. After processing the span is written to the frame buffer by calling a device driver function. The goal is to maximize the number of pixel processed inside loops and to minimize the number of function calls.
+ Point, Line, Triangle, glDrawPixel, glCopyPixels and glBitmap all use the sw_span structure and functions in s_span.c generate horizontal runs of pixels called spans. Processing includes window clipping, depth testing, stenciling, texturing, etc. After processing the span is written to the frame buffer by calling a device driver function. The goal is to maximize the number of pixels processed inside loops and to minimize the number of function calls.
'''Note:''' Pixel buffers are no longer present in the latest Mesa code (4.1). All fragment (pixels plus color, depth, texture coordinates) processing is done via the span functions in s_span.c.
@@ -72,7 +72,7 @@
In addition to the device driver table functions, each Mesa driver has its own set of unique interface functions. For example, the X/Mesa driver has the XMesaCreateContext, XMesaBindWindow, and XMesaSwapBuffers functions while the Windows/Mesa interface has WMesaCreateContext, WMesaPaletteChange and WMesaSwapBuffers. New Mesa drivers need to both implement the dd_function_table functions and define a set of unique window system or operating system-specific interface functions.
-The device driver functions can roughly be divided into four groups:
+The device driver functions can roughly be divided into three groups:
1. pixel span functions which read or write horizontal runs of RGB or color-index pixels. Each function takes an array of mask flags which indicate whether or not to plot each pixel in the span.
1. miscellaneous functions for window clearing, setting the current drawing color, enabling/disabling dithering, returning the current frame buffer size, specifying the window clear color, synchronization, etc. Most of these functions directly correspond to higher level OpenGL functions.
@@ -115,11 +115,11 @@
The last stage - rendering -, calls *BuildVertices in `*_vb.c` which applies the viewport transformation, perpective divide, data type convertion and packs the vertex data in the context (in the arrays tnl->vb->*Ptr->data) into a driver dependent buffer with just the information relevent for the current OpenGL state (e.g., with/without texture, fog, etc). The template `t_dd_vbtmp.h` does this into a Direct3D alike vertex structure format.
-For instance, if we needed to premultiply the textures coordinates, as it is done in the tdfx and mach64 driver, we will need to make a costumized version of `t_dd_vbtmp.h` for that effect, or change it and supply a configuration parameter to control that behavior.
+For instance, if we needed to premultiply the textures coordinates, as it is done in the tdfx and mach64 driver, we will need to make a customized version of `t_dd_vbtmp.h` for that effect, or change it and supply a configuration parameter to control that behavior.
This buffer is then used to render the primitives in `*_tris.c`. This vertex data is intended to be copied almost verbatim into DMA buffers, with a header command, in most chips with DMA.
-But in the case of Mach64, were the commands are interleaved with each of the vertex data elements, it will be necessary to use a different structure of *Vertex to do the same, and probably to come up with a rather different implementation of t_dd_vbtmp.h as well.
+But in the case of Mach64, where the commands are interleaved with each of the vertex data elements, it will be necessary to use a different structure of *Vertex to do the same, and probably to come up with a rather different implementation of t_dd_vbtmp.h as well.
Indeed, if the chip expects something quite different to the d3d vertices, one will certainly want to look at this. In the meantime, it may be simplest to go with a "normal-looking" `*_vb.c` and do some extra stuff in the triangle/line/point functions. The ffb and glint drivers are a bit like this, I think.
@@ -155,7 +155,7 @@
What follows is a description of the texture management system in the DRI. This is all based on the Radeon driver in the 11-Feb-2002 CVS of the mesa-4-0-branch. While it is based on the Radeon code, all drivers except gamma and tdfx seem to use the same scheme (and virtually identical code).
- * Excluding the texture backing store, which is managed by Mesa, texture data is tracked in two places. The per-screen (card) SAREA divides each type of texturable memory (on-card, AGP, etc.) into an array of fixed sized chunks (RADEONSAREAPriv.texList in `programs/Xserver/hw/xfree86/drivers/ati/radeon_sarea.h`). The number of these chunks is a compile-time constant, and it cannot be changed without destroying the universe. That is, any changes here will present major compatability issues. Currently, this constant is 64. So, for the new 128MB Radeon 8500 cards, each block of memory will likely be 1MB or more. This is not as bad as it may first seem, see below. The usage of each type of memory is also tracked per-context.
+ * Excluding the texture backing store, which is managed by Mesa, texture data is tracked in two places. The per-screen (card) SAREA divides each type of texturable memory (on-card, AGP, etc.) into an array of fixed sized chunks (RADEONSAREAPriv.texList in `programs/Xserver/hw/xfree86/drivers/ati/radeon_sarea.h`). The number of these chunks is a compile-time constant, and it cannot be changed without destroying the universe. That is, any changes here will present major compatibility issues. Currently, this constant is 64. So, for the new 128MB Radeon 8500 cards, each block of memory will likely be 1MB or more. This is not as bad as it may first seem, see below. The usage of each type of memory is also tracked per-context.
* The per-context memory tracking is done using a memHeap_t. Allocations from the memHeap_t (see lib/GL/mesa/src/drv/common/mm.c) are done at byte granularity. When a context needs a block of texture memory, it is allocated from the memHeap_t. This results in very little memory fragmentation (within a context). After the allocation is made, the map of allocated memory in the SAREA is updated (radeonUpdateTexLRU in `lib/GL/mesa/src/drv/radeon/radeon_texmem.c`). Basically, each block of memory in texList that corresponds to an allocated region (in the per-context memHeap_t) is marked as allocated.
* The texList isn't just an array of blocks. It's also a priority queue (linked list). As each texture is accessed, the blocks that it occupies are moved to the head of the queue. In the Radeon code, each time a texture is uploaded or bound to a texture unit, the blocks of memory (in AGP space or on-card) are moved to the head of the texList queue.
* If an allocation (via the memHeap_t) fails when texture space is allocated (radeonUploadTexImages in `lib/GL/mesa/src/drv/radeon/radeon_texmem.c`), blocks at the end of the texList queue are freed until the allocation can succeed.This may be an area where the algorithm could be improved. For example, it might be better to find the largest free block (in the memHeap_t) and release memory around that block in LRU or least-often-used fashion until the allocation can succeed. This may be too difficult to get right or too slow when done right. Someone would have to try it and see.
@@ -183,7 +183,7 @@
The client may have other state to restore as well. In the case of the tdfx driver we have three more flags for command fifo invalid, 3D state invalid, textures invalid. If those are set the corresponding state is restored.
-So, if the X server wakes up to process input, it current grabs the lock but doesn't invalidate any state. I'm actually fixing this now so that it doesn't grab the lock for input processing.
+So, if the X server wakes up to process input, it currently grabs the lock but doesn't invalidate any state. I'm actually fixing this now so that it doesn't grab the lock for input processing.
If the X server draws, it grabs the lock and invalidates the command FIFO.
diff -urN /tmp/wiki.V9dGLk/wiki/text/libGLDriver /home/groups/d/dr/dri/wiki/text/libGLDriver
--- /tmp/wiki.V9dGLk/wiki/text/libGLDriver 2003-09-22 11:06:24.000000000 -0700
+++ /home/groups/d/dr/dri/wiki/text/libGLDriver 2004-05-20 15:15:05.000000000 -0700
@@ -25,10 +25,10 @@
* For all of the existing drivers, the __driCreateScreen function is just a wrapper that calls __driUtilCreateScreen ([http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/dri/dri_util.c?rev=HEAD&content-type=text/vnd.viewcvs-markup xc/lib/GL/dri/dri_util.c]) with a pointer to the driver's API function table (of type __DriverAPIRec). This creates a __DRIscreenPrivate structure for the display and fills it in (mostly) with the supplied parameters (i.e., screen number, display information, etc.).
- It also opens and initialized the connection to DRM. This includes opening the DRM device, mapping the frame buffer (note: the DRM documentation says that the function used for this is called drmAddMap, but it is actually called drmMap), and mapping the SAREA. The final step is to call the driver initialization function for the driver (from the InitDriver field in the __DriverAPIRec (DriverAPI field of the __DRIscreenPrivate).
+ It also opens and initializes the connection to DRM. This includes opening the DRM device, mapping the frame buffer (note: the DRM documentation says that the function used for this is called drmAddMap, but it is actually called drmMap), and mapping the SAREA. The final step is to call the driver initialization function for the driver (from the InitDriver field in the __DriverAPIRec (DriverAPI field of the __DRIscreenPrivate).
* The InitDriver function does (at least in the Radeon and i810 drivers) two broad things. It first verifies the version of the services (XFree86, DDX, and DRM) that it will use.
- The driver then creates an internal representation of the screen and stores it (the pointer to the structure) in the private field of the __DRIscreenPrivate structure. The driver-private data may include things such as mappings of MMIO registers, mappings of display and texture memory, information about the layout if video memory, chipset version specific data (feature availability for the specific chip revision, etc.), and other similar data. This is the handle that identifies the specific graphics card to the driver (in case there is more than one card in the system that will use the same driver).
+ The driver then creates an internal representation of the screen and stores it (the pointer to the structure) in the private field of the __DRIscreenPrivate structure. The driver-private data may include things such as mappings of MMIO registers, mappings of display and texture memory, information about the layout of video memory, chipset version specific data (feature availability for the specific chip revision, etc.), and other similar data. This is the handle that identifies the specific graphics card to the driver (in case there is more than one card in the system that will use the same driver).
* After performing the __glXInitialize step, CreateContext calls the createContext function for the requested screen. This is where it gets pretty complicated. I have only looked at the Radeon driver. radeonCreateContext ([http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c?rev=HEAD&content-type=text/vnd.viewcvs-markup xc/lib/GL/mesa/src/drv/radeon/radeon_context.c]) allocates a GLcontext structure (actually '''struct __GLcontextRec''' from extras/Mesa/src/mtypes.h). Here it fills in function tables for virtually every OpenGL call. Additionally, the __GLcontextRec has pointers to buffers where the driver will store context specific hardware state (textures, register settings, etc.) for when context (in terms of OpenGL / X context) switches occur.
|