From 29b86f9852b2b7ecc31cdfee56679537e40bc6e2 Mon Sep 17 00:00:00 2001 From: marha Date: Mon, 12 Apr 2010 09:53:17 +0000 Subject: svn merge -r524:HEAD "^/branches/released" . --- mesalib/docs/MESA_swap_control.spec | 7 +- mesalib/docs/MiniGLX.html | 534 ------------------------------------ mesalib/docs/README.3DFX | 2 +- mesalib/docs/README.D3D | 124 --------- mesalib/docs/README.directfb | 29 -- mesalib/docs/contents.html | 8 +- mesalib/docs/demos.html | 18 -- mesalib/docs/devinfo.html | 2 +- mesalib/docs/dispatch.html | 6 +- mesalib/docs/egl.html | 324 ++++++++++++++++++++++ mesalib/docs/envvars.html | 23 ++ mesalib/docs/install.html | 9 - mesalib/docs/lists.html | 31 ++- mesalib/docs/news.html | 19 +- mesalib/docs/opengles.html | 79 ++++++ mesalib/docs/openvg.html | 19 +- mesalib/docs/osmesa.html | 2 +- mesalib/docs/pbuffers.html | 54 ---- mesalib/docs/relnotes-7.6.1.html | 12 +- mesalib/docs/relnotes-7.7.1.html | 60 ++++ mesalib/docs/relnotes-7.7.html | 12 +- mesalib/docs/relnotes-7.8.html | 62 +++++ mesalib/docs/relnotes.html | 2 + mesalib/docs/repository.html | 84 +++++- mesalib/docs/shading.html | 4 - mesalib/docs/sourcetree.html | 165 +++++++++++ 26 files changed, 869 insertions(+), 822 deletions(-) delete mode 100644 mesalib/docs/MiniGLX.html delete mode 100644 mesalib/docs/README.D3D delete mode 100644 mesalib/docs/README.directfb delete mode 100644 mesalib/docs/demos.html create mode 100644 mesalib/docs/egl.html create mode 100644 mesalib/docs/opengles.html delete mode 100644 mesalib/docs/pbuffers.html create mode 100644 mesalib/docs/relnotes-7.7.1.html create mode 100644 mesalib/docs/relnotes-7.8.html create mode 100644 mesalib/docs/sourcetree.html (limited to 'mesalib/docs') 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 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 @@ - - - - Mini GLX Specification - - -

-
Mini GLX Specification
-

-

-
Tungsten Graphics, Inc.
-
-January 20, 2003
-
-
-

-

Copyright © 2002-2003 by Tungsten Graphics, Inc., Cedar Park, -Texas. All Rights Reserved.
-
-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.
-
-

-

1. Introduction

-

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.

-

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.

-

This document serves as both the reference guide and programming -guide for Mini GLX.
-
-

-

2. Mini GLX Concepts

-

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.

-

There are three main datatypes or resources managed by Mini GLX. The -resources and their corresponding GLX or Xlib data types are:

- - - - - - - - - - - - - - - - - - - -
ResourceData type
pixel formatsX Visual and XVisualInfo
drawing surfacesX Window or GLXDrawable
rendering contextsGLXContext
-

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.

-

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.

-

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.

-

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.
-
-

-

3. Using Mini GLX

-

To use the Mini GLX interface in your application, include the -GL/miniglx.h header file at compile time:

-
#include <GL/miniglx.h>
-
-Applications should link with libGL.so (i.e. gcc -myprogram.o -lGL -o myprogram).  libGL.so implements the -MiniGLX API functions and, in turn, loads a hardware-specific device -driver (such as radeon_dri.so) at runtime.  The -environment variable LIBGL_DRIVERS_PATH should name the -directory where these modules are located.
-
-The remainder of this section describes the MiniGLX API functions.
-
-

3.1 Initialization

-

The XOpenDisplay function is used to initialize the graphics system:

-
- 
Display *XOpenDisplay(const char *displayname)
-
-

The displayName parameter is currently ignored in Mini -GLX. It is recommended that NULL be passed as thedisplayName -parameter.

-

