RELNOTES-4.1 revision 55c82c596e1c1e597da183942db002d3d0b8f29f
1 2 Mesa 4.1 release notes 3 4 <month>, <day>, 2002 5 6 PLEASE READ!!!! 7 8 9 10Introduction 11------------ 12 13Mesa uses an even/odd version number scheme like the Linux kernel. 14Even numbered versions (such as 4.0) designate stable releases. 15Odd numbered versions (such as 4.1) designate new developmental releases. 16 17 18New Features in Mesa 4.1 19------------------------ 20 21New extensions. Docs at http://oss.sgi.com/projects/ogl-sample/registry/ 22 23GL_NV_vertex_program 24 25 NVIDIA's vertex programming extension 26 27GL_NV_vertex_program1_1 28 29 A few features built on top of GL_NV_vertex_program 30 31GL_ARB_window_pos 32 33 This is the ARB-approved version of GL_MESA_window_pos 34 35GL_ARB_depth_texture 36 37 This is the ARB-approved version of GL_SGIX_depth_texture. 38 It allows depth (Z buffer) data to be stored in textures. 39 This is used by GL_ARB_shadow 40 41GL_ARB_shadow 42 43 Shadow mapping with depth textures. 44 This is the ARB-approved version of GL_SGIX_shadow. 45 46GL_ARB_shadow_ambient 47 48 Allows one to specify the luminance of shadowed pixels. 49 This is the ARB-approved version of GL_SGIX_shadow_ambient. 50 51GL_EXT_shadow_funcs 52 53 Extends the set of GL_ARB_shadow texture comparision functions to 54 include all eight of standard OpenGL dept-test functions. 55 56GL_ARB_point_parameters 57 58 This is basically the same as GL_EXT_point_parameters. 59 60GL_ARB_texture_env_crossbar 61 62 Allows any texture combine stage to reference any texture source unit. 63 64GL_NV_point_sprite 65 66 For rendering points as textured quads. Useful for particle effects. 67 68GL_NV_texture_rectangle 69 70 Allows one to use textures with sizes that are not powers of two. 71 Note that mipmapping and several texture wrap modes are not allowed. 72 73GL_EXT_multi_draw_arrays 74 75 Allows arrays of vertex arrays to be rendered with one call. 76 77 78 79Device Driver Status 80-------------------- 81 82A number of Mesa's software drivers haven't been actively maintained for 83some time. We rely on volunteers to maintain many of these drivers. 84Here's the current status of all included drivers: 85 86 87Driver Status 88---------------------- --------------------- 89XMesa (Xlib) implements OpenGL 1.3 90OSMesa (off-screen) implements OpenGL 1.3 91FX (3dfx Voodoo1/2) implements OpenGL 1.3 92SVGA implements OpenGL 1.3 93Wind River UGL implements OpenGL 1.3 94Windows/Win32 implements OpenGL 1.3 95DOS/DJGPP implements OpenGL 1.3 96GGI implements OpenGL 1.3 97BeOS needs updating (underway) 98Allegro needs updating 99D3D needs updating 100DOS needs updating 101 102 103 104Porting Information 105------------------- 106 107When moving from Mesa 4.0.x to Mesa 4.1 there are a number of things 108you may have to update. 109 1101. _mesa_create_context() changes. This function now takes a pointer to 111 a __GLimports object. The __GLimports structure contains function 112 pointers to system functions like fprintf(), malloc(), etc. 113 The _mesa_init_default_imports() function can be used to initialize 114 a __GLimports object. Most device drivers (like the DRI drivers) 115 should use this. 116 1172. more to come... 118 119 120 121XXX Things To Do Yet XXXX 122------------------------- 123 124Verify x86 code for normal transformation works with new 4-element normal 125vector arrays. Pretty sure the SSE code is wrong. 126 127Finish up NV_vertex_program support for evaluators. Vertex arrays seem 128to work as of 4/21/2002. 129 130Allow multiple points to be rendered into one sw_span. 131 132improve point/line rendering speed. 133 134_tnl_end() has flushing forced on. 135 136readpixels from stencil/z should respect ctx->ReadBuffer 137 138glVertexAttrib*NV(index>15) should cause an error. 139 140isosurf with vertex program exhibits some missing triangles (probably 141when recycling the vertex buffer for long prims). 142 143 144 145Porting Info 146------------ 147 148If you're porting a DRI or other driver from Mesa 4.0.x to Mesa 4.1 here 149are some things to change: 150 1511. ctx->Texture._ReallyEnabled is obsolete. 152 153 Since there are now 5 texture targets (1D, 2D, 3D, cube and rect) that 154 left room for only 6 units (6*5 < 32) in this field. 155 This field is being replaced by ctx->Texture._EnabledUnits which has one 156 bit per texture unit. If the bit k of _EnabledUnits is set, that means 157 ctx->Texture.Unit[k]._ReallyEnabled is non-zero. You'll have to look at 158 ctx->Texture.Unit[k]._ReallyEnabled to learn if the 1D, 2D, 3D, cube or 159 rect texture is enabled for unit k. 160 161 This also means that the constants TEXTURE1_*, TEXTURE2_*, etc are 162 obsolete. 163 164 The tokens TEXTURE0_* have been replaced as well (since there's no 165 significance to the "0" part: 166 167 old token new token 168 TEXTURE0_1D TEXTURE_1D_BIT 169 TEXTURE0_2D TEXTURE_2D_BIT 170 TEXTURE0_3D TEXTURE_3D_BIT 171 TEXTURE0_CUBE TEXTURE_CUBE_BIT 172 <none> TEXTURE_RECT_BIT 173 174 These tokens are only used for the ctx->Texture.Unit[i].Enabled and 175 ctx->Texture.Unit[i]._ReallyEnabled fields. Exactly 0 or 1 bits will 176 be set in _ReallyEnabled at any time! 177 178 Q: "What's the purpose of Unit[i].Enabled vs Unit[i]._ReallyEnabled?" 179 A: The user can enable GL_TEXTURE_1D, GL_TEXTURE_2D, etc for any 180 texure unit all at once (an unusual thing to do). 181 OpenGL defines priorities that basically say GL_TEXTURE_2D has 182 higher priority than GL_TEXTURE_1D, etc. Also, just because a 183 texture target is enabled by the user doesn't mean we'll actually 184 use that texture! If a texture object is incomplete (missing mip- 185 map levels, etc) it's as if texturing is disabled for that target. 186 The _ReallyEnabled field will have a bit set ONLY if the texture 187 target is enabled and complete. This spares the driver writer from 188 examining a _lot_ of GL state to determine which texture target is 189 to be used. 190 191 1922. Tnl tokens changes 193 194 During the implementation of GL_NV_vertex_program some of the vertex 195 buffer code was changed. Specifically, the VERT_* bits defined in 196 tnl/t_context.h have been renamed to better match the conventions of 197 GL_NV_vertex_program. The old names are still present but obsolete. 198 Drivers should use the newer names. 199 200 For example: VERT_RGBA is now VERT_BIT_COLOR0 and 201 VERT_SPEC_RGB is now VERT_BIT_COLOR1. 202 203 204 2053. Read/Draw Buffer changes 206 207 The business of setting the current read/draw buffers in Mesa 4.0.x 208 was complicated. It's much simpler now in Mesa 4.1. 209 210 Here are the changes: 211 212 - Rename ctx->Color.DrawDestMask to ctx->Color._DrawDestMask 213 - Rename ctx->Color.DriverDrawBuffer to ctx->Color._DriverDrawBuffer 214 - Rename ctx->Pixel.DriverReadBuffer to ctx->Pixel._DriverReadBuffer 215 - Removed ctx->Color.MultiDrawBuffer 216 - Removed ctx->Driver.SetDrawBuffer 217 - Added ctx->Driver.DrawBuffer and ctx->Driver.ReadBuffer. These functions 218 exactly correspond to glDrawBuffer and glReadBuffer calls. 219 Many drivers will set ctx->Driver.DrawBuffer = _swrast_DrawBuffer and 220 leave ctx->Draw.ReadBuffer NULL. 221 DRI drivers should implement their own function for ctx->Driver.DrawBuffer 222 and use it to set the current hardware drawing buffer. You'll probably 223 also want to check for GL_FRONT_AND_BACK mode and fall back to software. 224 Call _swrast_DrawBuffer() too, to update the swrast state. 225 - Removed swrast->Driver.SetReadBuffer 226 - Added swrast->Driver.SetBuffer. This function should be implemented by 227 _all_ device drivers. Mesa will call it to specify the buffer to use 228 for span reading AND writing and point/line/triangle rendering. There 229 should be no confusion between current read or draw buffer anymore. 230 231 232 233 234---------------------------------------------------------------------- 235$Id: RELNOTES-4.1,v 1.13 2002/07/09 01:28:03 brianp Exp $ 236