Hi, I've included an (hopefully) updated version the Mesa Implementation Notes in the DRI-Devel-FAQ.
I would appreciate corrections additions to this. Although a hypertext version (whith direct links to the DRI CVS) is at http://mefriss1.swan.ac.uk/~jfonseca/dri/faq/html/architecture.html#MESA-INTERNALS I've pasted a ascii-only version here for your convenience. --------------------------------------------------------------------------------------- 3.3.5. Mesa Implementation Notes This document is an overview of the internal structure of Mesa and is meant for those who are interested in modifying or enhancing Mesa, or just curious. [Note] Based on the original Mesa Implementation Notes by Brian Paul. 3.3.5.1. Library State and Contexts OpenGL uses the notion of a state machine. Mesa encapsulates the state in one large struct: gl_context, as seen in types.h The gl_context struct actually contains a number of sub structs which exactly correspond to OpenGL's attribute groups. This organization made glPushAttrib and glPopAttrib trivial to implement and proved to be a good way of organizing the state variables. 3.3.5.2. Vertex buffer The vertices between glBegin and glEnd are accumulated in the vertex buffer (see vb.h and vb.c ). When either the vertex buffer becomes filled or a state change outside the glBegin/glEnd is made, we must flush the buffer. That is, we apply the vertex transformations, compute lighting, fog, texture coordinates etc. Then, we can render the vertices as points, lines or polygons by calling the gl_render_vb() function in render.c . When we're outside of a glBegin/glEnd pair the information in this structure is retained pending either of the flushing events described above. [Note] Originally, Mesa didn't accumulate vertices in this way. Instead, glVertex transformed and lit then buffered each vertex as it was received. When enough vertices to draw the primitive (1 for points, 2 for lines, >2 for polygons) were accumulated the primitive was drawn and the buffer cleared. 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 xform.c for an example. Also, vertices shared between primitives (i.e. GL_LINE_STRIP) are only transformed once. The only complication is clipping. If no vertices in the vertex buffer have their clip flag set, the rasterization functions can be applied directly to the vertex buffer. Otherwise, a clipping function is called before rasterizing each primitive. If clipping introduces new vertices they will be stored at the end of the vertex buffer. For best performance Mesa clients should try to maximize the number of vertices between glBegin/glEnd pairs and used connected primitives when possible. 3.3.5.3. Rasterization The point, line and polygon rasterizers are called via the PointsFunc, LineFunc, and TriangleFunc function pointers in the dd_function_table driver function pointer table. Whenever the library state is changed in a significant way, the NewState context flag is raised. When glBegin is called NewState is checked. If the flag is set we re-evaluate the state to determine what rasterizers to use. Special purpose rasterizers are selected according to the status of certain state variables such as flat vs smooth shading, depth-buffered vs. non-depth- buffered, etc. The gl_set_point|line|polygon_function functions do this analysis. They in turn query the device driver for "accelerated" rasterizers. More on that later. In general, typical states (depth-buffered & smooth-shading) result in optimized rasterizers being selected. Non-typical states (stenciling, blending, stippling) result in slower, general purpose rasterizers being selected. For best performance, Mesa clients should group state changes (glEnable, glDisable, glShadeModel, glLight*, glMaterial) together to minimize the number of times the rasterizer selectors are called. 3.3.5.4. Pixel (fragment) buffer The general purpose point, line and bitmap rasterizers accumulate fragments (pixels plus color, depth, texture coords) in the PB (Pixel Buffer) struct seen in . pb.h and pb.c . When the pixel buffer is full or glEnd is called the pixel buffer is flushed. This includes clipping the fragments against the window, depth testing, stenciling, blending, stippling, etc. Finally, the pixel buffer's pixels are drawn to the display buffer by calling one of device driver functions. The goal is to maximize the number of pixels processed inside loops and to minimize the number of function calls. 3.3.5.5. Pixel spans The polygon, glDrawPixels, and glCopyPixels functions generate horizontal runs of pixels called spans. Spans are processed in span.c . 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. 3.3.5.6. Device Driver There are three Mesa datatypes which are meant to be used by device drivers: GLcontext this contains the Mesa rendering state GLvisual this describes the color buffer (rgb vs. ci), whether or not there's a depth buffer, stencil buffer, etc. GLframebuffer contains pointers to the depth buffer, stencil buffer, accum buffer and alpha buffers. These types should be encapsulated by corresponding device driver datatypes. See xmesa.h and xmesaP.h for an example. In OOP terms, GLcontext, GLvisual, and GLframebuffer are base classes which the device driver must derive from. The struct dd_function_table seen in dd.h , defines the device driver functions. By using a table of pointers, the device driver can be changed dynamically at runtime. For example, the X/Mesa and OS/Mesa (Off-Screen rendering) device drivers can co-exist in one library and be selected at runtime. 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: 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. 2. pixel array functions which are very similar to the pixel span functions except that they're used to read or write arrays of pixels at random locations rather than horizontal runs. 3. 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. 4. if your graphics hardware or operating system provides accelerated point, line and polygon rendering operations, they can be utilized through the PointsFunc, LineFunc, and TriangleFunc functions. Mesa will call these functions to "ask" the device driver for accelerated functions trhough the UpdateState . If the device driver can provide an appropriate renderer, given the current Mesa state, then a pointer to that function can be returned. Otherwise the PointsFunc, LineFunc, and TriangleFunc functions pointers can just be set to NULL. Even if hardware accelerated renderers aren't available, the device driver may implement tuned, special purpose code for common kinds of points, lines or polygons. The X/Mesa device driver does this for a number of lines and polygons. See the xmesa3.c file. 3.3.5.7. Overall Organization The overall relation of the core Mesa library, X device driver/interface, toolkits and application programs is shown in this diagram: +-----------------------------------------------------------+ | | | Application Programs | | | | +- glu.h -+- aux.h tk.h glut.h -+ | | | | | | | | GLU | aux, tk or GLUT | | | | | toolkits | | | | | | | +---------- gl.h ------------+-------- glx.h ----+ | | | | | | Mesa core | GLX functions | | | | | | +---------- dd.h ------------+------------- xmesa.h --------+ | | | XMesa* and device driver functions | | | +-----------------------------------------------------------+ | Hardware/OS/Window System | +-----------------------------------------------------------+ --------------------------------------------------------------------------------------- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