If XOpenDisplay is able to initialize the graphics system a pointer -to a Display will be returned. Otherwise, NULL will be returned.

-

3.2 Choosing a Visual

-

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:

-
- 
XVisualInfo *glXChooseVisual(Display *dpy, int screen, const int *attribList)
-
-

dpy is a pointer to the display returned by -XOpenDisplay.

-

screen is currently ignored by Mini GLX and should be -zero.

-

attribList is a list of GLX attributes which describe -the desired pixel format. It is terminated by the token None. -The attributes are as follows:

-
-
-
GLX_USE_GL
-
This attribute should always be present in order to maintain -compatibility with GLX.
-
GLX_RGBA
-
If present, only RGBA pixel formats will be considered. -Otherwise, only color index formats are considered.
-
GLX_DOUBLEBUFFER
-
if present, only double-buffered pixel formats will be chosen.
-
GLX_RED_SIZE n
-
Must be followed by a non-negative integer indicating the -minimum number of bits per red pixel component that is acceptable.
-
GLX_GREEN_SIZE n
-
Must be followed by a non-negative integer indicating the -minimum number of bits per green pixel component that is acceptable.
-
GLX_BLUE_SIZE n
-
Must be followed by a non-negative integer indicating the -minimum number of bits per blue pixel component that is acceptable.
-
GLX_ALPHA_SIZE n
-
Must be followed by a non-negative integer indicating the -minimum number of bits per alpha pixel component that is acceptable.
-
GLX_STENCIL_SIZE n
-
Must be followed by a non-negative integer indicating the -minimum number of bits per stencil value that is acceptable.
-
None
-
This token is used to terminate the attribute list.
-
-
-

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.

-

Note that visuals with accumulation buffers and depth buffers are -not available.
-
-

-

3.3 Creating a Drawing Surface

-

Drawing surfaces are created as X windows.  For Mini GLX, -windows are full-screen; 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.

-

3.3.1 Window Creation

-

The XCreateWindow function is used to create a drawing surface:

-
- 
Window XCreateWindow( Display *display,
                      Window parent,
                      int x, int y,
                      unsigned int width, unsigned int height,
                      unsigned int borderWidth,
                      int depth,
                      unsigned int class,
                      Visual *visual,
                      unsigned long valuemask,
                      XSetWindowAttributes *attributes )
-
-

The parameters are as follows:

-
-
-
display
-
A Display pointer, as returned by XOpenDisplay.
-
parent
-
The parent window for the new window. For Mini GLX, this -should beRootWindow(dpy, 0).
-
x, y
-
The position of the window. For Mini GLX, both values should -be zero.
-
width, height
-
The size of the window. For Mini GLX, this specifies the -desired screen size such as 1024, 768 or 1280, 1024.
-
borderWidth
-
This parameter should be zero.
-
depth
-
The pixel depth for the window. For Mini GLX this should be -the depth found in the XVisualInfo object returned by glxChooseVisual.
-
class
-
The window class. For Mini GLX this value should be InputOutput.
-
visual
-
This parameter should be the visual field of the XVisualInfo -object returned by glxChooseVisual.
-
valuemask
-
This parameter indicates which fields of the XSetWindowAttributes -are to be used. For Mini GLX this is typically the bitmaskCWBackPixel -| CWBorderPixel | CWColormap.
-
attributes
-
Initial window attributes. Of the fields in the XSetWindowAttributes -structure, thebackground_pixel, border_pixel -and colormap fields should be set.  See the discussion -below regarding colormaps.
-
-
-

XCreateWindow will return a window handle if it succeeds -or zero if it fails.

-

3.3.2 Window Mapping

-

To display the window the XMapWindow function must be called:

-
- 
void XMapWindow(Display *dpy, Window w)
-
-

This function does nothing in Mini GLX but is required for Xlib/GLX -compatibility

-

3.3.3 Colormaps
-

-

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:

-
Colormap XCreateColormap(Display *dpy, Window window, -Visual *visual, int alloc)
-
-

The parameters are as follows:
-

