diff options
| author | marha <marha@users.sourceforge.net> | 2010-04-12 09:53:17 +0000 |
|---|---|---|
| committer | marha <marha@users.sourceforge.net> | 2010-04-12 09:53:17 +0000 |
| commit | 29b86f9852b2b7ecc31cdfee56679537e40bc6e2 (patch) | |
| tree | 1e6ec8ccf2dbf773260a1953b8e13c49f9b7c5f5 /mesalib/docs | |
| parent | 529236591df7366479a6fac30b387667678fd1ba (diff) | |
| download | vcxsrv-29b86f9852b2b7ecc31cdfee56679537e40bc6e2.tar.gz vcxsrv-29b86f9852b2b7ecc31cdfee56679537e40bc6e2.tar.bz2 vcxsrv-29b86f9852b2b7ecc31cdfee56679537e40bc6e2.zip | |
svn merge -r524:HEAD "^/branches/released" .
Diffstat (limited to 'mesalib/docs')
26 files changed, 869 insertions, 822 deletions
diff --git a/mesalib/docs/MESA_swap_control.spec b/mesalib/docs/MESA_swap_control.spec index ecc674649..856978b53 100644 --- a/mesalib/docs/MESA_swap_control.spec +++ b/mesalib/docs/MESA_swap_control.spec @@ -43,7 +43,7 @@ Issues New Procedures and Functions - int glXSwapIntervalMESA(int interval) + int glXSwapIntervalMESA(unsigned int interval) int glXGetSwapIntervalMESA(void) New Tokens @@ -103,11 +103,8 @@ Additions to the GLX 1.3 Specification Errors - glXSwapIntervalMESA returns GLX_BAD_VALUE if parameter <interval> is - less than zero. - glXSwapIntervalMESA returns GLX_BAD_CONTEXT if there is no current - GLXContext. + GLXContext or if the current context is not a direct rendering context. GLX Protocol diff --git a/mesalib/docs/MiniGLX.html b/mesalib/docs/MiniGLX.html deleted file mode 100644 index e7ebae685..000000000 --- a/mesalib/docs/MiniGLX.html +++ /dev/null @@ -1,534 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> -<head> - <title>Mini GLX Specification</title> -</head> -<body> -<h1> -<center>Mini GLX Specification</center> -</h1> -<h2> -<center>Tungsten Graphics, Inc.<br> -<br> -January 20, 2003<br> -<br> -</center> -</h2> -<p> Copyright © 2002-2003 by Tungsten Graphics, Inc., Cedar Park, -Texas. All Rights Reserved. <br> -<br> -Permission is granted to make and distribute verbatim copies of this -document provided the copyright notice and this permission notice are -preserved on all copies.<br> -<br> -</p> -<h1>1. Introduction</h1> -<p>The Mini GLX interface facilitates OpenGL rendering on embedded -devices. The interface is a subset of the GLX interface, plus a minimal -set of Xlib-like functions.</p> -<p>Programs written to the Mini GLX specification should run unchanged -on systems with the X Window System and the GLX extension. The intention -is to allow flexibility for prototyping and testing.</p> -<p>This document serves as both the reference guide and programming -guide for Mini GLX.<br> -<br> -</p> -<h1>2. Mini GLX Concepts</h1> -<p>The OpenGL specification does not describe how OpenGL rendering -contexts and drawing surfaces (i.e. the frame buffer) are created and -managed. Rather, this is handled by an OpenGL window system interface, -such as Mini GLX.</p> -<p>There are three main datatypes or resources managed by Mini GLX. The -resources and their corresponding GLX or Xlib data types are:</p> -<table cellspacing="10" align="center"> - <tbody> - <tr> - <td><u>Resource</u></td> - <td><u>Data type</u></td> - </tr> - <tr> - <td>pixel formats</td> - <td>X Visual and XVisualInfo</td> - </tr> - <tr> - <td>drawing surfaces</td> - <td>X Window or GLXDrawable</td> - </tr> - <tr> - <td>rendering contexts</td> - <td>GLXContext</td> - </tr> - </tbody> -</table> -<p>Pixel formats or X Visuals describe the per-pixel attributes of the -frame buffer. For example, bits per color component, Z buffer size, -stencil size, TrueColor vs PseudoColor, etc.</p> -<p>Drawing surfaces or X Windows typically describe a spatial -allocation of the frame buffer (i.e. the position and size of a -rectangular region of pixels). Since MiniGLX doesn't really support a -window system, the window is effectively the entire frame buffer.</p> -<p>A rendering context represents the current OpenGL state such as -current drawing color, line width, blending mode, texture parameters, -etc. Several rendering contexts can be created but only one can be in -use at any given time.</p> -<p>The Mini GLX interface provides all the functions needed for -choosing pixel formats, create drawing surfaces, creating rendering -contexts and binding rendering contexts to drawing surfaces.<br> -<br> -</p> -<h1>3. Using Mini GLX</h1> -<p>To use the Mini GLX interface in your application, include the -GL/miniglx.h header file at compile time:</p> -<blockquote><code> #include <GL/miniglx.h><br> - </code></blockquote> -<code></code>Applications should link with libGL.so (i.e. <code>gcc -myprogram.o -lGL -o myprogram</code>). libGL.so implements the -MiniGLX API functions and, in turn, loads a hardware-specific device -driver (such as <code>radeon_dri.so</code>) at runtime. The -environment variable <code>LIBGL_DRIVERS_PATH</code> should name the -directory where these modules are located.<br> -<br> -The remainder of this section describes the MiniGLX API functions.<br> -<br> -<h2>3.1 Initialization</h2> -<p>The XOpenDisplay function is used to initialize the graphics system:</p> -<blockquote> - <pre>Display *XOpenDisplay(const char *displayname)<br></pre> -</blockquote> -<p>The <code>displayName</code> parameter is currently ignored in Mini -GLX. It is recommended that <code>NULL</code> be passed as the<code>displayName</code> -parameter.</p> -<p>If XOpenDisplay is able to initialize the graphics system a pointer -to a Display will be returned. Otherwise, NULL will be returned.</p> -<h2>3.2 Choosing a Visual</h2> -<p>A visual (i.e. pixel format) must be chosen before a drawing surface -or rendering context can be created. This is done with the -glXChooseVisual function:</p> -<blockquote> - <pre>XVisualInfo *glXChooseVisual(Display *dpy, int screen, const int *attribList)<br></pre> -</blockquote> -<p><code>dpy</code> is a pointer to the display returned by -XOpenDisplay. </p> -<p><code>screen</code> is currently ignored by Mini GLX and should be -zero. </p> -<p><code>attribList</code> is a list of GLX attributes which describe -the desired pixel format. It is terminated by the token <code>None</code>. -The attributes are as follows:</p> -<blockquote> - <dl> - <dt><code>GLX_USE_GL</code></dt> - <dd>This attribute should always be present in order to maintain -compatibility with GLX.</dd> - <dt><code>GLX_RGBA</code></dt> - <dd>If present, only RGBA pixel formats will be considered. -Otherwise, only color index formats are considered.</dd> - <dt><code>GLX_DOUBLEBUFFER</code></dt> - <dd>if present, only double-buffered pixel formats will be chosen.</dd> - <dt><code>GLX_RED_SIZE n</code></dt> - <dd>Must be followed by a non-negative integer indicating the -minimum number of bits per red pixel component that is acceptable.</dd> - <dt><code>GLX_GREEN_SIZE n</code></dt> - <dd>Must be followed by a non-negative integer indicating the -minimum number of bits per green pixel component that is acceptable.</dd> - <dt><code>GLX_BLUE_SIZE n</code></dt> - <dd>Must be followed by a non-negative integer indicating the -minimum number of bits per blue pixel component that is acceptable.</dd> - <dt><code>GLX_ALPHA_SIZE n</code></dt> - <dd>Must be followed by a non-negative integer indicating the -minimum number of bits per alpha pixel component that is acceptable.</dd> - <dt><code>GLX_STENCIL_SIZE n</code></dt> - <dd>Must be followed by a non-negative integer indicating the -minimum number of bits per stencil value that is acceptable.</dd> - <dt><code>None</code></dt> - <dd>This token is used to terminate the attribute list.</dd> - </dl> -</blockquote> -<p>glXChooseVisual will return a pointer to an XVisualInfo object which -most closely matches the requirements of the attribute list. If there -is no visual which matches the request, NULL will be returned.</p> -<p>Note that visuals with accumulation buffers and depth buffers are -not available.<br> -<br> -</p> -<h2>3.3 Creating a Drawing Surface</h2> -<p>Drawing surfaces are created as X windows. For Mini GLX, -windows are <i>full-screen</i>; they cover the entire frame buffer. - Also, Mini GLX imposes a limit of one window. A second window -cannot be created until the first one is destroyed.</p> -<h3>3.3.1 Window Creation</h3> -<p>The XCreateWindow function is used to create a drawing surface:</p> -<blockquote> - <pre>Window XCreateWindow( Display *display,<br> Window parent,<br> int x, int y,<br> unsigned int width, unsigned int height,<br> unsigned int borderWidth,<br> int depth,<br> unsigned int class,<br> Visual *visual,<br> unsigned long valuemask,<br> XSetWindowAttributes *attributes )<br></pre> -</blockquote> -<p>The parameters are as follows:</p> -<blockquote> - <dl> - <dt><code>display</code></dt> - <dd>A Display pointer, as returned by XOpenDisplay.</dd> - <dt><code>parent</code></dt> - <dd>The parent window for the new window. For Mini GLX, this -should be<code>RootWindow(dpy, 0)</code>.</dd> - <dt><code>x, y</code></dt> - <dd>The position of the window. For Mini GLX, both values should -be zero.</dd> - <dt><code>width, height</code></dt> - <dd>The size of the window. For Mini GLX, this specifies the -desired screen size such as 1024, 768 or 1280, 1024.</dd> - <dt><code>borderWidth</code></dt> - <dd>This parameter should be zero.</dd> - <dt><code>depth</code></dt> - <dd>The pixel depth for the window. For Mini GLX this should be -the depth found in the XVisualInfo object returned by <code>glxChooseVisual</code>.</dd> - <dt><code>class</code></dt> - <dd>The window class. For Mini GLX this value should be <code>InputOutput</code>.</dd> - <dt><code>visual</code></dt> - <dd>This parameter should be the <code>visual</code> field of the <code>XVisualInfo</code> -object returned by <code>glxChooseVisual</code>.</dd> - <dt><code>valuemask</code></dt> - <dd>This parameter indicates which fields of the <code>XSetWindowAttributes</code> -are to be used. For Mini GLX this is typically the bitmask<code>CWBackPixel -| CWBorderPixel | CWColormap</code>.</dd> - <dt><code>attributes</code></dt> - <dd>Initial window attributes. Of the fields in the <code>XSetWindowAttributes</code> -structure, the<code>background_pixel</code>, <code>border_pixel</code> -and <code>colormap</code> fields should be set. See the discussion -below regarding colormaps.</dd> - </dl> -</blockquote> -<p><code>XCreateWindow</code> will return a window handle if it succeeds -or zero if it fails.</p> -<h3>3.3.2 Window Mapping</h3> -<p>To display the window the XMapWindow function must be called:</p> -<blockquote> - <pre>void XMapWindow(Display *dpy, Window w)</pre> -</blockquote> -<p>This function does nothing in Mini GLX but is required for Xlib/GLX -compatibility</p> -<h3>3.3.3 Colormaps<br> -</h3> -<p>Xlib requires specification of a colormap when creating a window. - For purposes of interoperability, Mini GLX requires this as well, -though the colormap is not actually used. The XCreateColormap -function is used to create a colormap:</p> -<blockquote><code>Colormap XCreateColormap(Display *dpy, Window window, -Visual *visual, int alloc)</code><br> - <code></code></blockquote> -<p>The parameters are as follows:<br> -</p> -<blockquote> - <dl> - <dt><code>dpy</code></dt> - <dd>The display handle as returned by XOpenDisplay.</dd> - <dt><code>window</code></dt> - <dd> This parameter is ignored by Mini GLX but should be the value -returned by the <code>RootWindow(dpy, 0)</code> macro.<br> - </dd> - <dt><code>visual</code></dt> - <dd>This parameter is ignored by Mini GLX but should be the visual -field of the XVisualInfo object returned by glXChooseVisual. </dd> - <dt><code>alloc</code></dt> - <dd>This parameter is ignored by Mini GLX but should be set to <code>AllocNone</code>.</dd> - </dl> -</blockquote> -<br> -<h2>3.4 Creating a Rendering Context</h2> -<p>An OpenGL rendering context is created with the <code>glXCreateContext</code> -function:</p> -<blockquote> - <pre>GLXContext glXCreateContext(Display *dpy, XVisualInfo *visInfo, GLXContext shareList, Bool direct)<br></pre> -</blockquote> -<p>The parameters are as follows:</p> -<blockquote> - <dl> - <dt><code>dpy</code></dt> - <dd>The display handle as returned by XOpenDisplay.</dd> - <dt><code>visInfo</code></dt> - <dd>The visual as returned by glXChooseVisual.</dd> - <dt><code>shareList</code></dt> - <dd>If non-zero, texture objects and display lists are shared with -the named rendering context. If zero, texture objects and display lists -will (initially) be private to this context. They may be shared when a -subsequent context is created.</dd> - <dt><code>direct</code></dt> - <dd>Specifies whether direct or indirect rendering is desired. For -Mini GLX this value is ignored but it should be set to <code>True</code>.</dd> - </dl> -</blockquote> -<p><code>glXCreateContext</code> will return a GLXContext handle if it -succeeds or zero if it fails due to invalid parameter or insufficient -resources.<br> -<br> -</p> -<h2>3.5 Binding a Rendering Context</h2> -<p>The final step before beginning OpenGL rendering is to bind (i.e. -activate) a rendering context and drawing surface with the -glXMakeCurrent function:</p> -<blockquote> - <pre>Bool glXMakeCurrent(Display *dpy, GLXDrawable drawable, GLXContext ctx)<br></pre> -</blockquote> -<p>The parameters are as follows:</p> -<blockquote> - <dl> - <dt><code>dpy</code></dt> - <dd>The display handle, as returned by XOpenDisplay.</dd> - <dt><code>drawable</code></dt> - <dd>The window or drawable to bind to the rendering context. This -should be the value returned by XCreateWindow.</dd> - <dt><code>ctx</code></dt> - <dd>The rendering context to bind, as returned by glXCreateContext.</dd> - </dl> -</blockquote> -<p>If glXMakeCurrent succeeds True is returned. Otherwise False is -returned to indicate an invalid display, window or context parameter.</p> -<p>After the rendering context has been bound to the drawing surface -OpenGL rendering can begin.</p> -<p>The current rendering context may be unbound by calling -glXMakeCurrent with the window and context parameters set to zero.</p> -<p>An application may create any number of rendering contexts and bind -them as needed. Note that binding a rendering context is generally not a -light-weight operation. Most simple OpenGL applications create -only one rendering context.<br> -<br> -</p> -<h2>3.6 Color Buffer Swapping</h2> -<p>A double buffered window has two color buffers: a front buffer and a -back buffer. Normally, rendering is directed to the back buffer while -the front buffer is displayed. When rendering of a frame is finished -the front and back buffers are swapped to provide the illusion of -instanteous screen updates.</p> -<p>The color buffers for a particular window (i.e. drawable) may be -swapped with the glXSwapBuffers command:</p> -<blockquote> - <pre>void glXSwapBuffers(Display *dpy, GLXDrawable drawable)<br></pre> -</blockquote> -Any pending rendering commands will be completed before the buffer swap -takes place.<br> -<br> -Calling glXSwapBuffers on a window which is single-buffered has no -effect.<br> -<br> -<h2>3.7 Releasing Resources</h2> -<h3>3.7.1 Releasing Rendering Contexts</h3> -<p>A rendering context may be destroyed by calling glXDestroyContext:</p> -<blockquote> - <pre>void glXDestroyContext(Display *dpy, GLXContext ctx)<br></pre> -</blockquote> -<h3>3.7.2 Releasing Windows</h3> -<p>A window may be destroyed by calling XDestroyWindow:</p> -<blockquote> - <pre>void XDestroyWindow(Display *dpy, Window window)<br></pre> -</blockquote> -<h3>3.7.3 Releasing Visuals</h3> -<p>An XVisualInfo object may be freed by calling XFree:</p> -<blockquote> - <pre>void XFree(void *data)<br></pre> -</blockquote> -<h3>3.7.4 Releasing Colormaps</h3> -<p>A colormap may be freed by calling XFreeColormap:</p> -<blockquote> - <pre>void XFreeColormap(Display *dpy, Colormap colormap)<br></pre> -</blockquote> -<h3>3.7.4 Releasing Display Resources</h3> -<p>When the application is about to exit, the resources associated with -the graphics system can be released by calling XCloseDisplay:</p> -<blockquote> - <pre>void XCloseDisplay(Display *dpy)<br></pre> -</blockquote> -<p>The display handle becomes invalid at this point.<br> -<br> -</p> -<h2>3.8 Query Functions</h2> -<h3>3.8.1 Querying Available Visuals</h3> -A list of all available visuals can be obtained with the XGetVisualInfo -function:<br> -<br> -<div style="margin-left: 40px;"><code>XVisualInfo -*XGetVisualInfo(Display *dpy, long vinfo_mask, XVisualInfo -*vinfo_template, int *nitems_return)<br> -</code></div> -<br> -The parameters are as follows:<br> -<blockquote> - <dl> - <dt><code>dpy</code></dt> - <dd>The display handle, as returned by XOpenDisplay.</dd> - <dt><code>vinfo_mask</code></dt> - <dd>A bitmask indicating which fields of the vinfo_template are to -be matched. The value must be VisualScreenMask.</dd> - <dt><code>vinfo_template</code></dt> - <dd>A template whose fields indicate which visual attributes must -be matched by the results. The screen field of this structure must -be zero.</dd> - <dt><code>nitems_return</code></dt> - <dd>Returns the number of visuals returned. </dd> - </dl> -</blockquote> -The return value is the address of an array of all available visuals.<br> -<br> -An example of using XGetVisualInfo to get all available visuals follows:<br> -<br> -<div style="margin-left: 40px;"><code>XVisualInfo visTemplate, *results;</code><br> -<code>int numVisuals;</code><br> -<code>Display *dpy = XOpenDisplay(NULL);</code><br> -<code>visTemplate.screen = 0;</code><br> -<code>results = XGetVisualInfo(dpy, VisualScreenMask, &visTemplate, -&numVisuals);</code><br> -<code></code></div> -<br> -<h3>3.8.2 Querying Visual Attributes</h3> -<p>The GLX attributes of an X visual may be queried with the -glXGetConfig function:</p> -<blockquote> - <pre>int glXGetConfig(Display *dpy, XVisualInfo *vis, int attribute, int *value)<br></pre> -</blockquote> -<p>The parameters are as follows:</p> -<blockquote> - <dl> - <dt><code>dpy</code></dt> - <dd>The display handle, as returned by XOpenDisplay.</dd> - <dt><code>vis</code></dt> - <dd>The visual, as returned by glXChooseVisual.</dd> - <dt><code>attribute</code></dt> - <dd>The attribute to query. The attributes are listed below.</dd> - <dt><code>value</code></dt> - <dd>Pointer to an integer in which the result of the query will be -stored. </dd> - </dl> -</blockquote> -<p>The return value will be zero if no error occurs.<code> - GLX_INVALID_ATTRIBUTE</code> will be returned if the attribute -parameter is invalid.<code> GLX_BAD_VISUAL</code> will be returned -if the XVisualInfo parameter is invalid.</p> -<p>The following attributes may be queried:</p> -<blockquote> - <dl> - <dt><code>GLX_USE_GL</code></dt> - <dd>The result will be <code>True</code> or <code>False</code> to -indicate if OpenGL rendering is supported with the visual. Mini GLX -always return <code>True</code>.</dd> - <dt><code>GLX_RGBA</code></dt> - <dd>The result will be <code>True</code> for RGBA visuals or <code>False</code> -for color index visuals.</dd> - <dt><code>GLX_DOUBLEBUFFER</code></dt> - <dd>The result will be <code>True</code> if the visual has two -color buffers or <code>False</code> if the visual has one color buffer.</dd> - <dt><code>GLX_RED_SIZE</code></dt> - <dd>The result will be the number of red bits per pixel.</dd> - <dt><code>GLX_GREEN_SIZE</code></dt> - <dd>The result will be the number of green bits per pixel.</dd> - <dt><code>GLX_BLUE_SIZE</code></dt> - <dd>The result will be the number of blue bits per pixel.</dd> - <dt><code>GLX_ALPHA_SIZE</code></dt> - <dd>The result will be the number of alpha bits per pixel.</dd> - <dt><code>GLX_DEPTH_SIZE</code></dt> - <dd>The result will be the number of bits per Z value.</dd> - <dt><code>GLX_STENCIL_SIZE</code></dt> - <dd>The result will be the number of bits per stencil value.<br> - <br> - </dd> - </dl> -</blockquote> -<h3>3.8.3 Querying the Current Rendering Context</h3> -<p>The current rendering context can be queried with -glXGetCurrentContext: </p> -<blockquote> - <pre>GLXContext glXGetCurrentContext(void)<br></pre> -</blockquote> -<p>Zero will be returned if no context is currently bound.<br> -<br> -</p> -<h3>3.8.4 Querying the Current Drawable</h3> -<p>The current drawable (i.e. window or drawing surface) can be queried -with glXGetCurrentDrawable:</p> -<blockquote> - <pre>GLXDrawable glXGetCurrentDrawable(void)<br></pre> -</blockquote> -<p>Zero will be returned if no drawable is currently bound.<br> -<br> -</p> -<h3>3.8.5 Function Address Queries</h3> -<p>The glXGetProcAddress function will return the address of any -available OpenGL or Mini GLX function:</p> -<blockquote> - <pre>void *glXGetProcAddress(const GLubyte *procName)<br></pre> -</blockquote> -<p>If <code>procName</code> is a valid function name, a pointer to that -function will be returned. Otherwise, NULL will be returned.</p> -<p>The purpose of glXGetProcAddress is to facilitate using future -extensions to OpenGL or Mini GLX. If a future version of the library -adds new extension functions they'll be accessible via -glXGetProcAddress. The alternative is to hard-code calls to the new -functions in the application but doing so will prevent linking the -application with older versions of the library.<br> -<br> -</p> -<h2>3.9 Versioning</h2> -The Mini GLX version can be queried at run time with glXQueryVersion: -<blockquote> - <pre>Bool glXQueryVersion(Display *dpy, int *major, int *minor)<br></pre> -</blockquote> -<p><code>major</code> will be set to the major version number and<code>minor</code> -will be set to the minor version number.<code>True</code> will be -returned if the function succeeds. <code>False</code> will be returned -if the function fails due to invalid parameters. The <code>dpy</code> -argument is currently ignored, but should be the value returned by -XOpenDisplay.</p> -<p>At compile time, the Mini GLX interface version can be tested with -the MINI_GLX_VERSION_1_<i>x</i> preprocessor tokens. For example, if -version 1.0 of Mini GLX is supported, then<code> MINI_GLX_VERSION_1_0</code> -will be defined. If version 1.1 of Mini GLX is supported, then<code> -MINI_GLX_VERSION_1_1</code> will be defined.</p> -<p>At the time of writing the current Mini GLX version is 1.0.<br> -<br> -</p> -<h1>4.0 Interoperability with GLX and Xlib</h1> -While Mini GLX strives to be compatible with GLX and Xlib there are -some unavoidable differences which must be taken into consideration.<br> -<h2>4.1 Public vs Private Structures</h2> -The structure of many X data types is public. For example, the <code>Display</code> -data type is defined as a structure in /usr/include/X11/Xlib.h and -programmers may access any fields of that structure at will. Mini -GLX also defines a Display data type but its fields are hidden and not -visiblein <code>miniglx.h</code>. Duplicating the Xlib -declaration for the <code>Display</code> data type in minigl.h would -require defining a large number of other superfluous Xlib datatypes.<br> -<br> -Mini GLX users are discouraged from directly accessing the fields of -Xlib data types to maximize portability - though this is unavoidable to -some extent. For example, the <code>XVisualInfo</code> and <code>XSetWindowAtttributes</code> -data types must be completely public. -<h2>4.2 Macros</h2> -In some cases, Xlib defines macros which are meant to be used instead -of direct structure accesses. For example, the <code>RootWindow(dpy, -screen)</code> macro returns the root window for a given screen on a -given display. Unfortunately, macros do nothing to aid in ABI -compatibility since they are resolved at compile time instead of at -link/run time.<br> -<br> -Mini GLX also defines a <code>RootWindow</code> macro since it's -essential for creating windows. But the implementation of this -macro by Xlib and Mini GLX is completely different.<br> -<h2>4.3 Summary</h2> -Because Xlib and Mini GLX define data types and macros differently, -Mini GLX applications must be recompiled when retargeting Mini GLX or -native Xlib/GLX. That is, applications can't simply be re-linked -because of ABI incompatibilities.<br> -<br> -Nevertheless, the fact that Mini GLX programs can be recompiled for -Xlib and GLX increases portability and flexibility for testing and -prototyping.<br> -<br> -<h1>5.0 Example Program</h1> -<p>This section shows an example program which uses the Mini GLX -interface. The program simply draws several frames of a rotating square.<br> -</p> -<p>The program may be compiled for use with Xlib/GLX or Mini GLX by -setting the <code>USE_MINIGLX</code> token to 0 or 1, respectively. - Note that the only difference is the header files which are -included.<br> -</p> -<p> </p> -<pre><code><br></code>#define USE_MINIGLX 1 /* 1 = use Mini GLX, 0 = use Xlib/GLX */<br><br>#include <stdio.h><br>#include <stdlib.h><br>#include <GL/gl.h><br><br>#if USE_MINIGLX<br>#include <GL/miniglx.h><br>#else<br>#include <GL/glx.h><br>#include <X11/Xlib.h><br>#endif<br><br><code>/*<br> * Create a simple double-buffered RGBA window.<br> */<br>static Window<br>MakeWindow(Display * dpy, unsigned int width, unsigned int height)<br>{<br> int visAttributes[] = {<br> GLX_RGBA,<br> GLX_RED_SIZE, 1,<br> GLX_GREEN_SIZE, 1,<br> GLX_BLUE_SIZE, 1,<br> GLX_DOUBLEBUFFER,<br> None<br> };<br> XSetWindowAttributes attr;<br> unsigned long attrMask;<br> Window root;<br> Window win;<br> GLXContext ctx;<br> XVisualInfo *visinfo;<br><br> root = RootWindow(dpy, 0);<br><br> /* Choose GLX visual / pixel format */<br> visinfo = glXChooseVisual(dpy, 0, visAttributes);<br> if (!visinfo) {<br> printf("Error: couldn't get an RGB, Double-buffered visual\n");<br> exit(1);<br> }<br><br> /* Create the window */<br> attr.background_pixel = 0;<br> attr.border_pixel = 0;<br> attr.colormap = XCreateColormap(dpy, root, visinfo->visual, AllocNone);<br> attrMask = CWBackPixel | CWBorderPixel | CWColormap;<br> win = XCreateWindow(dpy, root, 0, 0, width, height,<br> 0, visinfo->depth, InputOutput,<br> visinfo->visual, attrMask, &attr);<br> if (!win) {<br> printf("Error: XCreateWindow failed\n");<br> exit(1);<br> }<br><br> /* Display the window */<br> XMapWindow(dpy, win);<br><br> /* Create GLX rendering context */<br> ctx = glXCreateContext(dpy, visinfo, NULL, True);<br> if (!ctx) {<br> printf("Error: glXCreateContext failed\n");<br> exit(1);<br> }<br><br> /* Bind the rendering context and window */<br> glXMakeCurrent(dpy, win, ctx);<br><br> return win;<br>}<br><br><br>/*<br> * Draw a few frames of a rotating square.<br> */<br>static void<br>DrawFrames(Display * dpy, Window win)<br>{<br> int angle;<br> glShadeModel(GL_FLAT);<br> glClearColor(0.5, 0.5, 0.5, 1.0);<br> for (angle = 0; angle < 360; angle += 10) {<br> glClear(GL_COLOR_BUFFER_BIT);<br> glColor3f(1.0, 1.0, 0.0);<br> glPushMatrix();<br> glRotatef(angle, 0, 0, 1);<br> glRectf(-0.8, -0.8, 0.8, 0.8);<br> glPopMatrix();<br> glXSwapBuffers(dpy, win);<br> }<br>}<br><br><br>int<br>main(int argc, char *argv[])<br>{<br> Display *dpy;<br> Window win;<br><br> dpy = XOpenDisplay(NULL);<br> if (!dpy) {<br> printf("Error: XOpenDisplay failed\n");<br> return 1;<br> }<br><br> win = MakeWindow(dpy, 300, 300);<br><br> DrawFrames(dpy, win);<br><br> return 0;<br>}<br></code></pre> -<br> -</body> -</html> diff --git a/mesalib/docs/README.3DFX b/mesalib/docs/README.3DFX index 037e8fa7c..7feda6f33 100644 --- a/mesalib/docs/README.3DFX +++ b/mesalib/docs/README.3DFX @@ -644,7 +644,7 @@ Hints and Special Features: - The Voodoo driver supports the GL_EXT_paletted_texture. it works only with GL_COLOR_INDEX8_EXT, GL_RGBA palettes and the alpha value - is ignored because this is a limitation of the the current Glide + is ignored because this is a limitation of the current Glide version and of the Voodoo hardware. See Mesa-3.1/3Dfx/demos/paltex.c for a demo of this extension. diff --git a/mesalib/docs/README.D3D b/mesalib/docs/README.D3D deleted file mode 100644 index b41fcb620..000000000 --- a/mesalib/docs/README.D3D +++ /dev/null @@ -1,124 +0,0 @@ - - DirectX 6 Driver for Mesa 3.0 - - -This software is distributed under the terms of the GNU Library -General Public License, see the LICENSE file for details. - - - -What do you need ? ------------------- - - - A PC with a DirectX 6 video driver installed. - - - Mesa 3.0 - - - The 3Dfx Glide library 2.3 or later for your OS (the 2.4 works fine). - The Voodoo2 requires the Glide library 2.51. The Glide 3.0 is not - compatible with the Glide 2.x so it doesn't work with the current - version of the driver; - - - Visual C++ 5.0 is only compiler test but others should be ok with - changes to the makefiles (CFLAGS/LFLAGS). - - - DirectX 6 SDK (was a MS download but not sure if still available). - - - SoftIce or another debugger that will get DPF's is nice. - - -Tested on: ----------- - Windows 95 - Windows 98 - Windows NT 5.0 (beta 2) - - -What is able to do ? --------------------- - - - the driver will try and use DirectX to rasterize the OpenGL primitives - that are sent to the driver. The driver will fall back to SW if the rendering - context is too big. The fallback to SW still uses DirectDraw. If the driver - fails to support and operation (accum, stencil, etc) then it will try and get - Mesa to render it in SW. DirectX 6 features that are unsupported by the - installed DirectX 6 driver will be mapped to some other best fit feature. - - -How to compile: ---------------- - - These instructions assume you have Visual C++ installed. - - You might need to increase you enviroment space. You can do this by - adding the following statement to you config.sys. - - shell=C:\COMMAND.COM C:\ /p /e:8198 - - Next setup you compiler enviroment by running vcvars32.bat in the Visual C++ - 'bin' directoy. - - c:\DevStudio\VC\bin\vcvars32.bat - - Modify the D3D makefile to point at your SDK install. Example has the SDK - installed on my 'f' drive in the root. - - file: \Mesa-3.0\src\makefile.d3d - - SDKROOT=f:\mssdk - - Now you can simply make the project. If you look in the makefile you can see - I have some different targets like 'install'. - - nmake /f makefile.d3d - - -FAQ: ----- - - 1) I don't think the driver is using my DirectX driver. - - This maybe true as the current version will only select the Primary D3D driver - installed. If you 3D card is the secondary (3dfx) then your out of luck for this - release. - - 2) The driver seems like its not HW accelerated. - - If you have a video card with limited memory then you might want to try and - change your destop resolution to a low setting (640x480x16) so that the 3D part - of the card has more resources. Remeber the driver can't make the card better... - - 3) Nothing works. - - Make sure you have a DirectX '6' driver installed. Check you driver docs for this - info or use the SDK info utilities. - The final 'dll' is named opengl32.dll and is either in the same directory as the - OpenGL program or in your system directory (x:\windows\system or x:\winnt\system32). - Check your destop resolution. Most DirectX 6 drivers will only support 16bit and - 32bit color depth. To find out for sure you can check the DirectX Info Viewer in - the SDK. - - - 4) Rendering doesn't look right. - - Sometimes this is because the card doesn't support a feature that that is required. - This is usually due to unsupported alpha functions (test/blend) or texture mapping. - Some cards suffer from too small of an alpha channel. The driver does its best to - fallback on unsupported features. This is not to say the driver may not have a bug(s). - - 5) Textures look bad. - - No mipmapping in this release. - - -Thanks to: ----------- - -Brian Paul - - - - -Leigh McRae (leigh@altsoftware.com) -February 9, 1999 - diff --git a/mesalib/docs/README.directfb b/mesalib/docs/README.directfb deleted file mode 100644 index d66ca8d3c..000000000 --- a/mesalib/docs/README.directfb +++ /dev/null @@ -1,29 +0,0 @@ - - Mesa DirectFB Information - - -Requirements -============ - - To build Mesa with DirectFB (DirectFBGL) support you need: - - DirectFB at least 1.0.0 (http://directfb.org) - - pkg-config at least 0.9 (http://pkgconfig.sf.net) - - -Installation -============ - Run - - make linux-directfb - - to build Mesa and DirectFBGL module, - - make install - - to install OpenGL libraries and - - cd src/mesa/drivers/directfb ; make install - - to install DirectFBGL module in the proper location. - Actually, that last command may not be needed. Please provide feedback. - diff --git a/mesalib/docs/contents.html b/mesalib/docs/contents.html index d15e6c1e3..cca20ecaa 100644 --- a/mesalib/docs/contents.html +++ b/mesalib/docs/contents.html @@ -52,9 +52,12 @@ a:visited { <b>User Topics</b> <ul> +<li><a href="shading.html" target="MainFrame">Shading Language</a> +<li><a href="egl.html" target="MainFrame">EGL</a> +<li><a href="opengles.html" target="MainFrame">OpenGL ES</a> +<li><a href="openvg.html" target="MainFrame">OpenVG / Vega</a> <LI><A HREF="envvars.html" target="MainFrame">Environment Variables</A> <LI><A HREF="osmesa.html" target="MainFrame">Off-Screen Rendering</A> -<LI><A HREF="pbuffers.html" target="MainFrame">Pbuffer Rendering</A> <LI><A HREF="debugging.html" target="MainFrame">Debugging Tips</A> <LI><A HREF="perf.html" target="MainFrame">Performance Tips</A> <LI><A HREF="extensions.html" target="MainFrame">Mesa Extensions</A> @@ -65,8 +68,8 @@ a:visited { <ul> <li><a href="http://sourceforge.net/projects/mesa3d" target="_parent">SourceForge homepage</a> <li><a href="repository.html" target="MainFrame">Source Code Repository</a> +<li><a href="sourcetree.html" target="MainFrame">Source Code Tree</a> <li><a href="memory.html" target="MainFrame">DRI Memory Management</a> -<li><a href="shading.html" target="MainFrame">Shading Language</a> <li><a href="glu.html" target="MainFrame">SGI's GLU</a> <li><a href="utilities.html" target="MainFrame">Utilities</a> <li><a href="helpwanted.html" target="MainFrame">Help Wanted</a> @@ -89,7 +92,6 @@ a:visited { <li><a href="modelers.html" target="MainFrame">Modeling and Rendering</a> <li><a href="science.html" target="MainFrame">Science and Technical</a> <li><a href="utility.html" target="MainFrame">Utilities</a> -<li><a href="demos.html" target="MainFrame">Demos / other</a> </ul> <b>Hosted by:</b> diff --git a/mesalib/docs/demos.html b/mesalib/docs/demos.html deleted file mode 100644 index b4a2cc5e3..000000000 --- a/mesalib/docs/demos.html +++ /dev/null @@ -1,18 +0,0 @@ -<HTML> - -<TITLE>Demos</TITLE> - -<link rel="stylesheet" type="text/css" href="mesa.css"></head> - -<BODY> - -<H1>Demos</H1> - - -<ul> -<li><a href="http://www.geocities.com/shobhand/homepage.html">Shobhan Dutta's Geartrain and Walkthrough Demos</a> -</li></ul> - - -</body> -</html>
\ No newline at end of file diff --git a/mesalib/docs/devinfo.html b/mesalib/docs/devinfo.html index 0fb816749..df0e72652 100644 --- a/mesalib/docs/devinfo.html +++ b/mesalib/docs/devinfo.html @@ -107,7 +107,7 @@ Global variables are not allowed. Function name examples: </p> <pre> - glFooBar() - a public GL entry point (in dispatch.c) + glFooBar() - a public GL entry point (in glapi_dispatch.c) _mesa_FooBar() - the internal immediate mode function save_FooBar() - retained mode (display list) function in dlist.c foo_bar() - a static (private) function diff --git a/mesalib/docs/dispatch.html b/mesalib/docs/dispatch.html index bcab74c70..e5587c1a2 100644 --- a/mesalib/docs/dispatch.html +++ b/mesalib/docs/dispatch.html @@ -199,7 +199,7 @@ few preprocessor defines.</p> <li>If <tt>GLX_USE_TLS</tt> is defined, method #4 is used.</li> <li>If <tt>PTHREADS</tt> is defined, method #3 is used.</li> <li>If any of <tt>PTHREADS</tt>, -<tt>SOLARIS_THREADS</tt>, <tt>WIN32_THREADS</tt>, or <tt>BEOS_THREADS</tt> +<tt>WIN32_THREADS</tt>, or <tt>BEOS_THREADS</tt> is defined, method #2 is used.</li> <li>If none of the preceeding are defined, method #1 is used.</li> </ul> @@ -244,8 +244,8 @@ isn't a significant problem.</p> system. There are two steps to this. The file must first be added to <tt>src/mesa/sources</tt>. That gets the file built and linked. The second step is to add the correct <tt>#ifdef</tt> magic to -<tt>src/mesa/main/dispatch.c</tt> to prevent the C version of the dispatch -functions from being built.</p> +<tt>src/mesa/glapi/glapi_dispatch.c</tt> to prevent the C version of the +dispatch functions from being built.</p> <A NAME="fixedsize"/> <H3>3.4. Fixed-Length Dispatch Stubs</H3> diff --git a/mesalib/docs/egl.html b/mesalib/docs/egl.html new file mode 100644 index 000000000..55907f6cf --- /dev/null +++ b/mesalib/docs/egl.html @@ -0,0 +1,324 @@ +<html> + +<title>Mesa EGL</title> + +<head><link rel="stylesheet" type="text/css" href="mesa.css"></head> + +<body> + +<h1>Mesa EGL</h1> + +<p>The current version of EGL in Mesa implements EGL 1.4. More information +about EGL can be found at +<a href="http://www.khronos.org/egl/" target="_parent"> +http://www.khronos.org/egl/</a>.</p> + +<p>The Mesa's implementation of EGL uses a driver architecture. The main +library (<code>libEGL</code>) is window system neutral. It provides the EGL +API entry points and helper functions for use by the drivers. Drivers are +dynamically loaded by the main library and most of the EGL API calls are +directly dispatched to the drivers.</p> + +<p>The driver in use decides the window system to support. For drivers that +support hardware rendering, there are usually multiple drivers supporting the +same window system. Each one of of them supports a certain range of graphics +cards.</p> + +<h2>Build EGL</h2> + +<ol> +<li> +<p>Run <code>configure</code> with the desired state trackers and enable +the Gallium driver for your hardware. For example</p> + +<pre> + $ ./configure --with-state-trackers=egl,es,vega --enable-gallium-{swrast,intel} +</pre> + +<p>The main library will be enabled by default. The <code>egl</code> state +tracker is needed by a number of EGL drivers. EGL drivers will be covered +later. The <a href="opengles.html">es state tracker</a> provides OpenGL ES 1.x +and 2.x and the <a href="openvg.html">vega state tracker</a> provides OpenVG +1.x.</p> +</li> + +<li>Build and install Mesa as usual.</li> +</ol> + +<p>In the given example, it will build and install <code>libEGL</code>, +<code>libGLESv1_CM</code>, <code>libGLESv2</code>, <code>libOpenVG</code>, and +one or more EGL drivers.</p> + +<h3>Configure Options</h3> + +<p>There are several options that control the build of EGL at configuration +time</p> + +<ul> +<li><code>--enable-egl</code> + +<p>By default, EGL is enabled. When disabled, the main library and the drivers +will not be built.</p> + +</li> + +<li><code>--with-egl-driver-dir</code> + +<p>The directory EGL drivers should be installed to. If not specified, EGL +drivers will be installed to <code>${libdir}/egl</code>.</p> + +</li> + +<li><code>--with-egl-displays</code> + +<p>List the window system(s) to support. It is by default <code>x11</code>, +which supports the X Window System. Its argument is a comma separated string +like, for example, <code>--with-egl-displays=x11,kms</code>. Because an EGL +driver decides which window system to support, this example will enable two +(sets of) EGL drivers. One supports the X window system and the other supports +bare KMS (kernel modesetting).</p> + +</li> + +<li><code>--with-state-trackers</code> + +<p>The argument is a comma separated string. It is usually used to specify the +rendering APIs, like OpenGL ES or OpenVG, to build. But it should be noted +that a number of EGL drivers depend on the <code>egl</code> state tracker. +They will <em>not</em> be built without the <code>egl</code> state tracker.</p> + +</li> + +<li><code>--enable-gallium-swrast</code> + +<p>This option is not specific to EGL. But if there is no driver for your +hardware, or you are experiencing problems with the hardware driver, you can +enable the swrast DRM driver. It is a dummy driver and EGL will fallback to +software rendering automatically.</p> + +</li> +</ul> + +<h3>OpenGL</h3> + +<p>The OpenGL state tracker is not built in the above example. It should be +noted that the classic <code>libGL</code> is not a state tracker and cannot be +used with EGL (unless the EGL driver in use is <code>egl_glx</code>). To build +the OpenGL state tracker, one may append <code>glx</code> to +<code>--with-state-trackers</code> and manually build +<code>src/gallium/winsys/xlib/</code>.</p> + +<h2>Use EGL</h2> + +<p> The demos for OpenGL ES and OpenVG can be found in <code>progs/es1/</code>, +<code>progs/es2/</code> and <code>progs/openvg/</code>. You can use them to +test your build. For example,</p> + +<pre> + $ cd progs/es1/xegl + $ make + $ ./torus +</pre> + +<h3>Environment Variables</h3> + +<p>There are several environment variables that control the behavior of EGL at +runtime</p> + +<ul> +<li><code>EGL_DRIVERS_PATH</code> + +<p>By default, the main library will look for drivers in the directory where +the drivers are installed to. This variable specifies a list of +colon-separated directories where the main library will look for drivers, in +addition to the default directory. This variable is ignored for setuid/setgid +binaries.</p> + +</li> + +<li><code>EGL_DRIVER</code> + +<p>This variable specifies a full path to an EGL driver and it forces the +specified EGL driver to be loaded. It comes in handy when one wants to test a +specific driver. This variable is ignored for setuid/setgid binaries.</p> + +</li> + +<li><code>EGL_DISPLAY</code> + +<p>When <code>EGL_DRIVER</code> is not set, the main library loads <em>all</em> +EGL drivers that support a certain window system. <code>EGL_DISPLAY</code> can +be used to specify the window system and the valid values are, for example, +<code>x11</code> or <code>kms</code>. When the variable is not set, the main +library defaults the value to the first window system listed in +<code>--with-egl-displays</code> at configuration time. + +</li> + +<li><code>EGL_LOG_LEVEL</code> + +<p>This changes the log level of the main library and the drivers. The valid +values are: <code>debug</code>, <code>info</code>, <code>warning</code>, and +<code>fatal</code>.</p> + +</li> + +<li><code>EGL_SOFTWARE</code> + +<p>For drivers that support both hardware and software rendering, setting this +variable to true forces the use of software rendering.</p> + +</li> +</ul> + +<h2>EGL Drivers</h2> + +<p>There are two categories of EGL drivers: Gallium and classic.</p> + +<p>Gallium EGL drivers supports all rendering APIs specified in EGL 1.4. The +support for optional EGL functions and EGL extensions is usually more complete +than the classic ones. These drivers depend on the <code>egl</code> state +tracker to build. The available drivers are</p> + +<ul> +<li><code>egl_<dpy>_i915</code></li> +<li><code>egl_<dpy>_i965</code></li> +<li><code>egl_<dpy>_radeon</code></li> +<li><code>egl_<dpy>_nouveau</code></li> +<li><code>egl_<dpy>_swrast</code></li> +<li><code>egl_<dpy>_vmwgfx</code></li> +</ul> + +<p><code><dpy></code> is given by <code>--with-egl-displays</code> at +configuration time. There will be one EGL driver for each combination of the +displays listed and the hardware drivers enabled.</p> + +<p>Classic EGL drivers, on the other hand, supports only OpenGL as its +rendering API. They can be found under <code>src/egl/drivers/</code>. There +are 3 of them</p> + +<ul> +<li><code>egl_glx</code> + +<p>This driver provides a wrapper to GLX. It uses exclusively GLX to implement +the EGL API. It supports both direct and indirect rendering when the GLX does. +It is accelerated when the GLX is. As such, it cannot provide functions that +is not available in GLX or GLX extensions.</p> +</li> + +<li><code>egl_dri2</code> + +<p>This driver supports the X Window System as its window system. It functions +as a DRI2 driver loader. Unlike <code>egl_glx</code>, it has no dependency on +<code>libGL</code>. It talks to the X server directly using DRI2 protocol.</p> + +</li> +<li><code>egl_dri</code> + +<p>This driver lacks maintenance and does <em>not</em> build. It is similiar +to <code>egl_dri2</code> in that it functions as a DRI(1) driver loader. But +unlike <code>egl_dri2</code>, it supports Linux framebuffer devices as its +window system and supports EGL_MESA_screen_surface extension. As DRI1 drivers +are phasing out, it might eventually be replaced by <code>egl_dri2</code>.</p> + +</li> +</ul> + +<p>To use the classic drivers, one must manually set <code>EGL_DRIVER</code> at +runtime.</p> + +<h2>Developers</h2> + +<p>The sources of the main library and the classic drivers can be found at +<code>src/egl/</code>. The sources of the <code>egl</code> state tracker can +be found at <code>src/gallium/state_trackers/egl/</code>.</p> + +<p>The suggested way to learn to write a EGL driver is to see how other drivers +are written. <code>egl_glx</code> should be a good reference. It works in any +environment that has GLX support, and it is simpler than most drivers.</p> + +<h3>Lifetime of Display Resources</h3> + +<p>Contexts and surfaces are examples of display resources. They might live +longer than the display that creates them.</p> + +<p>In EGL, when a display is terminated through <code>eglTerminate</code>, all +display resources should be destroyed. Similarly, when a thread is released +throught <code>eglReleaseThread</code>, all current display resources should be +released. Another way to destory or release resources is through functions +such as <code>eglDestroySurface</code> or <code>eglMakeCurrent</code>.</p> + +<p>When a resource that is current to some thread is destroyed, the resource +should not be destroyed immediately. EGL requires the resource to live until +it is no longer current. A driver usually calls +<code>eglIs<Resource>Bound</code> to check if a resource is bound +(current) to any thread in the destroy callbacks. If it is still bound, the +resource is not destroyed.</p> + +<p>The main library will mark destroyed current resources as unlinked. In a +driver's <code>MakeCurrent</code> callback, +<code>eglIs<Resource>Linked</code> can then be called to check if a newly +released resource is linked to a display. If it is not, the last reference to +the resource is removed and the driver should destroy the resource. But it +should be careful here because <code>MakeCurrent</code> might be called with an +uninitialized display.</p> + +<p>This is the only mechanism provided by the main library to help manage the +resources. The drivers are responsible to the correct behavior as defined by +EGL.</p> + +<h3><code>EGL_RENDER_BUFFER</code></h3> + +<p>In EGL, the color buffer a context should try to render to is decided by the +binding surface. It should try to render to the front buffer if the binding +surface has <code>EGL_RENDER_BUFFER</code> set to +<code>EGL_SINGLE_BUFFER</code>; If the same context is later bound to a +surface with <code>EGL_RENDER_BUFFER</code> set to +<code>EGL_BACK_BUFFER</code>, the context should try to render to the back +buffer. However, the context is allowed to make the final decision as to which +color buffer it wants to or is able to render to.</p> + +<p>For pbuffer surfaces, the render buffer is always +<code>EGL_BACK_BUFFER</code>. And for pixmap surfaces, the render buffer is +always <code>EGL_SINGLE_BUFFER</code>. Unlike window surfaces, EGL spec +requires their <code>EGL_RENDER_BUFFER</code> values to be honored. As a +result, a driver should never set <code>EGL_PIXMAP_BIT</code> or +<code>EGL_PBUFFER_BIT</code> bits of a config if the contexts created with the +config won't be able to honor the <code>EGL_RENDER_BUFFER</code> of pixmap or +pbuffer surfaces.</p> + +<p>It should also be noted that pixmap and pbuffer surfaces are assumed to be +single-buffered, in that <code>eglSwapBuffers</code> has no effect on them. It +is desirable that a driver allocates a private color buffer for each pbuffer +surface created. If the window system the driver supports has native pbuffers, +or if the native pixmaps have more than one color buffers, the driver should +carefully attach the native color buffers to the EGL surfaces, re-route them if +required.</p> + +<p>There is no defined behavior as to, for example, how +<code>glDrawBuffer</code> interacts with <code>EGL_RENDER_BUFFER</code>. Right +now, it is desired that the draw buffer in a client API be fixed for pixmap and +pbuffer surfaces. Therefore, the driver is responsible to guarantee that the +client API renders to the specified render buffer for pixmap and pbuffer +surfaces.</p> + +<h3><code>EGLDisplay</code> Mutex</h3> + +The <code>EGLDisplay</code> will be locked before calling any of the dispatch +functions (well, except for GetProcAddress which does not take an +<code>EGLDisplay</code>). This guarantees that the same dispatch function will +not be called with the sample display at the same time. If a driver has access +to an <code>EGLDisplay</code> without going through the EGL APIs, the driver +should as well lock the display before using it. + +<h3>TODOs</h3> + +<ul> +<li>Pass the conformance tests</li> +<li>Better automatic driver selection: <code>EGL_DISPLAY</code> loads all +drivers and might eat too much memory.</li> + +</ul> + +</body> +</html> diff --git a/mesalib/docs/envvars.html b/mesalib/docs/envvars.html index b2c0e01ee..fd1700a02 100644 --- a/mesalib/docs/envvars.html +++ b/mesalib/docs/envvars.html @@ -51,5 +51,28 @@ See the <A HREF="xlibdriver.html">Xlib software driver page</A> for details. </ul> +<p> +These environment variables are for the Intel i945/i965 drivers: +</p> +<ul> +<li>INTEL_STRICT_CONFORMANCE - if set to 1, enable sw fallbacks to improve + OpenGL conformance. If set to 2, always use software rendering. +<li>INTEL_NO_BLIT - if set, disable hardware-accelerated glBitmap, + glCopyPixels, glDrawPixels. +</ul> + + +<p> +These environment variables are for the Radeon R300 driver: +</p> +<ul> +<li>R300_NO_TCL - if set, disable hardware-accelerated Transform/Clip/Lighting. +</ul> + +<p> +Mesa EGL supports different sets of environment variables. See the +<a href="egl.html">Mesa EGL</a> page for the details. +</p> + </BODY> </HTML> diff --git a/mesalib/docs/install.html b/mesalib/docs/install.html index 8c24cee7a..5aea92e0b 100644 --- a/mesalib/docs/install.html +++ b/mesalib/docs/install.html @@ -352,19 +352,10 @@ by -debug for debug builds. </p> <p> -The sample programs are built seperately. To build them do -<pre> - scons -C progs -</pre> -And the build output will be placed in progs/build/... -</p> - -<p> To build Mesa with SCons for Windows on Linux using the MinGW crosscompiler toolchain do </p> <pre> scons platform=windows toolchain=crossmingw machine=x86 statetrackers=mesa drivers=softpipe,trace winsys=gdi - scons -C progs platform=windows toolchain=crossmingw machine=x86 -k </pre> <p> This will create: diff --git a/mesalib/docs/lists.html b/mesalib/docs/lists.html index 5227fbd05..9c17a9f35 100644 --- a/mesalib/docs/lists.html +++ b/mesalib/docs/lists.html @@ -13,36 +13,41 @@ </p> <ul> -<li><a href="https://lists.sourceforge.net/lists/listinfo/mesa3d-announce" -target="_parent">mesa3d-announce</a> - announcements of new Mesa -versions are sent to this list. -</li> -<br> <li><a href="https://lists.sourceforge.net/lists/listinfo/mesa3d-users" -target="_parent">mesa3d-users</a> - intended for users of the Mesa and DRI. -Newbie questions are appropriate, but please try the general OpenGL +target="_parent">mesa3d-users</a> - intended for end-users of Mesa and DRI +drivers. Newbie questions are OK, but please try the general OpenGL resources and Mesa/DRI documentation first. </li> <br> <li><a href="https://lists.sourceforge.net/lists/listinfo/mesa3d-dev" -target="_parent">mesa3d-dev</a> - for discussion of Mesa and Direct Rendering -Infrastructure development. Not for beginners. +target="_parent">mesa3d-dev</a> - for Mesa, Gallium and DRI development +discussion. Not for beginners. </li> <br> <li><a href="http://lists.freedesktop.org/mailman/listinfo/mesa-commit" target="_parent">mesa-commit</a> - relays git check-in messages (for developers). +In general, people should not post to this list. +</li> <br> -Note: the old mesa3d-cvs list is no longer in use. +<li><a href="https://lists.sourceforge.net/lists/listinfo/mesa3d-announce" +target="_parent">mesa3d-announce</a> - announcements of new Mesa +versions are sent to this list. Very low traffic. </li> </ul> +<p> +Follow the links above for list archives. +</p> + <p>For mailing lists about Direct Rendering Modules (drm) in Linux/BSD -kernels, see <a href="http://dri.freedesktop.org/wiki/MailingLists">wiki</a>. +kernels, see the +<a href="http://dri.freedesktop.org/wiki/MailingLists" target="_parent"> +DRI wiki</a>. +</p> <p> -<b>Notice</b>: non-member posts to any of these lists will be automatically -rejected. +<b>Notice</b>: You must subscribe to these lists in order to post to them. </p> diff --git a/mesalib/docs/news.html b/mesalib/docs/news.html index 2abec2e63..a60d7a87d 100644 --- a/mesalib/docs/news.html +++ b/mesalib/docs/news.html @@ -10,11 +10,28 @@ <H1>News</H1> -<h2>November XX, 2009</h2> + +<h2>March 26, 2010</h2> +<p> +<a href="relnotes-7.7.1.html">Mesa 7.7.1</a> is released. This is a bug-fix +release fixing issues found in the 7.7 release. +</p> +<p> +Also, <a href="relnotes-7.8.html">Mesa 7.8</a> is released. This is a new +development release. +</p> + + + +<h2>December 21, 2009</h2> <p> <a href="relnotes-7.6.1.html">Mesa 7.6.1</a> is released. This is a bug-fix release fixing issues found in the 7.6 release. </p> +<p> +Also, <a href="relnotes-7.7.html">Mesa 7.7</a> is released. This is a new +development release. +</p> <h2>September 28, 2009</h2> diff --git a/mesalib/docs/opengles.html b/mesalib/docs/opengles.html new file mode 100644 index 000000000..fc41e6771 --- /dev/null +++ b/mesalib/docs/opengles.html @@ -0,0 +1,79 @@ +<html> + +<title>OpenGL ES State Trackers</title> + +<head><link rel="stylesheet" type="text/css" href="mesa.css"></head> + +<body> + +<h1>OpenGL ES State Trackers</h1> + +<p>The current version of the OpenGL ES state trackers implement OpenGL ES 1.1 and OpenGL ES 2.0. +More informations about OpenGL ES can be found at +<a href="http://www.khronos.org/opengles/" target="_parent"> +http://www.khronos.org/opengles/</a>.</p> + +<p>The OpenGL ES state trackers depends on the Gallium architecture and a +working EGL implementation. Please refer to <a href="egl.html">Mesa EGL</a> +for more information about EGL.</p> + + +<h2>Build the Libraries</h2> +<ol> +<li>Run <code>configure</code> with <code>--with-state-trackers=egl,es</code> and enable the Gallium driver for your hardware.</li> +<li>Build and install Mesa as usual.</li> +</ol> + +<p>It will install libGLESv1_CM, libGLESv2, libEGL, and one or more EGL drivers for your hardware.</p> +<h2>Run the Demos</h2> + +<p>There are some demos in <code>progs/es1/</code> and <code>progs/es2/</code>. You can use them to test your build. For example,</p> + +<pre> + $ cd progs/es1/xegl + $ make + $ ./torus +</pre> + +<h2>Developers</h2> + +<p>The core of OpenGL ES state trackers is the ES overlay. It is located in +<code>src/mesa/es/</code>.</p> + +<h3>Structure</h3> + +<p>The ES overlay uses as much code as possible from Mesa. It has its own glapi XMLs to describe the APIs of OpenGL ES. The ES overlay can be built parallelly with Mesa, and they will give</p> + +<table border="1"> + <tr><td>Library Name</td><td>Usage</td><td>Source</td></tr> + <tr><td>libmesagallium.a</td><td>OpenGL state tracker</td><td>Mesa</td></tr> + <tr><td>libes1gallium.a</td><td>OpenGL ES 1.x state tracker</td><td>ES overlay</td></tr> + <tr><td>libes2gallium.a</td><td>OpenGL ES 2.x state tracker</td><td>ES overlay</td></tr> + <tr><td>libglapi.a</td><td>OpenGL API</td><td>Mesa</td></tr> + <tr><td>libes1api.a</td><td>OpenGL ES 1.x API</td><td>ES overlay</td></tr> + <tr><td>libes2api.a</td><td>OpenGL ES 2.x API</td><td>ES overlay</td></tr> +</table> + +<p>The OpenGL ES state trackers and APIs are then used by <code>src/gallium/state_trackers/es/</code> to create the final libraries.</p> + +<h3>Dispatch Table</h3> + +<p>The ES overlay uses an additional indirection when dispatching fucntions</p> + +<pre> + Mesa: glFoo() --> _mesa_Foo() + ES overlay: glFoo() --> _es_Foo() --> _mesa_Foo() +</pre> + +<p>The indirection serves several purposes</p> + +<ul> +<li>When a function is in Mesa and the type matches, it checks the arguments and calls the Mesa function.</li> +<li>When a function is in Mesa but the type mismatches, it checks and converts the arguments before calling the Mesa function.</li> +<li>When a function is not available in Mesa, or accepts arguments that are not available in OpenGL, it provides its own implementation.</li> +</ul> + +<p>Other than the last case, the ES overlay uses <code>APIspec.xml</code> to generate functions to check and/or converts the arguments.</p> + +</body> +</html> diff --git a/mesalib/docs/openvg.html b/mesalib/docs/openvg.html index 442ee522f..cdf6b57e0 100644 --- a/mesalib/docs/openvg.html +++ b/mesalib/docs/openvg.html @@ -1,6 +1,6 @@ <HTML> -<TITLE>Mesa Release Notes</TITLE> +<TITLE>OpenVG State Tracker</TITLE> <head><link rel="stylesheet" type="text/css" href="mesa.css"></head> @@ -20,12 +20,13 @@ http://www.khronos.org/openvg/</a> . </p> <p> The OpenVG state tracker depends on the Gallium architecture and a working EGL implementation. +Please refer to <a href="egl.html">Mesa EGL</a> for more information about EGL. </p> <h2>Building the library</h2> <ol> -<li>Build Mesa3D with Gallium3D. Any build that builds Gallium3D libraries and EGL will suffice</li> +<li>Build Mesa3D with Gallium3D. Any build that builds Gallium3D libraries, EGL, and Gallium EGL drivers will suffice</li> <li>cd src/gallium/state_trackers/vega; make</li> <li>The last step will build libOpenVG library. You can add the libdir to LD_LIBRARY_PATH or install libOpenVG</li> </ol> @@ -33,12 +34,9 @@ The OpenVG state tracker depends on the Gallium architecture and a working EGL i <h3>Sample build</h3> A sample build looks as follows: <pre> - make linux-x86-64-debug - cd src/gallium/state_trackers/vega - make - cd ../../../.. - export LD_LIBRARY_PATH=$PWD/lib64 - export EGL_DRIVER="egl_softpipe" + $ ./configure --with-state-trackers=egl,vega --enable-gallium-intel + $ make + $ make install </pre> <h2>OpenVG Demos</h2> @@ -59,10 +57,5 @@ To run a demo: </pre> -<h2>Notes</h2> -<ul> -<li>EGL_DRIVER environmental variable: forces usage of a specific EGL driver. Unless you force egl_softpipe the implementation will look for a DRI hardware accelerate driver and unless you have a Gallium driver that supports it, you'll see crashes</li> -</ul> - </body> </html> diff --git a/mesalib/docs/osmesa.html b/mesalib/docs/osmesa.html index 629d054f4..525da4d42 100644 --- a/mesalib/docs/osmesa.html +++ b/mesalib/docs/osmesa.html @@ -26,7 +26,7 @@ more information about the API functions. </p> <p> -There are several examples of OSMesa in the <code>progs/osdemo/</code> +There are several examples of OSMesa in the <code>progs/osdemos/</code> directory. </p> diff --git a/mesalib/docs/pbuffers.html b/mesalib/docs/pbuffers.html deleted file mode 100644 index 259910155..000000000 --- a/mesalib/docs/pbuffers.html +++ /dev/null @@ -1,54 +0,0 @@ -<HTML> - -<TITLE>PBuffer Rendering</TITLE> - -<link rel="stylesheet" type="text/css" href="mesa.css"></head> - -<BODY> - -<H1>PBuffer Rendering</H1> - -<p> -Basically, FBconfigs and PBuffers allow you to do off-screen rendering -with OpenGL. The OSMesa interface does basically the same thing, but -fbconfigs and pbuffers are supported by more vendors. -PBuffer rendering may also be hardware accelerated. -</p> - -<p> -PBuffers are getting more use nowadays, though they've actually been -around for a long time on IRIX systems and other workstations. -</p> - -<p> -The -<a href="http://oss.sgi.com/projects/ogl-sample/registry/SGIX/fbconfig.txt" -target="_parent">GL_SGIX_fbconfig</a> -and -<a href="http://oss.sgi.com/projects/ogl-sample/registry/SGIX/pbuffer.txt" -target="_parent"> -GL_SGIX_pbuffer</a> extensions describe the functionality. -More recently, these extensions have been promoted to ARB extensions (on -Windows at least). -</p> - -<p> -The Mesa/progs/xdemos/ directory has some useful code for working -with pbuffers: -</p> - -<ul> -<li><b>pbinfo.c</b> - like glxinfo, it prints a list of available - fbconfigs and whether each supports pbuffers. -<li><b>pbutil.c</b> - a few utility functions for dealing with - fbconfigs and pbuffers. -<li><b>pbdemo.c</b> - a demonstration of off-screen rendering with pbuffers. -</ul> - -<p> -Mesa 4.1 and later support GL_SGIX_fbconfig and GL_SGIX_pbuffer (software -rendering only). -</p> - -</BODY> -</HTML> diff --git a/mesalib/docs/relnotes-7.6.1.html b/mesalib/docs/relnotes-7.6.1.html index a41bcee81..1d0ecd2ac 100644 --- a/mesalib/docs/relnotes-7.6.1.html +++ b/mesalib/docs/relnotes-7.6.1.html @@ -8,7 +8,7 @@ <body bgcolor="#eeeeee"> -<H1>Mesa 7.6.1 Release Notes, (date tbd)</H1> +<H1>Mesa 7.6.1 Release Notes, 21 December 2009</H1> <p> Mesa 7.6.1 is a bug-fix release fixing issues since version 7.6. @@ -26,7 +26,15 @@ for DRI hardware acceleration. <h2>MD5 checksums</h2> <pre> -tbd +e80fabad2e3eb7990adae773d6aeacba MesaLib-7.6.1.tar.gz +7db4617e9e10ad3aca1b64339fd71b7d MesaLib-7.6.1.tar.bz2 +dd3275dbf9833480d2e92d0c69b22abd MesaLib-7.6.1.zip +f7fdcfe3c0f363e571c60f02f74368fb MesaDemos-7.6.1.tar.gz +a4226f06732a02556fcf6be290b86dff MesaDemos-7.6.1.tar.bz2 +849425f356bd940726cebedfa79de176 MesaDemos-7.6.1.zip +d40cc7c5e337a85b674e27a8e494f52f MesaGLUT-7.6.1.tar.gz +ca9aecb91f05b1da9fd7d5eeb19d47d7 MesaGLUT-7.6.1.tar.bz2 +23fad8398004c977a1d8953079b72ca6 MesaGLUT-7.6.1.zip </pre> diff --git a/mesalib/docs/relnotes-7.7.1.html b/mesalib/docs/relnotes-7.7.1.html new file mode 100644 index 000000000..00b36714c --- /dev/null +++ b/mesalib/docs/relnotes-7.7.1.html @@ -0,0 +1,60 @@ +<HTML> + +<TITLE>Mesa Release Notes</TITLE> + +<head><link rel="stylesheet" type="text/css" href="mesa.css"></head> + +<BODY> + +<body bgcolor="#eeeeee"> + +<H1>Mesa 7.7.1 Release Notes / March 28, 2010</H1> + +<p> +Mesa 7.7.1 is a bug-fix release. +</p> +<p> +Mesa 7.7.1 implements the OpenGL 2.1 API, but the version reported by +glGetString(GL_VERSION) depends on the particular driver being used. +Some drivers don't support all the features required in OpenGL 2.1. +</p> +<p> +See the <a href="install.html">Compiling/Installing page</a> for prerequisites +for DRI hardware acceleration. +</p> + + +<h2>MD5 checksums</h2> +<pre> +3ab0638cfa7ce8157337a229cf0db2c4 MesaLib-7.7.1.tar.gz +46664d99e03f1e3ac078a7fea02af115 MesaLib-7.7.1.tar.bz2 +4e73ba8abb59aff79485eb95d7cefff7 MesaLib-7.7.1.zip +bf1b108983995f7a712cf3343df1c918 MesaDemos-7.7.1.tar.gz +aeb39645d80d656e0adebaa09e5bcd03 MesaDemos-7.7.1.tar.bz2 +01c49b7454fd292244eaf8bdc6ed8cf0 MesaDemos-7.7.1.zip +37ec6386693dcb6dc770d1efd63a7a93 MesaGLUT-7.7.1.tar.gz +1e16c85282f843791a21f7bc7b6a1ca8 MesaGLUT-7.7.1.tar.bz2 +d352c9e36a8e4d1059f4abc017b131e0 MesaGLUT-7.7.1.zip +</pre> + + +<h2>Bug fixes</h2> +<ul> +<li>Assorted fixes to VMware SVGA gallium driver. +<li>Fixed broken blending to multiple color buffers in swrast driver. +<li>Allocate constants more tightly in GL_ARB_vertex/fragment parser. +<li>Fixed mipmap generation bug caused by invalid viewport state. +<li>Gallium SSE codegen for XPD didn't always work. +<li>Fixed Windows build. +<li>Fixed broken glMultiDrawElements(). +<li>Silence bogus GL errors generated in glxinfo. +<li>Fixed several render to texture bugs. +<li>Assorted bug fixes in Mesa/Gallium state tracker including + glCopy/DrawPixels() to FBOs. +<li>Assorted fixes to Gallium drivers. +<li>Fixed broken glPush/PopClientAttrib() for vertex arrays in GLX code. +</ul> + + +</body> +</html> diff --git a/mesalib/docs/relnotes-7.7.html b/mesalib/docs/relnotes-7.7.html index 8c8f763b6..c1ed65461 100644 --- a/mesalib/docs/relnotes-7.7.html +++ b/mesalib/docs/relnotes-7.7.html @@ -8,7 +8,7 @@ <body bgcolor="#eeeeee"> -<H1>Mesa 7.7 Release Notes / date TBD</H1> +<H1>Mesa 7.7 Release Notes / 21 December 2009</H1> <p> Mesa 7.7 is a new development release. @@ -28,7 +28,15 @@ for DRI hardware acceleration. <h2>MD5 checksums</h2> <pre> -tbd +395c9516edf1ad54b0934d8db15557bf MesaLib-7.7.tar.gz +e3fa64a1508bc23dd9de9dd2cea7cfb1 MesaLib-7.7.tar.bz2 +e54903eb5e49c3969821fa16b32da245 MesaLib-7.7.zip +53b5b6f78e55de170d43c98cb6aaab7e MesaDemos-7.7.tar.gz +6fd616b27b9826d0faa23e08e05d9435 MesaDemos-7.7.tar.bz2 +240fe06159ad73d5e22c27033b66c80a MesaDemos-7.7.zip +9fe11a904b2a9d8cd06cc52bc330b716 MesaGLUT-7.7.tar.gz +e8dceed05a59a2d3c2619d7d734587e3 MesaGLUT-7.7.tar.bz2 +96af041d435349ee23ead4667ec36363 MesaGLUT-7.7.zip </pre> diff --git a/mesalib/docs/relnotes-7.8.html b/mesalib/docs/relnotes-7.8.html new file mode 100644 index 000000000..9622d1665 --- /dev/null +++ b/mesalib/docs/relnotes-7.8.html @@ -0,0 +1,62 @@ +<HTML> + +<TITLE>Mesa Release Notes</TITLE> + +<head><link rel="stylesheet" type="text/css" href="mesa.css"></head> + +<BODY> + +<body bgcolor="#eeeeee"> + +<H1>Mesa 7.8 Release Notes / March 28, 2010</H1> + +<p> +Mesa 7.8 is a new development release. +People who are concerned with stability and reliability should stick +with a previous release or wait for Mesa 7.8.1. +</p> +<p> +Mesa 7.8 implements the OpenGL 2.1 API, but the version reported by +glGetString(GL_VERSION) depends on the particular driver being used. +Some drivers don't support all the features required in OpenGL 2.1. +</p> +<p> +See the <a href="install.html">Compiling/Installing page</a> for prerequisites +for DRI hardware acceleration. +</p> + + +<h2>MD5 checksums</h2> +<pre> +tbd +</pre> + + +<h2>New features</h2> +<ul> +<li>GL_NV_conditional_render extension (swrast driver only) +<li>GL_EXT_draw_buffers2 extension (swrast and i965 driver only) +<li>GL_ARB_fragment_coord_conventions extension (for swrast, i965, and Gallium drivers) +<li>GL_EXT_texture_array extension (swrast driver only) +<li>GL_APPLE_object_purgeable extension (swrast and i945/i965 DRI drivers) +<li>Much improved support for <a href="egl.html">EGL in Mesa</a> +<li>New state trackers for <a href="opengles.html">OpenGL ES 1.1 and 2.0</a> +<li>Dedicated documentation for Gallium +</ul> + + +<h2>Bug fixes</h2> +<ul> +<li>Massive improvements to the Gallium driver for R300-R500 Radeons; this + driver is now moderately stable but not terribly performant. +</ul> + + +<h2>Changes</h2> +<ul> +<li>Removed support for color-index rendering</li> +<li>Removed support for GCC versions earlier than 3.3.0.</li> +</ul> + +</body> +</html> diff --git a/mesalib/docs/relnotes.html b/mesalib/docs/relnotes.html index b301ee046..3e17a1e94 100644 --- a/mesalib/docs/relnotes.html +++ b/mesalib/docs/relnotes.html @@ -13,6 +13,8 @@ The release notes summarize what's new or changed in each Mesa release. </p> <UL> +<LI><A HREF="relnotes-7.8.html">7.8 release notes</A> +<LI><A HREF="relnotes-7.7.1.html">7.7.1 release notes</A> <LI><A HREF="relnotes-7.7.html">7.7 release notes</A> <LI><A HREF="relnotes-7.6.1.html">7.6.1 release notes</A> <LI><A HREF="relnotes-7.6.html">7.6 release notes</A> diff --git a/mesalib/docs/repository.html b/mesalib/docs/repository.html index ed385288e..95d274a7a 100644 --- a/mesalib/docs/repository.html +++ b/mesalib/docs/repository.html @@ -1,6 +1,6 @@ <HTML> -<TITLE>Cocd Repository</TITLE> +<TITLE>Code Repository</TITLE> <link rel="stylesheet" type="text/css" href="mesa.css"></head> @@ -9,11 +9,8 @@ <h1>Code Repository</h1> <p> -As of December 5, 2006, Mesa is using -<a href="http://git.or.cz/"target="_parent">git</a> +Mesa uses <a href="http://git.or.cz/"target="_parent">git</a> as its source code management system. -CVS was used previously. -The old CVS repository should no longer be used. </p> The master git repository is hosted on @@ -125,6 +122,83 @@ Questions about branch status/activity should be posted to the mesa3d-dev mailing list. </p> +<H2>Developer Git Tips</H2> + +<ol> +<li>Setting up to edit the master branch +<p> +If you try to do a pull by just saying<code> git pull </code> +and git complains that you have not specified a +branch, try: +<pre> + git config branch.master.remote origin + git config branch.master.merge master +</pre> +Otherwise, you have to say<code> git pull origin master </code> +each time you do a pull. +</p> +<li>Small changes to master +<p> +If you are an experienced git user working on substancial modifications, +you are probably +working on a separate branch and would rebase your branch prior to +merging with master. +But for small changes to the master branch itself, +you also need to use the rebase feature in order to avoid an +unnecessary and distracting branch in master. +</p> +<p> +If it has been awhile since you've done the initial clone, try +<pre> + git pull +</pre> +to get the latest files before you start working. +</p> +<p> +Make your changes and use +<pre> + git add <files to commit> + git commit +</pre> +to get your changes ready to push back into the fd.o repository. +</p> +<p> +It is possible (and likely) that someone has changed master since +you did your last pull. Even if your changes do not conflict with +their changes, git will make a fast-forward +merge branch, branching from the point in time +where you did your last pull and merging it to a point after the other changes. +</p> +<p> +To avoid this, +<pre> + git pull --rebase + git push +</pre> +If you are familiar with CVS or similar system, this is similar to doing a +<code> cvs update </code> in order to update your source tree to +the current repository state, instead of the time you did the last update. +(CVS doesn't work like git in this respect, but this is easiest way +to explain it.) +</br> +In any case, your repository now looks like you made your changes after +all the other changes. +</p> +<p> +If the rebase resulted in conflicts or changes that could affect +the proper operation of your changes, you'll need to investigate +those before doing the push. +</p> +<p> +If you want the rebase action to be the default action, then +<pre> + git config branch.master.rebase true + git config --global branch.autosetuprebase=always +</pre> +<p> +See <a href="http://www.eecs.harvard.edu/~cduan/technical/git/" target="_parent">Understanding Git Conceptually</a> for a fairly clear explanation about all of this. +</p> +</ol> </body> </html> diff --git a/mesalib/docs/shading.html b/mesalib/docs/shading.html index bd02335a8..750884cf3 100644 --- a/mesalib/docs/shading.html +++ b/mesalib/docs/shading.html @@ -15,10 +15,6 @@ OpenGL Shading Language</a>. </p> <p> -Last updated on 15 December 2008. -</p> - -<p> Contents </p> <ul> diff --git a/mesalib/docs/sourcetree.html b/mesalib/docs/sourcetree.html new file mode 100644 index 000000000..00dc4e7c9 --- /dev/null +++ b/mesalib/docs/sourcetree.html @@ -0,0 +1,165 @@ +<HTML> + +<TITLE>Mesa Source Tree</TITLE> + +<link rel="stylesheet" type="text/css" href="mesa.css"></head> + +<BODY> + +<h1>Mesa source code tree overview</h1> + +<p> +This is a brief summary of Mesa's directory tree and what's contained in +each directory. +</p> + + +<ul> +<li><b>docs</b> - Documentation +<li><b>include</b> - Public OpenGL header files +<li><b>src</b> + <ul> + <li><b>egl</b> - EGL library sources + <ul> + <li><b>docs</b> - EGL documentation + <li><b>drivers</b> - EGL drivers + <li><b>main</b> - main EGL library implementation. This is where all + the EGL API functions are implemented, like eglCreateContext(). + </ul> + <li><b>mesa</b> - Main Mesa sources + <ul> + <li><b>glapi</b> - OpenGL API dispatch layer. This is where all the + GL entrypoints like glClear, glBegin, etc. are generated, as well as + the GL dispatch table. All GL function calls jump through the + dispatch table to functions found in main/. + <li><b>main</b> - The core Mesa code (mainly state management) + <li><b>drivers</b> - Mesa drivers (not used with Gallium) + <ul> + <li><b>common</b> - code which may be shared by all drivers + <li><b>dri</b> - Direct Rendering Infrastructure drivers + <ul> + <li><b>common</b> - code shared by all DRI drivers + <li><b>i915</b> - driver for Intel i915/i945 + <li><b>i965</b> - driver for Intel i965 + <li>XXX more + </ul> + <li><b>x11</b> - Xlib-based software driver + <li><b>osmesa</b> - off-screen software driver + <li><b>glslcompiler</b> - a stand-alone GLSL compiler driver + <li>XXX more + </ul> + <li><b>es</b> - OpenGL ES overlay, parallelly buildable with the core Mesa + <li><b>math</b> - vertex array translation and transformation code + (not used with Gallium) + <li><b>ppc</b> - Assembly code/optimizations for PPC systems + (not used with Gallium) + <li><b>shader</b> - Vertex/fragment shader and GLSL compiler code + <li><b>sparc</b> - Assembly code/optimizations for SPARC systems + (not used with Gallium) + <li><b>state_tracker</b> - State tracker / driver for Gallium. This + is basically a Mesa device driver that speaks to Gallium. This + directory may be moved to src/mesa/drivers/gallium at some point. + <li><b>swrast</b> - Software rasterization module. For drawing points, + lines, triangles, bitmaps, images, etc. in software. + (not used with Gallium) + <li><b>swrast_setup</b> - Software primitive setup. Does things like + polygon culling, glPolygonMode, polygon offset, etc. + (not used with Gallium) + <li><b>tnl</b> - Software vertex Transformation 'n Lighting. + (not used with Gallium) + <li><b>tnl_dd</b> - TNL code for device drivers. + (not used with Gallium) + <li><b>vbo</b> - Vertex Buffer Object code. All drawing with + glBegin/glEnd, glDrawArrays, display lists, etc. goes through this + module. The results is a well-defined set of vertex arrays which + are passed to the device driver (or tnl module) for rendering. + <li><b>vf</b> - vertex format conversion (currently unused) + <li><b>x86</b> - Assembly code/optimizations for 32-bit x86 systems + (not used with Gallium) + <li><b>x86-64</b> - Assembly code/optimizations for 64-bit x86 systems + (not used with Gallium) + </ul> + <li><b>gallium</b> - Gallium3D source code + <ul> + <li><b>include</b> - Gallium3D header files which define the Gallium3D + interfaces + <li><b>drivers</b> - Gallium3D device drivers + <ul> + <li><b>cell</b> - Driver for Cell processor. + <li><b>i915</b> - Driver for Intel i915/i945. + <li><b>i965</b> - Driver for Intel i965. + <li><b>llvmpipe</b> - Software driver using LLVM for runtime code generation. + <li><b>nv*</b> - Drivers for NVIDIA GPUs. + <li><b>r300</b> - Driver for ATI/AMD R300. + <li><b>softpipe</b> - Software reference driver. + <li><b>svga</b> - Driver for VMware's SVGA virtual GPU. + <li><b>trace</b> - Driver for tracing Gallium calls. + <li>XXX more + </ul> + <li><b>auxiliary</b> - Gallium support code + <ul> + <li><b>draw</b> - Software vertex processing and primitive assembly + module. This includes vertex program execution, clipping, culling + and optional stages for drawing wide lines, stippled lines, + polygon stippling, two-sided lighting, etc. + Intended for use by drivers for hardware that does not have + vertex shaders. + Geometry shaders will also be implemented in this module. + <li><b>cso_cache</b> - Constant State Objects Cache. Used to filter out + redundant state changes between state trackers and drivers. + <li><b>gallivm</b> - LLVM module for Gallium. For LLVM-based + compilation, optimization and code generation for TGSI shaders. + Incomplete. + <li><b>pipebuffer</b> - utility module for managing buffers + <li><b>rbug</b> - Gallium remote debug utility + <li><b>rtasm</b> - run-time assembly/machine code generation. + Currently there's run-time code generation for x86/SSE, PowerPC + and Cell SPU. + <li><b>tgsi</b> - TG Shader Infrastructure. Code for encoding, + manipulating and interpretting GPU programs. + <li><b>translate</b> - module for translating vertex data from one format + to another. + <li><b>util</b> - assorted utilities for arithmetic, hashing, surface + creation, memory management, 2D blitting, simple rendering, etc. + </ul> + <li><b>state_trackers</b> - + <ul> + <li><b>dri</b> - Meta state tracker for DRI drivers + <li><b>egl</b> - Meta state tracker for EGL drivers + <li><b>es</b> - OpenGL ES 1.x and 2.x state trackers + <li><b>g3dvl</b> - + <li><b>glx</b> - Meta state tracker for GLX + <li><b>python</b> - + <li><b>vega</b> - OpenVG 1.x state tracker + <li><b>wgl</b> - + <li><b>xorg</b> - Meta state tracker for Xorg video drivers + </ul> + <li><b>winsys</b> - + <ul> + <li><b>drm</b> - + <li><b>g3dvl</b> - + <li><b>gdi</b> - + <li><b>xlib</b> - + </ul> + </ul> + </ul> + <ul> + <li><b>glu</b> - The OpenGL Utility library + <ul> + <li><b>sgi</b> - GLU from SGI + <li><b>mesa</b> - Mesa version of GLU (deprecated) + </ul> + <li><b>glut</b> - Mark Kilgard's OpenGL OpenGL Utility Toolkit library + <li><b>glx</b> - The GLX library code for building libGL. This is used for + direct rendering drivers. It will dynamically load one of the + xxx_dri.so drivers. + <li><b>glw</b> - Widgets for Xt/Motif. + <li><b>glew</b> - OpenGL Extension Wrangler library (used by demo programs) + </ul> +<li><b>progs</b> - OpenGL test and demonstration programs +<li><b>lib</b> - where the GL libraries are placed +</ul> + + +</BODY> +</HTML> |