From 43caa5c09a5059c1ee05f5ecc7030f5a1c642531 Mon Sep 17 00:00:00 2001 From: Brian Paul Date: Fri, 4 May 2001 17:42:53 +0000 Subject: added info about driver status in 3.5 --- docs/RELNOTES-3.5 | 54 +++++++++++++++++++++++++++++++++--------------------- 1 file changed, 33 insertions(+), 21 deletions(-) (limited to 'docs/RELNOTES-3.5') diff --git a/docs/RELNOTES-3.5 b/docs/RELNOTES-3.5 index 96ab65e22a..b92e447cad 100644 --- a/docs/RELNOTES-3.5 +++ b/docs/RELNOTES-3.5 @@ -1,7 +1,7 @@ Mesa 3.5 release notes - Month ??, 2001 + May ??, 2001 PLEASE READ!!!! @@ -11,14 +11,39 @@ Introduction ------------ Mesa uses an even/odd version number scheme like the Linux kernel. -Odd numbered versions (such as 3.3) designate new developmental releases. +Odd numbered versions (such as 3.5) designate new developmental releases. Even numbered versions (such as 3.4) designate stable releases. -The internal structure of Mesa 3.5 is (will be) changed so that it -is more modular. The motivation is better support of 3D hardware -such as T&L hardware in which much of core Mesa isn't needed. +The biggest change in Mesa 3.5 is a complete overhaul of the source +code in order to make it more modular. This was driven by the DRI +hardware drivers. It simplifies the DRI drivers and opens the door +to hardware transform/clip/lighting (TCL). + + + +Driver Support +-------------- + +The device driver interface in Mesa 3.5 has changed a lot since Mesa 3.4 +Not all of the older Mesa drivers have been updated. Here's the status: + +Driver Status +---------------------- ----------- +XMesa (Xlib) updated +OSMesa (off-screen) updated +FX (3dfx Voodoo1/2) updated +SVGA updated +GGI not updated +Windows/Win32 not updated +DOS/DJGPP not updated +BeOS not updated +Allegro not updated +D3D not updated +DOS not updated + +We're looking for volunteers to update the remaining drivers. Please +post to the Mesa3d-dev mailing list if you can help. -Details to come... GLU 1.3 @@ -156,20 +181,7 @@ xm_dd.c, xm_line.c, xm_span.c and xm_tri.c. Multitexture ------------ -Three texture units are now supported by default. We'll allow more -than three texture units when we fix some bitfield issues. In at least -one place we have a 32-bit bitfield which is fully allocated, leaving -no space for texture unit #3 or higher. - -The TEXTURE1_1D, TEXTURE1_2D, etc constants may go away in the future. -Currently, they're only used in the ctx->Texture.ReallyEnabled field. -This bitfield is just a conglomerate of ctx->Texture.Unit[i].ReallyEnabled -for all texture units. ctx->Texture.ReallyEnabled may become a -GLboolean. Then, drivers will have to loop over the texture units to -examine ctx->Texture.Unit[i].ReallyEnabled. - - - +Eight texture units are now supported by default. @@ -208,4 +220,4 @@ In the future I hope to implement support for 32-bit, floating point color channels. ---------------------------------------------------------------------- -$Id: RELNOTES-3.5,v 1.12 2001/04/26 22:33:34 brianp Exp $ +$Id: RELNOTES-3.5,v 1.13 2001/05/04 17:42:53 brianp Exp $ -- cgit v1.2.3