-
-
-
dpy
-
The display handle as returned by XOpenDisplay.
-
window
-
This parameter is ignored by Mini GLX but should be the value -returned by the RootWindow(dpy, 0) macro.
-
-
visual
-
This parameter is ignored by Mini GLX but should be the visual -field of the XVisualInfo object returned by glXChooseVisual.
-
alloc
-
This parameter is ignored by Mini GLX but should be set to AllocNone.
-
-
-
-

3.4 Creating a Rendering Context

-

An OpenGL rendering context is created with the glXCreateContext -function:

-
- 
GLXContext glXCreateContext(Display *dpy, XVisualInfo *visInfo, GLXContext shareList, Bool direct)
-
-

The parameters are as follows:

-
-
-
dpy
-
The display handle as returned by XOpenDisplay.
-
visInfo
-
The visual as returned by glXChooseVisual.
-
shareList
-
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.
-
direct
-
Specifies whether direct or indirect rendering is desired. For -Mini GLX this value is ignored but it should be set to True.
-
-
-

glXCreateContext will return a GLXContext handle if it -succeeds or zero if it fails due to invalid parameter or insufficient -resources.
-
-

-

3.5 Binding a Rendering Context

-

The final step before beginning OpenGL rendering is to bind (i.e. -activate) a rendering context and drawing surface with the -glXMakeCurrent function:

-
- 
Bool glXMakeCurrent(Display *dpy, GLXDrawable drawable, GLXContext ctx)
-
-

The parameters are as follows:

-
-
-
dpy
-
The display handle, as returned by XOpenDisplay.
-
drawable
-
The window or drawable to bind to the rendering context. This -should be the value returned by XCreateWindow.
-
ctx
-
The rendering context to bind, as returned by glXCreateContext.
-
-
-

If glXMakeCurrent succeeds True is returned. Otherwise False is -returned to indicate an invalid display, window or context parameter.

-

After the rendering context has been bound to the drawing surface -OpenGL rendering can begin.

-

The current rendering context may be unbound by calling -glXMakeCurrent with the window and context parameters set to zero.

-

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.
-
-

-

3.6 Color Buffer Swapping

-

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.

-

The color buffers for a particular window (i.e. drawable) may be -swapped with the glXSwapBuffers command:

-
- 
void glXSwapBuffers(Display *dpy, GLXDrawable drawable)
-
-Any pending rendering commands will be completed before the buffer swap -takes place.
-
-Calling glXSwapBuffers on a window which is single-buffered has no -effect.
-
-

3.7 Releasing Resources

-

3.7.1 Releasing Rendering Contexts

-

A rendering context may be destroyed by calling glXDestroyContext:

-
- 
void glXDestroyContext(Display *dpy, GLXContext ctx)
-
-

3.7.2 Releasing Windows

-

A window may be destroyed by calling XDestroyWindow:

-
- 
void XDestroyWindow(Display *dpy, Window window)
-
-

3.7.3 Releasing Visuals

-

An XVisualInfo object may be freed by calling XFree:

-
- 
void XFree(void *data)
-
-

3.7.4 Releasing Colormaps

-

A colormap may be freed by calling XFreeColormap:

-
- 
void XFreeColormap(Display *dpy, Colormap colormap)
-
-

3.7.4 Releasing Display Resources

-

When the application is about to exit, the resources associated with -the graphics system can be released by calling XCloseDisplay:

-
- 
void XCloseDisplay(Display *dpy)
-
-

The display handle becomes invalid at this point.
-
-

-

3.8 Query Functions

-

3.8.1 Querying Available Visuals

-A list of all available visuals can be obtained with the XGetVisualInfo -function:
-
-
XVisualInfo -*XGetVisualInfo(Display *dpy, long vinfo_mask, XVisualInfo -*vinfo_template, int *nitems_return)
-
-
-The parameters are as follows:
-
-
-
dpy
-
The display handle, as returned by XOpenDisplay.
-
vinfo_mask
-
A bitmask indicating which fields of the vinfo_template are to -be matched.  The value must be VisualScreenMask.
-
vinfo_template
-
A template whose fields indicate which visual attributes must -be matched by the results.  The screen field of this structure must -be zero.
-
nitems_return
-
Returns the number of visuals returned.
-
-
-The return value is the address of an array of all available visuals.
-
-An example of using XGetVisualInfo to get all available visuals follows:
-
-
XVisualInfo visTemplate, *results;
-int numVisuals;
-Display *dpy = XOpenDisplay(NULL);
-visTemplate.screen = 0;
-results = XGetVisualInfo(dpy, VisualScreenMask, &visTemplate, -&numVisuals);
-
-
-

