fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2026-05-05 16:08:04 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

added info about driver status in 3.5

Browse source
This commit is contained in:
Brian Paul 2001-05-04 17:42:53 +00:00
parent a2519c8aed
commit 43caa5c09a
1 changed files with 33 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

54
docs/RELNOTES-3.5
View file

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