|
|
|
|
|
|
|
|
|
|
|
|
|
|
Mesa 3.5 release notes |
|
|
Mesa 3.5 release notes |
|
|
|
|
|
|
|
|
Month ??, 2001 |
|
|
|
|
|
|
|
|
May ??, 2001 |
|
|
|
|
|
|
|
|
PLEASE READ!!!! |
|
|
PLEASE READ!!!! |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
------------ |
|
|
------------ |
|
|
|
|
|
|
|
|
Mesa uses an even/odd version number scheme like the Linux kernel. |
|
|
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. |
|
|
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 |
|
|
GLU 1.3 |
|
|
|
|
|
|
|
|
Multitexture |
|
|
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. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
color channels. |
|
|
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 $ |