3.8.2 Querying Visual Attributes

-

The GLX attributes of an X visual may be queried with the -glXGetConfig function:

-
- 
int glXGetConfig(Display *dpy, XVisualInfo *vis, int attribute, int *value)
-
-

The parameters are as follows:

-
-
-
dpy
-
The display handle, as returned by XOpenDisplay.
-
vis
-
The visual, as returned by glXChooseVisual.
-
attribute
-
The attribute to query. The attributes are listed below.
-
value
-
Pointer to an integer in which the result of the query will be -stored.
-
-
-

The return value will be zero if no error occurs. - GLX_INVALID_ATTRIBUTE will be returned if the attribute -parameter is invalid.  GLX_BAD_VISUAL will be returned -if the XVisualInfo parameter is invalid.

-

The following attributes may be queried:

-
-
-
GLX_USE_GL
-
The result will be True or False to -indicate if OpenGL rendering is supported with the visual. Mini GLX -always return True.
-
GLX_RGBA
-
The result will be True for RGBA visuals or False -for color index visuals.
-
GLX_DOUBLEBUFFER
-
The result will be True if the visual has two -color buffers or False if the visual has one color buffer.
-
GLX_RED_SIZE
-
The result will be the number of red bits per pixel.
-
GLX_GREEN_SIZE
-
The result will be the number of green bits per pixel.
-
GLX_BLUE_SIZE
-
The result will be the number of blue bits per pixel.
-
GLX_ALPHA_SIZE
-
The result will be the number of alpha bits per pixel.
-
GLX_DEPTH_SIZE
-
The result will be the number of bits per Z value.
-
GLX_STENCIL_SIZE
-
The result will be the number of bits per stencil value.
-
-
-
-
-

3.8.3 Querying the Current Rendering Context

-

The current rendering context can be queried with -glXGetCurrentContext:

-
- 
GLXContext glXGetCurrentContext(void)
-
-

Zero will be returned if no context is currently bound.
-
-

-

3.8.4 Querying the Current Drawable

-

The current drawable (i.e. window or drawing surface) can be queried -with glXGetCurrentDrawable:

-
- 
GLXDrawable glXGetCurrentDrawable(void)
-
-

Zero will be returned if no drawable is currently bound.
-
-

-

3.8.5 Function Address Queries

-

The glXGetProcAddress function will return the address of any -available OpenGL or Mini GLX function:

-
- 
void *glXGetProcAddress(const GLubyte *procName)
-
-

If procName is a valid function name, a pointer to that -function will be returned.  Otherwise, NULL will be returned.

-

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.
-
-

-

3.9 Versioning

-The Mini GLX version can be queried at run time with glXQueryVersion: -
- 
Bool glXQueryVersion(Display *dpy, int *major, int *minor)
-
-

major will be set to the major version number andminor -will be set to the minor version number.True will be -returned if the function succeeds. False will be returned -if the function fails due to invalid parameters. The dpy -argument is currently ignored, but should be the value returned by -XOpenDisplay.

-

At compile time, the Mini GLX interface version can be tested with -the MINI_GLX_VERSION_1_x preprocessor tokens. For example, if -version 1.0 of Mini GLX is supported, then MINI_GLX_VERSION_1_0 -will be defined. If version 1.1 of Mini GLX is supported, then -MINI_GLX_VERSION_1_1 will be defined.

-

At the time of writing the current Mini GLX version is 1.0.
-
-

-

4.0 Interoperability with GLX and Xlib

-While Mini GLX strives to be compatible with GLX and Xlib there are -some unavoidable differences which must be taken into consideration.
-

4.1 Public vs Private Structures

-The structure of many X data types is public.  For example, the Display -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 miniglx.h.  Duplicating the Xlib -declaration for the Display data type in minigl.h would -require defining a large number of other superfluous Xlib datatypes.
-
-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 XVisualInfo and XSetWindowAtttributes -data types must be completely public. -

4.2 Macros

-In some cases, Xlib defines macros which are meant to be used instead -of direct structure accesses.  For example, the RootWindow(dpy, -screen) 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.
-
-Mini GLX also defines a RootWindow macro since it's -essential for creating windows.  But the implementation of this -macro by Xlib and Mini GLX is completely different.
-

4.3 Summary

-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.
-
-Nevertheless, the fact that Mini GLX programs can be recompiled for -Xlib and GLX increases portability and flexibility for testing and -prototyping.
-
-

5.0 Example Program

-

This section shows an example program which uses the Mini GLX -interface. The program simply draws several frames of a rotating square.
-

-

The program may be compiled for use with Xlib/GLX or Mini GLX by -setting the USE_MINIGLX token to 0 or 1, respectively. - Note that the only difference is the header files which are -included.
-

-

-

#define USE_MINIGLX 1  /* 1 = use Mini GLX, 0 = use Xlib/GLX */

#include <stdio.h>
#include <stdlib.h>
#include <GL/gl.h>

#if USE_MINIGLX
#include <GL/miniglx.h>
#else
#include <GL/glx.h>
#include <X11/Xlib.h>
#endif

/*
 * Create a simple double-buffered RGBA window.
 */
static Window
MakeWindow(Display * dpy, unsigned int width, unsigned int height)
{
   int visAttributes[] = {
      GLX_RGBA,
      GLX_RED_SIZE, 1,
      GLX_GREEN_SIZE, 1,
      GLX_BLUE_SIZE, 1,
      GLX_DOUBLEBUFFER,
      None
   };
   XSetWindowAttributes attr;
   unsigned long attrMask;
   Window root;
   Window win;
   GLXContext ctx;
   XVisualInfo *visinfo;

   root = RootWindow(dpy, 0);

   /* Choose GLX visual / pixel format */
   visinfo = glXChooseVisual(dpy, 0, visAttributes);
   if (!visinfo) {
      printf("Error: couldn't get an RGB, Double-buffered visual\n");
      exit(1);
   }

   /* Create the window */
   attr.background_pixel = 0;
   attr.border_pixel = 0;
   attr.colormap = XCreateColormap(dpy, root, visinfo->visual, AllocNone);
   attrMask = CWBackPixel | CWBorderPixel | CWColormap;
   win = XCreateWindow(dpy, root, 0, 0, width, height,
		       0, visinfo->depth, InputOutput,
		       visinfo->visual, attrMask, &attr);
   if (!win) {
      printf("Error: XCreateWindow failed\n");
      exit(1);
   }

   /* Display the window */
   XMapWindow(dpy, win);

   /* Create GLX rendering context */
   ctx = glXCreateContext(dpy, visinfo, NULL, True);
   if (!ctx) {
      printf("Error: glXCreateContext failed\n");
      exit(1);
   }

   /* Bind the rendering context and window */
   glXMakeCurrent(dpy, win, ctx);

   return win;
}


/*
 * Draw a few frames of a rotating square.
 */
static void
DrawFrames(Display * dpy, Window win)
{
   int angle;
   glShadeModel(GL_FLAT);
   glClearColor(0.5, 0.5, 0.5, 1.0);
   for (angle = 0; angle < 360; angle += 10) {
      glClear(GL_COLOR_BUFFER_BIT);
      glColor3f(1.0, 1.0, 0.0);
      glPushMatrix();
      glRotatef(angle, 0, 0, 1);
      glRectf(-0.8, -0.8, 0.8, 0.8);
      glPopMatrix();
      glXSwapBuffers(dpy, win);
   }
}


int
main(int argc, char *argv[])
{
   Display *dpy;
   Window win;

   dpy = XOpenDisplay(NULL);
   if (!dpy) {
      printf("Error: XOpenDisplay failed\n");
      return 1;
   }

   win = MakeWindow(dpy, 300, 300);

   DrawFrames(dpy, win);

   return 0;
}
-
- - 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 { User Topics @@ -244,8 +244,8 @@ isn't a significant problem.

system. There are two steps to this. The file must first be added to src/mesa/sources. That gets the file built and linked. The second step is to add the correct #ifdef magic to -src/mesa/main/dispatch.c to prevent the C version of the dispatch -functions from being built.

+src/mesa/glapi/glapi_dispatch.c to prevent the C version of the +dispatch functions from being built.

3.4. Fixed-Length Dispatch Stubs

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 @@ + + +Mesa EGL + + + + + +

Mesa EGL

+ +

The current version of EGL in Mesa implements EGL 1.4. More information +about EGL can be found at + +http://www.khronos.org/egl/.

+ +

The Mesa's implementation of EGL uses a driver architecture. The main +library (libEGL) 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.

+ +

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.

+ +

Build EGL

+ +
    +
  1. +

    Run configure with the desired state trackers and enable +the Gallium driver for your hardware. For example

    + +
    +  $ ./configure --with-state-trackers=egl,es,vega --enable-gallium-{swrast,intel}
+
    + +

    The main library will be enabled by default. The egl state +tracker is needed by a number of EGL drivers. EGL drivers will be covered +later. The es state tracker provides OpenGL ES 1.x +and 2.x and the vega state tracker provides OpenVG +1.x.

    +
    2. + +
  2. Build and install Mesa as usual.
    3. +
+ +

In the given example, it will build and install libEGL, +libGLESv1_CM, libGLESv2, libOpenVG, and +one or more EGL drivers.

+ +

Configure Options

+ +

There are several options that control the build of EGL at configuration +time

+ + + +

OpenGL

+ +

The OpenGL state tracker is not built in the above example. It should be +noted that the classic libGL is not a state tracker and cannot be +used with EGL (unless the EGL driver in use is egl_glx). To build +the OpenGL state tracker, one may append glx to +--with-state-trackers and manually build +src/gallium/winsys/xlib/.

+ +

Use EGL

+ +

The demos for OpenGL ES and OpenVG can be found in progs/es1/, +progs/es2/ and progs/openvg/. You can use them to +test your build. For example,

+ +
+  $ cd progs/es1/xegl
+  $ make
+  $ ./torus
+
+ +

Environment Variables

+ +

There are several environment variables that control the behavior of EGL at +runtime

+ + + +

EGL Drivers

+ +

There are two categories of EGL drivers: Gallium and classic.

+ +

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 egl state +tracker to build. The available drivers are

+ + + +

<dpy> is given by --with-egl-displays at +configuration time. There will be one EGL driver for each combination of the +displays listed and the hardware drivers enabled.

+ +

Classic EGL drivers, on the other hand, supports only OpenGL as its +rendering API. They can be found under src/egl/drivers/. There +are 3 of them

+ + + +

To use the classic drivers, one must manually set EGL_DRIVER at +runtime.

+ +

Developers

+ +

The sources of the main library and the classic drivers can be found at +src/egl/. The sources of the egl state tracker can +be found at src/gallium/state_trackers/egl/.

+ +

The suggested way to learn to write a EGL driver is to see how other drivers +are written. egl_glx should be a good reference. It works in any +environment that has GLX support, and it is simpler than most drivers.

+ +

Lifetime of Display Resources

+ +

Contexts and surfaces are examples of display resources. They might live +longer than the display that creates them.

+ +

In EGL, when a display is terminated through eglTerminate, all +display resources should be destroyed. Similarly, when a thread is released +throught eglReleaseThread, all current display resources should be +released. Another way to destory or release resources is through functions +such as eglDestroySurface or eglMakeCurrent.

+ +

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 +eglIs<Resource>Bound 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.

+ +

The main library will mark destroyed current resources as unlinked. In a +driver's MakeCurrent callback, +eglIs<Resource>Linked 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 MakeCurrent might be called with an +uninitialized display.

+ +

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.

+ +

EGL_RENDER_BUFFER

+ +

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 EGL_RENDER_BUFFER set to +EGL_SINGLE_BUFFER; If the same context is later bound to a +surface with EGL_RENDER_BUFFER set to +EGL_BACK_BUFFER, 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.

+ +

For pbuffer surfaces, the render buffer is always +EGL_BACK_BUFFER. And for pixmap surfaces, the render buffer is +always EGL_SINGLE_BUFFER. Unlike window surfaces, EGL spec +requires their EGL_RENDER_BUFFER values to be honored. As a +result, a driver should never set EGL_PIXMAP_BIT or +EGL_PBUFFER_BIT bits of a config if the contexts created with the +config won't be able to honor the EGL_RENDER_BUFFER of pixmap or +pbuffer surfaces.

+ +

It should also be noted that pixmap and pbuffer surfaces are assumed to be +single-buffered, in that eglSwapBuffers 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.

+ +

There is no defined behavior as to, for example, how +glDrawBuffer interacts with EGL_RENDER_BUFFER. 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.

+ +

EGLDisplay Mutex

+ +The EGLDisplay will be locked before calling any of the dispatch +functions (well, except for GetProcAddress which does not take an +EGLDisplay). 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 EGLDisplay without going through the EGL APIs, the driver +should as well lock the display before using it. + +

TODOs

+ + + + + 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 Xlib software driver page for details. +

+These environment variables are for the Intel i945/i965 drivers: +

+ + + +

+These environment variables are for the Radeon R300 driver: +

+ + +

+Mesa EGL supports different sets of environment variables. See the +Mesa EGL page for the details. +

+ 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 @@ -351,20 +351,11 @@ example linux or windows, machine is x86 or x86_64, optionally followed by -debug for debug builds.

-

-The sample programs are built seperately. To build them do -

-    scons -C progs
-
-And the build output will be placed in progs/build/... -

-

To build Mesa with SCons for Windows on Linux using the MinGW crosscompiler toolchain do 

     scons platform=windows toolchain=crossmingw machine=x86 statetrackers=mesa drivers=softpipe,trace winsys=gdi
-    scons -C progs platform=windows toolchain=crossmingw machine=x86 -k

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 @@

+

+Follow the links above for list archives. +

+

For mailing lists about Direct Rendering Modules (drm) in Linux/BSD -kernels, see wiki. +kernels, see the + +DRI wiki. +

-Notice: non-member posts to any of these lists will be automatically -rejected. +Notice: You must subscribe to these lists in order to post to them.

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 @@

News

-

November XX, 2009

+ +

March 26, 2010

+

+Mesa 7.7.1 is released. This is a bug-fix +release fixing issues found in the 7.7 release. +

+

+Also, Mesa 7.8 is released. This is a new +development release. +

+ + + +

December 21, 2009

Mesa 7.6.1 is released. This is a bug-fix release fixing issues found in the 7.6 release.

+

+Also, Mesa 7.7 is released. This is a new +development release. +

September 28, 2009

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 @@ + + +OpenGL ES State Trackers + + + + + +

OpenGL ES State Trackers

+ +

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 + +http://www.khronos.org/opengles/.

+ +

The OpenGL ES state trackers depends on the Gallium architecture and a +working EGL implementation. Please refer to Mesa EGL +for more information about EGL.

+ + +

Build the Libraries

+
    +
  1. Run configure with --with-state-trackers=egl,es and enable the Gallium driver for your hardware.
    2. +
  2. Build and install Mesa as usual.
    3. +
+ +

It will install libGLESv1_CM, libGLESv2, libEGL, and one or more EGL drivers for your hardware.

+

Run the Demos

+ +

There are some demos in progs/es1/ and progs/es2/. You can use them to test your build. For example,

+ +
+  $ cd progs/es1/xegl
+  $ make
+  $ ./torus
+
+ +

Developers

+ +

The core of OpenGL ES state trackers is the ES overlay. It is located in +src/mesa/es/.

+ +

Structure

+ +

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

+ + + + + + + + + +
Library NameUsageSource
libmesagallium.aOpenGL state trackerMesa
libes1gallium.aOpenGL ES 1.x state trackerES overlay
libes2gallium.aOpenGL ES 2.x state trackerES overlay
libglapi.aOpenGL APIMesa
libes1api.aOpenGL ES 1.x APIES overlay
libes2api.aOpenGL ES 2.x APIES overlay
+ +

The OpenGL ES state trackers and APIs are then used by src/gallium/state_trackers/es/ to create the final libraries.

+ +

Dispatch Table

+ +

The ES overlay uses an additional indirection when dispatching fucntions

+ +
+  Mesa:       glFoo() --> _mesa_Foo()
+  ES overlay: glFoo() --> _es_Foo() --> _mesa_Foo()
+
+ +

The indirection serves several purposes

+ + + +

Other than the last case, the ES overlay uses APIspec.xml to generate functions to check and/or converts the arguments.

+ + + 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 @@ -Mesa Release Notes +OpenVG State Tracker @@ -20,12 +20,13 @@ http://www.khronos.org/openvg/ .

The OpenVG state tracker depends on the Gallium architecture and a working EGL implementation. +Please refer to Mesa EGL for more information about EGL.

Building the library

    -
  1. Build Mesa3D with Gallium3D. Any build that builds Gallium3D libraries and EGL will suffice
    2. +
  2. Build Mesa3D with Gallium3D. Any build that builds Gallium3D libraries, EGL, and Gallium EGL drivers will suffice
  3. cd src/gallium/state_trackers/vega; make
  4. The last step will build libOpenVG library. You can add the libdir to LD_LIBRARY_PATH or install libOpenVG
@@ -33,12 +34,9 @@ The OpenVG state tracker depends on the Gallium architecture and a working EGL i

Sample build

A sample build looks as follows: 
-  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

OpenVG Demos

@@ -59,10 +57,5 @@ To run a demo: -

Notes

- - 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.

-There are several examples of OSMesa in the progs/osdemo/ +There are several examples of OSMesa in the progs/osdemos/ directory.

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 @@ - - -PBuffer Rendering - - - - - -

PBuffer Rendering

- -

-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. -

- -

-PBuffers are getting more use nowadays, though they've actually been -around for a long time on IRIX systems and other workstations. -

- -

-The -GL_SGIX_fbconfig -and - -GL_SGIX_pbuffer extensions describe the functionality. -More recently, these extensions have been promoted to ARB extensions (on -Windows at least). -

- -

-The Mesa/progs/xdemos/ directory has some useful code for working -with pbuffers: -

- - - -

-Mesa 4.1 and later support GL_SGIX_fbconfig and GL_SGIX_pbuffer (software -rendering only). -

- - - 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 @@ -

Mesa 7.6.1 Release Notes, (date tbd)

+

Mesa 7.6.1 Release Notes, 21 December 2009

Mesa 7.6.1 is a bug-fix release fixing issues since version 7.6. @@ -26,7 +26,15 @@ for DRI hardware acceleration.

MD5 checksums

-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
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 @@ + + +Mesa Release Notes + + + + + + + +

Mesa 7.7.1 Release Notes / March 28, 2010

+ +

+Mesa 7.7.1 is a bug-fix release. +

+

+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. +

+

+See the Compiling/Installing page for prerequisites +for DRI hardware acceleration. +

+ + +

MD5 checksums

+
+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
+
+ + +

Bug fixes

+ + + + + 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 @@ -

Mesa 7.7 Release Notes / date TBD

+

Mesa 7.7 Release Notes / 21 December 2009

Mesa 7.7 is a new development release. @@ -28,7 +28,15 @@ for DRI hardware acceleration.

MD5 checksums

-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
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 @@ + + +Mesa Release Notes + + + + + + + +

Mesa 7.8 Release Notes / March 28, 2010

+ +

+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. +

+

+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. +

+

+See the Compiling/Installing page for prerequisites +for DRI hardware acceleration. +

+ + +

MD5 checksums

+
+tbd
+
+ + +

New features

+ + + +

Bug fixes

+ + + +

Changes

+ + + + 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.